Build vs Buy vs Adopt - What Should Software Engineers Do?

Transcript is auto-generated and may contain errors.

Hey folks, I'm just leaving the office here and we're going to go to the experience dev subreddit. This topic is about um they called it build versus adopt and I guess you know different flavors of this are like build versus buy versus adopt I suppose and uh kind of boils down to like you know as a software engineering team how do you make decisions about whether this is a technology that you need to build inhouse or otherwise use something that already exists. And so I think the framing for this post just for you know a little bit of extra context this Redditor was saying I think they're they're working somewhere where not everyone comes from a software development background and I think some people may have experience like this where their team is composed of uh of people like this or decision makers are and for some other people that might sound very foreign like what do you mean you're building software and uh Not everyone is like this.

So I think that's something I mean just to keep in mind as we're going through this because depending on your experience that may look different. But fundamental question, how do you make a decision about whether this is something a tech stack, whatever it is, uh that you should be building for your your use case, your product or service, or should you be adopting something that already exists? And I like this topic because I think there's a bunch of different things to consider. And you know in some situation making a decision about adopting or building a technology uh might seem very obvious and you can take the same sort of decision making and apply it in a different context and maybe like it turns it completely on its head. So going through and thinking through these types of things I think is really important. It genuinely is like an engineering activity because you have to think about pros and cons and weigh things out.

So overall, I like this topic and I also think that it's something that like it's not like you only see this at some part of your career or like uh only in some domains. I think this happens like all the time. So having more and more exposure to this and thinking through these types of things I think is just uh beneficial overall. Okay. So, I don't know exactly how I want to start on this one. And part of me was thinking like maybe it's like taking what seems like an exaggerated scenario might be kind of interesting uh because maybe that'll get us to think about it um from different angles right from the start. Right? So, I've had this conversation online before and uh I think the example I gave was like a database, right? So today, if you were building something and you needed a data store, is it likely that you would go build your own database from scratch?

So I mean like literally invent one, come up with some data store, or is it more likely or more plausible, a better fit that you would use something that's offtheshelf? Right? So that's the adopt versus build your own. And I think for many people the answer is probably like almost almost a no-brainer like I'm just like there's so many databases just pick one right and a lot of people you need a relational database cool use postgress done like we've solved it just go use Postgress right um or you know you could be like oh we're a Microsoft shop so like we want uh Microsoft SQL Server I don't know why for me. I just there's no good reason. I always default to MySQL. I don't I just I don't know why. And I've said this on video before, but like part of me is like next time next time I'm building something I need a database, I'm probably just going to try to convince myself just go use Postgress.

So for a lot of us, this is almost a decision that we don't make at all, right? It's it's almost not like do you build your own. It's really like do you need a relational database or do you need like a document DB? And I think for probably most people they convince themselves like I don't even need to consider a document DB. We're just going to go with a relational database. So not to say there is no place for them. But you the decision-m around this is almost never do you build your own, right? It's a database. Why would you build your own? But there probably are reasons. Right now, for probably most of us, for most of the applications and services that we'd consider building, do you actually need to build your own? Probably not. It would probably be way more effort. And we'll get into some of like the with a less of an exaggerated example like what that looks like to kind of do it yourself.

But are there situations where you may want your own database? And the answer in is perhaps yes, especially in highly specialized domains. I don't even know if off the top of my head I can like think of one because maybe before it was like well it's such massive scale right so massive that like we really need to come up with our own because nothing really exists that's going to do this properly and so like you do it and then you build it for the company and then it ends up being like some industry standard or something that other people can use right can you think of examples like that or I know at Microsoft like I work in uh Microsoft 365 side of the house and so they there is a a custom database there is a a jet database and that you know is

a proprietary format and like why well they build it because they had a special need for it in today like if someone was starting a new I don't know like mobile application or starting a new web service, is it likely that they'd go, hm, like I should go use a jet database? Like, probably not because it was, you know, designed for a very specific reason. And it's probably not likely that they're going to go build their own, but who knows? Maybe there still are these really special circumstances. And so I'm the reason I like this example is because there's a a guy that I I chat with uh on on LinkedIn posts or Twitter and stuff and like he's uh he's really really smart and he actually like on the side for some side projects was building some custom databases and I said databases plural not built his own custom database like built custom databases.

