When you're making technology choices when you're starting to build an application, or as you build an application, there are really kind of two classes of choices that you make. The first is big infrastructure choices. These are the ones that you make relatively infrequently. It's things like, "Where am I going to run my application? Which cloud provider am I going to use? What programming language am I going to use to write the software in?"
And then there's the class of much more frequent and much sort of smaller stakes choices such as, "What library do I want to use to sort of parse these particular files? What library do I want to use to talk to a specific API?" Teams are careful to put a lot of effort into big infrastructure decisions, like, "What web frameworks should we use? What language should we use?" But that's not the only third party code that software development teams use. They will also in the end, by the time an application is built, have hundreds or even thousands of open source libraries that they're using. And almost by necessity, because of the scale of those dependencies, there's not the same process care and procedure put into selecting individual libraries. Often those decisions are made by individual developers.
As you get a starting list of software that you might consider using, you're going to look at a few different things. The first and easy thing to check is, "Is the software licensed in a way that I can use it?" For example, if I'm building software that I'm going to distribute, and I'm wanting to use a library that's under the GPL, and I'm not willing to distribute the source code of my application, that's the thing that I can't actually use. And then after that, you want to look at, "Is this something that is actively maintained? Are there people that are still working on this library or has it been abandoned? Is it one person on their weekends and as soon as they get a new hobby nobody's working on this thing anymore? Or is there a thriving community around it? Or have they built some way for the package to be sustainable in the long term."
So that's the maintenance dimension. And that's more important than popularity, you know, like GitHub stars or something like that. More important is do they have a way that they're going to keep maintaining this. So it's very rare that you're going to find the perfect case, that you're going to find something that checks all of the boxes that you care about. In those circumstances, you've got a few options, you can choose to go with an imperfect choice, you can just use it as is and, you know, work around it in your own applications code, you can choose to make the changes that will make it sort of match what you want. In that case, you can contribute them back to the upstream project, or you can kind of maintain a fork of your own. Or you can decide that maybe I'm not even going to use any of the open source choices and just build something to use yourself and your application. You won't have just enough process, enough checklists, some systematic way of making sure that you're reviewing the basics on every package that you adopt.
50 Milk St, 16th Floor, Boston, MA 02109
