Why you should open-source parts of your technology stack

Kevin Goslar
6 min readJan 12, 2021

Developing software infrastructure that doesn’t add business differentiation as open-source is faster, more cost-efficient, and leads to better results than keeping it proprietary. It also allows more focus on business-critical software.

The physical world that we live in defines our paradigms, how we think about business and trading goods. If one owns a material item, let’s say a bagel, and gives it to somebody else, one doesn’t have it anymore. Making the service of giving bagels to others sustainable — turning it into a business — requires receiving something of equal value in return, for example, money, so that one can make more bagels.

Unlike bagels, software is information. Information behaves substantially differently than material objects. To understand how producing software differs from producing physical goods, let’s follow the journey of two software developers.

Alice owns and operates a small chain of bagel shops. Being a geek, she is in the process of building a Bakery Operations Software System (BOSS). This application helps her predict the demand for bagels in the next couple of days, automatically orders ingredients while minimizing cost, and schedules when to make which batch of bagels to always have enough variety of fresh product while reducing waste. The diagram below illustrates the different parts of BOSS.

components of the BOSS system

Most of BOSS is just boring infrastructure for running a bakery. Alice sells the same number of bagels whether she stores her recipes in her old recipe book or BOSS’s modern recipe database. The same goes for how her bakeries manage and order ingredients. Importing sales data from the point-of-sale (POS) system in her stores is also more a chore than a competitive advantage; doing it faster is nice but doesn’t move the needle for her business. And even an intern can create and follow a schedule when to bake each type of bagel to have enough of them ready at a specific time. A software solution makes all this more efficient, and that’s why Alice builds BOSS. But what makes a difference to Alice’s bottom line are her amazing recipes, her great customer service, the sales in each of her locations, and always having enough — but not too many — fresh bagels available. Alice’s AI-based sales prediction models can help with that, so they are valuable IP in this context.

If Alice keeps the entire BOSS system proprietary, only she can use it. But then she also has to shoulder the full development cost. It will take a while to build and polish such a comprehensive system, and a decade to break even on the full cost to do so. Building this as a fully proprietary system would be a poor business decision. Alice could try to license BOSS to her competition but that market is relatively small, and then she will have to build a much more comprehensive solution and spend most of her time building features that she doesn’t need but her clients want, and providing customer support. Alice wants to remain a baker, the BOSS software is just something she needs to run her business better.

Despite some people calling the idea crazy, Alice decides to develop most parts of her BOSS system as open source. She publishes pretty much all code except the AI-based sales prediction modules. An initial surprise is that Alice doesn’t lose anything. Unlike a bagel that is forever gone when given away, Alice can share the BOSS source code and still use it herself. Her software inventory and balance sheet are unchanged after open-sourcing her code.

But soon, amazing things happen. Alice starts receiving bug reports and bug fixes from other BOSS users. Other people help battle-test the application, for free. This eliminates problems before they affect Alice’s business. She also receives lots of positive feedback as well as ideas for improvements. Bob, the owner of a bar on the other side of the world, contributes several modules to predict beverage sales and order soft drinks to the BOSS codebase. This was a sizable item in Alice’s backlog. Now she gets this feature from a stranger, for free, a year sooner than she would have gotten around to it herself. Over the next months, more people contribute code to import more public events, support for perishable ingredients, real-time backup that improves the system’s robustness, and UI improvements for tablet-sized displays.

By giving the non-critical parts of BOSS away, Alice ends up with a better and at the same time cheaper system that becomes production-ready faster than a proprietary solution. Alice can now focus more on the important parts: improving sales predictions and developing new bagel recipes through A/B testing. The open-source BOSS project breaks even faster than its proprietary counterpart would. Open-sourcing parts of her non-critical software is a sound business decision for Alice.

Why does Bob contribute an entire beverage solution for free to Alice’s codebase? Bob wants to automate the operations of his bar as well. While researching solutions, he finds Alice’s open-source BOSS system. It has a lot of useful functionality out of the box. All that is missing are a few beverage-specific modules. Adding them into BOSS is much cheaper than building an entire bar management system from scratch. Bob gets a working solution done in a month. Since this costs him real money and time, he initially keeps the beverage modules proprietary. But each time Alice releases a new version of BOSS, Bob has to add his beverage modules back into it. This gets old quickly. When Alice changes the plugin API, Bob’s modules break and he has to rework them. Looking for a better way to do this, Bob realizes that automatic beverage ordering isn’t much of a differentiator for his business. Bob makes money by having a full bar until late in the evening, not from having a more automated interface to his beverage supplier. Once Bob contributes his module to Alice’s BOSS system, all new versions of BOSS come with the beverage module out of the box. Upgrading BOSS is now seamless, and maintaining his installation costs him less money, time, and headaches. And now other developers improve the beverage modules for free. Open-sourcing his beverage module is a sound business decision for Bob.

The economic advantages of open-source aren’t limited to bars and bakeries. Many businesses share code that isn’t a critical differentiator for them. Facebook open-sources its entire data center technology, a high-performance database, and their revolutionary frontend, API, and server technologies because Facebook makes money with ads, not IT infrastructure. Google open-sources its industry-leading AI stack, cloud stack, and scalable build system for the same reasons. Apple open-sources its state-of-the-art compiler infrastructure because they make money with hardware and services, not compilers. Netflix open-sources its groundbreaking micro-service DevOps toolchain because they make money with movie subscriptions. These companies understand the economy of software. In all given examples, the respective businesses benefit tremendously from open-sourcing their enabling technologies.

Most of the infrastructure of your business is also not a competitive differentiator. By open-sourcing its interesting parts, you reduce development and maintenance costs and compress timelines while improving the quality of your infrastructure. You become a technology leader. More products get built in a format that is compatible with your infrastructure, more people know (and love) your technology stack and are easy hires. A nice side effect is that doing good for the world by sharing innovation improves morale in your company and attracts better developer talent.

Most of your technology stack is already available to your competitors: all SaaS products you use, the hosting, Infrastructure-as-a-Service, and Platform-as-a-Service layers of your architecture, all the open-source operating systems, databases, programming languages, server frameworks, and libraries. Some of your code might make sense as open-source as well. Most of your business logic should probably be inner-source. Your business secrets remain proprietary. You can license this proprietary IP to your open-source users through an open-core model.

license for architecture layers

--

--