He was very interested in playing around with different storage techniques and how we could actually go make a database. And so I bet you like I don't off the top of my head I don't know but I bet you if I were to if he were right here sitting here and I said hey you know could you tell me a circumstance or like a situation a scenario why you would want to go build what you just did versus using you know SQLite right or Postgress we could talk about SQLite being something just a local data store very simple right it's like powers a lot of mobile applications on ice or something like Postgress where you know everyone's using it. You got two opposite ends here like very you know widely adopted. Why would you go build or use one of these custom databases like build your own like this?

And I bet you he could give you a big list of reasons. So the point is not that it never happens. It's just that it's not very common for something like a database. And I'm going to need one sec here cuz this is a crappy spot to merge. Get around this bus. Excellent. Okay, we're laughing now. Okay, so it's not that it's impossible. It's just kind of rare or pretty rare, especially for something like a database. But what else, right? Like a database is one thing. If you were to think about the different parts of your tech stack, there's so many different things that you could take off the shelf, right? Like you're probably I'm just going to make up some examples. You're similar to a database. You're probably not going to go invent your own source control, right? Probably not. You're probably not going to go invent your own bug tracker.

Probably wouldn't make sense. Uh, do you need your own uh, you know, front-end UI framework? Probably not, right? Could you go build your own custom JavaScript front-end framework? Probably. But there's a trillion of them. So, like, does it make sense to go do it? There's probably enough things off the shelf where the easy path is probably like, you know, 99% of the time you can pick uh components off the shelf and you're good to go build stuff. So, when does it make sense to go build it yourself? And I think when we have to make decisions like this, we have to think about the tradeoffs, right? A lot of the time if you're picking something off the shelf, what are you getting when you do this? Right? You're getting uh you know high for the most part high level of trust and confidence in something that is widely established, widely used uh for the most part has probably been around for quite some time, right?

It's you have I guess the best word I have for it is confidence. And confidence does not mean it's perfect. I think it's probably a mistake for people to, you know, call anything perfect, but especially when you're trying to rely on something for like infrastructure like a database, you probably want to have something that you're using where there's a lot of trust in it, right? Lot of confidence, a lot of trust in the technology you've selected. So that's one part. Um to add on to that, like if it's actively maintained, right? So, just to make up an example, if there was some database technology that was really good, right? And the last time it was updated was 15 years ago, I bet you like I don't know where the threshold is, but I bet you over time people would start to go, hm, like this is really good, but like I wonder, right?

Hasn't been updated in a long time. Maybe maybe it's so good that it just really hasn't had to. Buddy, this lane, it's not how you zipper merge. You're looking at your phone, dummy. Um, God. So, it's like some sort of recency around maintenance, right? Supported, like how well supported it is. It's probably a lot of that that's a big factor. And you get that for the most part when you're taking things off the shelf, right? If I said go use Postgress or go use Reddus, right? Like these are names that you've probably heard a million times because they are widely adopted, they are widely supported, they are actively maintained. So I think that's a really big part of it. The other part around maintenance got to let me in pal. Um the other part around maintenance is like this is where we might have a bit of a split decision is like you don't have to maintain it.

Pros and cons to that. But you know for something like Reddus, right? Like if you wanted to use a caching system like hey maybe Reddus is like a really good option because there's a lot of confidence you can have in it actively maintained. Give me one sec. Cool. Um, and then like because it's actively maintained, there's a community of people around it that are, you know, have vested interest in making this thing good, fixing bugs, adding features, improving it. So, what's good about that is like that's not you and your team doing it, right? you can focus on the other that's probably more relevant for your scenario, right? Your product, your service. Sorry, there's a bike that pulled up like right beside, but I guess they were trying to merge into the other lane. They awkwardly slowed down, so I didn't know what was going on.

Um, so you get that benefit. Now, what's a trade-off with that? Well, if it's something that's open source and you can contribute to it, you know, if there's some issue that you're experiencing, like maybe it's just a matter of like cool, like the code's available. You're able to go, you know, open a pull request and see if you can get that merged in. You could fork the code like you have some decision later on where like, man, there's this bike coming through. Look at this. How crazy is that? I'm assuming that showed up on the camera. I don't actually know. But that bike that just flew past was the same bike that I guess went to go weave in and out of traffic on the other end. But anyway, um yeah, if the code's available then like great, there's some flexibility there. But let's imagine now that you're taking you're adopting something, right?

