Don’t get me wrong, I love open source. Like many others, I make a living using and building upon it. No one should need to write a new operating system for their brand-new computer or worse – build such a computer from scratch. However, picking software only because it’s a popular open source project might not be the best decision.
There’s a spectrum between the NIH syndrom and avoiding building an in-house solution with a revolutionary zeal. Not surprisingly, most people are closer to the later stance. Yet, sometimes we fail to evaluate it just like any other off-the-shelve tool.
Here I mostly think about infrastructure deployed in production. Most likely in a business environment that expects ownership, SLAs, on call etc. But it might be applicable elsewhere as well.
The most common assumption I see, is that if there’s an open source solution available, there’s no need to reinvent the wheel and build something from scratch. It’s a practical approach, however, prone to a mistake of picking something that almost fits the bill. Adopted software should match the existing technical stack to avoid constructing a Rube Goldberg machine.
Similarly, decisions should be made considering the problem at hand and – if known – the future needs. Anything extra is a nice addition, but shouldn’t be a major consideration. Especially, if more features mean more expensive adoption.
Speaking of which, open source is often chosen over building anything in-house because it’s perceived as being cheaper and faster to deploy. That’s usually true, however, it can cause a last mile problem when it comes to integration it with the existing systems. Everything goes smoothly up to the point of productionizing operations.
I’ve seen it typically with monitoring, logging, and remediation. Even if there are hooks built-in, they may require either a specific stack deployed or implementing a new interface. Every so often, you get lucky and things are going to work out of the box. But typically, you won’t.
In theory, you can fix all the issues by writing some code and submitting a patch. It brings a good feeling, not only do you solve your issue, you also help others. That’s how open source should work. However, when company lawyers don’t allow you to contribute, your patch doesn’t get accepted, or it’s tightly coupled with a proprietary system, there’s no much left – you need to fork.
It’s ok. Forking is not scary, and I believe that it should be fully embraced by the organization if necessary. Especially if the software it’s related to the core business. But it comes at a cost. Rebasing, merging, setting up test and build infrastructures, those things don’t come free and the price is paid forever.
And even if you don’t fork, upgrading might become a chore. Projects evolve, change configuration formats, dependencies, interfaces, etc. Using someone else’s code is not deploy and forget, but rather signing up for a long-term responsibility. Everyone who had to go through a major CentOS upgrade knows what I’m talking about. He that hasn’t seen an ancient version of a crucial software in production may cast the first stone.
Each next revision may require more effort to upgrade. Software tends to grow over time as it solves more problems. Once again, that is a good thing, but it might increase cost of ownership, and it’s hard to justify the effort for features that are not needed or worse – require more resources.
I don’t aim to be a contrarian telling you not to use any open source software whatsoever. On the contrary, I will do it myself almost every time. But I’d like to encourage you to consider these points, and maybe more, every time you plan doing that. Choosing an open source solution is not a magical free way of solving a problem. Ask anyone who maintains old infrastructure (or any Java Script developer).
Building something in-house, tied to the exact needs of the organization, modified only when needed, and with expertise within the team, might be a better option. Of course, every time you consider doing just that, you should run a similar evaluation. Having a designated devil’s advocate in the room always pays off.