Reflections on Buy vs. Build
blog.dominodatalab.com
blog.dominodatalab.com
- Using open source is a completely different choice from the build vs. buy (false) dichotomy. Open source lets you have full control of your future, while not needing to write all the code yourself. It's a best of both words scenario that'll only create more problems than the alternatives if you have licensing incompatibilities.
- Yes, engineers are biased towards "build". And executives are extremely biased towards "buy". Keep both in mind. I've lost count of how many times I saw somebody spending 6 figures buying some software that didn't solve the problem, just by having the problem solved later by a single engineer working less than 6 months on it.
- Yes, most of the cost of any software is maintenance. That true for buying as well as building. Except that you can be sure that maintenance of built software goes to making it better, on brought software that varies a lot (know your suppliers).
- Finally, that doubt about buying software that sustain your core domain... If you can buy software that solves exactly your core domain, are are on the wrong domain.
Open source allows the product to modified or extended per your needs. You can contribute back your enhancements, if you don't want to maintain them forever. This has been done several times.
I disagree, and I say this as one of the maintainers of a decently popular open source project (https://www.fluentd.org)
It's true that open source allows you to tinker and that it lets you jump start your project. But as you point out yourself, a huge part of your software cost is maintenance, buy or build, open source or proprietary. The reason why open source is great is that as long as you can avoid forking the project, you can reduce your maintenance cost by leveraging community contributions and support.
However, the flip side is that you do not have full control: the community often has different needs than your own, and it's not always easy to convince the community so that the open source project caters to your needs. This is double true if you are _just_ a user.
The alternative of course is to create a fork and either take it in-house or try to get the community to rally behind your fork. In either case, you either lose the community's support entirely or reduce its effectiveness, and the same question/burden of long-term maintenance strikes you back.
And, of course you can get dependent on some open source code that you don't have enough resources to fork. But that again is strictly better than either buying or building, because you wouldn't be able to build it anyway, and it still gives you much more control than buying.
A solution you build yourself costs more than just the time of the engineer to build the first version, the work revolving around maintenance and improving it, when that could be borne by an outside company, could be quite high. Also, when an outside company makes it, they can amortize the cost of a new feature across multiple customers. And people will often build things that work with that product, saving you even more effort.
The cost of buying though, is also of course not just the money you pay (free and open source still have a significant cost). How complex is the bought system vs the one you would build? How hard is it to replace with something else? How well tested is it? I've done the 'buy' approach with some open source things and services before and super regretted it when it took longer to debug than writing my own and maintaining it would have.