Some product that's not open source. You don't have access to the code. Now, this benefit of like, hey, someone else is maintaining it. Great. What happens when there's an issue that's not being prioritized to fix and it's an issue that you're experiencing, right? It's blocking you and your team. And so, you contact tech support, right? there's some engagement with the developers and it's like cool like we'll add it to the backlog or you know you open a ticket and it doesn't even get reviewed or whatever like you can find yourself in scenarios where maybe you are blocked and trapped. So that is a possibility and depending on what you're choosing to adopt instead of build on your own like that's something to consider is is that a risk that is tolerable right and I think for a lot of things like just as an example

right picking postgress as a database picking reddus as a cache picking you know like the language you use are you going to invent your own programming language so that you have full control over what you're doing because you can't trust you know that the language maintainer for whatever language you pick is going to, you know, support having a a language that's not busted. Like, you're probably not doing that, right? For a lot of things, it is really low risk, but there might be things that you want to select because they offer some, you know, interesting type of performance or they they they work in some scenario that seems pretty unique to you. You might say, "You know what? This thing is kind of niche. It's great that someone else built it, but if we're going to really depend on this thing, like we might be kind of screwed." Come on, buddy.

Why are you switching lanes? There's no need. So weird. Um, I thought they just left their signal on, but I guess they didn't. They were just going slow and don't know how to switch lanes. Everyone's going around them. Something's going on. So, if you're like I'm kind of steering us to like this uh this conversation of like niche things, right? So, there's a benefit to other people building things for you, but that's a bit of a trade-off because if they're building it and they're maintaining it and there's not openness around it, that might start to create a risk, right? So, the benefit is that you don't spend resources on it, but the risk might be that you can't spend resources on it when you need to, right? And if you're going through these decisions like this is part of it is risk mitigation, right? Is that going to screw up development or like put your product or service at risk?

And maybe before I keep focusing on niche things, something that's worth bringing up is around security, right? This probably you could do a whole set of talks on just the security aspect of this kind of stuff, but you know when things are open source, right? people like the code is open which is great because people can look through it and find vulnerabilities to close out but it also means the code's open and if people find vulnerabilities and they don't close them out you have a lot of people that might be using something that's vulnerable but security is a big part of it right um the other flip side is if you're building it yourself are you going to do a as good of a as a community of people trying to support a technology that you will build it with uh with proper security. You might have the intention to but like again if you don't have a a community around it you know will will it genuinely be more secure?

We don't know. So when it comes to niche things though, right? So I think a decision or like a factor that you have to think about is if you're an engineering team and you are building a product or service one of the questions that I would I'm not saying it's like the the only consideration. It's almost like a litmus test is like is is the thing that we are trying to build in house do we expect that to be like our core technology? That's one of my litmus tests for this kind of thing because if the answer is no, then I would say you probably like not the only, like I said, not the only reason, but you're probably not better off building it in house then because once you build it inhouse, you should expect that you will be spending development resources on it. You're going to be maintaining it.

You're going to be fixing bugs. it's going to take more and more time. So, not only do you build the thing and you get it delivered and done and it's working, there is a tax. There is a tax to keep this thing maintained to add features to it like things like software is not from my experience, it's not just done at some point. So, even if you you have a library or whatever that you've built some technology, it's probably not just done. It's probably done to a point, but there's always more to do. So, if it's not going to be something that from a business perspective, you intend this team to be continuing to spend engineering resources on, I would say my litmus test is that's probably not something that you want to build in house, right? Um the the major reason for that is like is that it's a long-term investment and especially if that's going to be a core piece of technology that like is critical to whatever you're building.

But it's critical to what you're building, but you don't want that to be your your engineering wheelhouse. Like you're going to be spending a lot of resources on it. So not only to build, but to maintain. Do you really want to do that? I think probably not. Now, are there are there reasons why you might do it? I guess probably. Um, but probably need some uh some more concrete scenarios to actually like walk through something like that where it's like, okay, look, maybe we don't want this to be our core business, but um when we're evaluating the risks and the other sort of trade-offs that we're trying to make here, it might be worth it for us to spend the time and resources building the thing inhouse and then like consciously making a decision like and we probably need to spend a lot of engineering

resources uh like maintaining going forward like we acknowledge that and that is probably still a decision we would make given some other risks or some other you know trade-offs that we have to consider. Now, a challenge for me is like, can I think of a good example like that off the top of my head? I think, you know, I don't know if I can. Like, probably not cuz nothing's coming to me right now. I've been trying to think in the background if there's a good example. But my my point is like it's not that that is impossible. There very well there very well might be something where you're like, we just got to we just got to do this inhouse because it makes more sense for us to do. Um because you know um the the only open- source variants of this are like they still seem pretty new, right?

Um or there are open- source variants and they haven't been maintained or there's no open source but there's commercial ones and we don't want to be locked in. Right? So when it comes to building versus adopting, I would uh yeah, use that as a litmitness test. It's like, do you expect this to be some core tech? Now maybe we can flip the the framing around and say, cool. Okay, well that makes sense. What are some examples where you do want to build it inhouse, right? I think a lot of the time this comes down mostly to these niche scenarios. So, um, can I think of one that's recent? Like I think I don't know like the ones that kind of come to mind more uh generically are you know some of these big tech companies that basically started building things because they needed it for

the scale they were doing and then they said cool now that we have this we'll go um you know make it available for other developers to use right like kind of open source it there's a there's a configuration system that we use in uh our part of Microsoft and this is uh without going into the details of what it is um this is actually built for a specific product. So they had a need where they said cool we have you know this need for a configuration system and I don't know like I don't have the history so I don't know if they at the time were evaluating what's available for such a thing uh and maybe because I don't know there could be so many different things maybe in this case they're like well we don't want to given that it's a a running service

for this product we don't want to trust some you know third party thing whether it's open source or proprietary we don't want to trust it um there's too much risk given the scale for our customers and again I wasn't part of the decision I'm just kind of making this up right we we don't want to trust that or there would be too much risk that if there was something wrong with this that uh we don't have control over it or I don't know right like if uh if there was something malicious just in the code that the surface area for the impact of that would be too great, right? I don't know what the decisions were that went into that. But anyway, this team uh for this product and their service ended up building this configuration system.

And so they build this thing, they use it, and I guess over time, I don't know the full story of how it, you know, progressed, but this is now a configuration system that's used like over a tremendously wide surface area. So certainly not just uh you know, for this single product or service uh that was still very large. It's not just for that anymore, but it's like many many services. So, they ended up taking this thing that was like part of their tech stack and then going cool like this works so well for us, it should work well for others. And so, you can have this technology um in this case a configuration system that you basically turn into a product, right? So in this case, if it's used only internally, it's still like, you know, the the other products and services in Microsoft that use it, they're essentially customers of this of this team, right?

So this little maybe at one point little tech stack turns into something that keeps growing over time. They're adding features, maintaining it. They go, "Hey, this is awesome. Other people should use it." Now there's a team dedicated to it. And then this team grows over time. They take on a larger charter. And like really this thing that starts small turns into a a full-on, you know, entire piece of technology that lots of people depend on. So that's one example without getting into the details of like something at at Microsoft that I'm aware of that's like that. Um, and I think you have maybe a more natural opportunity for this kind of thing at maybe at larger companies where there's more teams. And I'm not saying it doesn't happen at small companies. You're not allowed to build your own thing or whatever.

I'm just thinking that there's probably more opportunity for it at bigger companies, especially when you have teams that make a decision to go build their own and you have a couple of different teams over this wider surface area that have built their own, whatever their own happens to be. Right? So just to make up an example, we'll continue on the configuration one, right? That one was real, by the way. But maybe there's a handful of people that or a handful of teams that have also built configuration systems, right? Maybe once upon a time this configuration system I was talking about didn't exist. But everyone needs to be able to flight changes, configure things, do experiments, and things like that. So, you know, team A does it over time. team B is like, "Hey, we need to be able to do that. They build their own." Right?

There there isn't a thing that we can use. We'll just build our own. And a bunch of them do it. My thought here is maybe at bigger companies there's more of an opportunity where uh when you zoom out and this like in part of the org, it's like wait a second, we have a few teams doing this like this is clearly a need, right? It's clearly a need because we we literally see it coming up from these teams and they face similar challenges, right? Like nothing uh you know, nothing good off the shelf or there's good stuff that's uh available off the shelf, but we can't use it for reasons x y and z. So we have teams building their own. So okay, well now we have multiple teams building their own. Like is that actually a good use of time, effort, resources? Maybe. in some cases and maybe absolutely not in a bunch of others.

So if that's the case, cool. We literally know that there's a use case for it. We know there's a need and we know there's teams spending, you know, multiple teams spending resources doing this. What if instead we worked on some type of convergence or unification strategy where let's not build three of these, five of these, 10 of these. let's take some, you know, resources from different teams and actually make a a V team or a dedicated offering to go, you know, build something that can be reused. And so I think this kind of thing probably happens a lot at big companies. I know that there's certainly examples of this at Microsoft. At smaller companies, I don't know.

Like I said, I'm sure it's not like uh they're immune to this kind of thing, but I think a lot of the time at smaller companies, um especially like startups and stuff, I would say if you're already like, man, there's so many things that we have to do, too many priorities, you're you're you're probably looking for shortcuts to get things developed in the first place. So going, hm, like we we we need to flight and configure things. You're probably for the most part looking at what's available and going even if it's not perfect, like I guess it's good enough, right? We'll just use it because we need to um cuz we have other to do. And so probably not gravitating towards like, oh, we didn't find the perfect solution. We'll just build our own. again, unless it's if it's aligning with a core part of what your your business strategy is, then maybe maybe you do go do that.

But anyway, I think that's how I would frame a lot of this. The the buy conversation is interesting cuz buy could look uh different at different scales, right? The buy consideration for technology could be like do we want to go buy a license for this type of thing or I don't know like you buy the the tech out uh once right it's a onetime payment so you could look at things that way and again that just gets factored into like your risk and cost analysis right so you either may need to spend engineering resources building the thing and then maintaining it you could take something that's off the shelf and it's free and like so what are the pros and cons of that or like is there a paid solution and if so like what are you actually paying for, right?

Like is it there's a good offering you pay for it and you get um a lot of support or you get dedicated support or um you know the open- source variation of it's not really that maintained but like the paid for one is like industry uh leading cutting edge. Maybe it's worth it to go pay for that. However, the other side of buy is depending like I said depending on the scale of things like do you acquire a company, right? like company A has some tech that is very interesting would be used heavily. So these decisions probably look a little different. So, for example, if you're like, "We need a database for our, you know, our product or service, unless it's a core part of your business, you're again, you're probably not going to go say, hm, we should go buy this company that has a database, right?

If you were making that decision, you'd probably consider buying that." Obviously, if the there's a lot of different factors here, but you probably wouldn't even entertain the idea unless it was a core part of your business where they had some type of technology offering where you were like, man, like that is something we want to make sure that we own. Probably not a decision. So when it comes to buying, it's likely not kind of convenience like uh oh, we need a configuration and flighting technology just so we can turn features on and off or run experiments, but hey, there's this company that makes a tech like that. We should just buy them. Like probably not because again from a business perspective like you need to spend time and resources and everything else to now literally go run this entire other business. So probably not the decision you're making unless it's for a piece of technology that's core to your business.

So can I think of examples like that? Sure. Um it's a lot more around product offering though and less around uh like purely around tech stack. Now let me see like so I used to work at a digital forensics company and so for example like they did a handful of acquisitions and so one acquisition uh was after I left and they they sort of did a merger acquisition with a uh a mobile forensics company. So like they have their own products, they have their own services, they have their own employees, right? Like they are their own company. And so you could make the argument that's a good acquis whether or not it's good or bad, not for me to say, but you know maybe one of the decisions is hey look if we acquire this company like we do get their you know sales, marketing development team, we get customer base, we have their product, their service, right?

Like this is a good business. But the other thing could be like, man, like look, okay, their products, maybe we don't I'm just making this up, right? Maybe we don't care about the actual uh customer base they have with their product, but their product has a piece of technology inside of it. We've been trying to build our own or we have built our own and we've been maintaining it and whatever else and like they just seem to have a superior one. So maybe we should buy them like buy their company just to own the piece of technology so that we don't have to you know buy their technology and I guess in in many circumstances like have their engineering team who is basically like you know solved this space or they're at least ahead in this space. So like we don't have to spend time and energy catching up.

we can spend money to be able to have you know the tech owned and then to have uh you know depending on whatever the deal looks like engineering resources everything else that goes along with it. So that's a different scale of like uh build versus adopt. It's uh yeah that's not something that's done lightly of course but you know that's a that's a consideration I think I the a recent video I was talking about outsourcing something right it was like this uh a combination of build it was let's build it but not inhouse so we'll build it and so that we don't slow our development team down we'll outsource it right so that's a different kind of trade-off Right? If we have to build it inhouse, that's going to mean that it's going to take our engineering resources. Okay? So, we won't do that. Instead, we will let our engineering resources focus on our core offering.

We will spend money so that we can do that in parallel. Now, maybe long-term you have to ask this question of like what does that look like long term? Because is that something that you continue to outsource the maintenance on? Is that something where like you're accelerating so you're like okay for now we don't want to spend the engineering resources but once we have the finished thing then we're willing to spend engineering resources to maintain it right so do you do that or do you you say no we got to build it in house in that example if you watch the the previous I don't know if it was the last video or a couple before but was talking through this uh this example And so in that case we outsourced it and then we we had to cut our losses and we actually did

build it in house and in my opinion that actually translated into like so like a little biased because I was one of the people who ended up building it in-house and managing it. Um but I think from a business perspective it made a lot of sense in the end because that was core technology. It was really valuable for us to to build that to own it and then not rely on other people for you know for fixing things or maintaining it. It was like no like having this in house is a a really good move for us because um because it's a critical piece of what we're doing. So to to generalize like all of these things, right? This always comes back to a pros and cons analysis. And I think that it's really important that you think through the tradeoffs and challenge yourself on it too because sometimes it might seem obvious right on the surface like why would we ever do that?

Isn't it obvious just to to go down this path? And like maybe not. Maybe it's obvious in some circumstances and if you've lived through a bunch of these experiences, you might default to like, oh man, just like like I was saying earlier, right? I just keep going to take uh MySQL as a database. Why? I don't know. I just default to it. Does it mean it's the right choice? I don't know. But for the stuff I've been building where I'm making that decision, it's not a critical aspect. But I need to be careful because I can't just keep defaulting to that because in the future that might not be the right choice, right? We have to think about like the constraints we have and then do pros and cons analysis. And you can do this for all sorts of things, right?

So whether it's the language you're using, whether that's within the language of the tech stack, whether that's the database, whether that's your cache, whether that's bug trackers, the operating system, like like whatever, all of these things are decisions that have a pros and cons analysis and go along with it. And so I think that that's a really key part of engineering. And I think that it's really important for people to to think through this kind of stuff, right? But yeah, I'm curious as I'm getting close to home here. I'm curious if other people have had experiences where they've they've gone back and forth on this kind of thing. Right. Did did you go down a path where you tried to build it yourself or the other way where you used something off the shelf? Was it paid for? Was it open source? And did you end up pivoting and going, "Nope.

Um, we got to do it ourselves." Right? Maybe um for some .NET developers, just to kind of throw this one out there, for some net developers over the past couple years, there are some some popular open- source libraries that um that went commercial. So, in some of these situations, there's like, you know, teams that have built, you know, huge offerings and they were using open-source libraries and then the maintainers are like, man, like, and you can disagree like all you want with it, like it's neither here nor there. because it's it's been done. So these open source maintainers for their projects were like it's basically a full-time job for me or in some cases like they were saying like they started resenting trying to support it cuz they're like I literally have a full-time job and like getting to this after is like it's so demanding and starting to resent it.

So they're like, "Cool, I'm going to commercialize it. Then I can do this full-time and focus on it." And then from their perspective, it's like, "I'm going to give this the proper attention, right? This needs more attention. I will invest my time into it and then do a better job." So what happens to all these teams, right? So in in some situations, it's like cool, like keep using whatever uh version is available. You can keep like you can fork the code. It's still open. Um, in some cases it's like cool, like for the next X time period or versions. This guy's on his phone. Good job, buddy. Um, you know, it's still going to be open source, but after this point, like, um, it's going to be commercial. So, like, in many cases, it's not like, oh, you're basically pay up right now. It's almost like a ransom.

Pay up right now or else you're screwed. Your product stops working. But in a lot of these cases, it's like, hey, like here's a here's a time horizon for you, and after some point, like you're just not getting any more updates, right? I'm going to continue to maintain, add features, fix bugs, um, for paying users. So, you know, obviously I feel like rightfully so, people are entitled to be pissed off by this. Um, just like rightfully so, I think the maintainers are entitled to say they can they can stop maintaining it or they can commercialize it, whatever. Like I said, neither here nor there. Some people were like, "Okay, like we're going to go build our own, right? We'll we'll show you. We don't need an open source one." Some people were like, "Cool, like it makes s like we've been using this uh we have a, you know, paid for product and service.

like we can we can actually afford to pay licensing fees for this. We'll do it. It's a it's a you know it's critical for us but we don't want to be the ones maintaining it, right? We will pay for the support. So they do. So I think there's some some interesting scenarios like that. And like I said, be curious to see if other people have any they want to share in the comments. But appreciate you being here. I'm just back into the driveway. So, if you got questions about software engineering or career development, please leave them below in the comments or you can go to codecommute.com and you can submit stuff anonymously. Thanks for watching. Take care.