Hidden cost of open-source

Companies and startups, in particular, are usually looking for savings and therefore software offered free of charge is the natural choice for them. Open-source software is free of a license fee, yet it doesn't mean that using it is completely costless. How expensive it is? As always - it depends and precise calculations required in-depth knowledge of the company and the development team. Still, let's take a closer look at the cost drivers leaving out the precise calculations.

Open-source landscape

It isn't easy to assess the size of the open-source landscape, yet let's take a look at some sources that may give you a feeling of its magnitude.

A search on GitHub¹ reveals that there are over 44 million publicly available repositories. CNCF's landscape² reveals the following picture:

CNCF Landscape (2022)

The number of projects on the CNCF's landscape is huge and the search result from GitHub is simply overwhelming. The situation has pros and cons: on the one hand, if you need a solution to a problem, most probably there is a project that solves it, on the other hand, choosing or even finding an appropriate project may not be easy.

Learning curve and integrations

When the projects to use are chosen all that's left is to start using them. Usually, there are some examples provided on projects' pages. More and more contributors also take care of documentation as these days there are lots of options to introduce it easily and cheaply. Unfortunately, that's not always the case and in such cases, there are only a few options to learn how to use the technology: trial and error method, debugging the code, and asking the community. This can be ineffective in case there is a small community or the problem is hard (edge cases, specific requirements, etc.) and there is only a small group of core contributors with relevant knowledge.

In the case of well-driven projects (usually founded by a bigger organization) the documentation and examples may be exhaustive, yet in this case, the amount of reading may be significant and the learning curve usually is steep.

Another dimension of complexity is added by necessary integrations. In isolation technologies usually behave as intended by the authors, yet in integration scenarios, side effects start to play a significant role: different versions of the same library, contradicting requirements, unwanted behaviors, etc.

All mentioned challenges can be fun to solve, yet it takes time and often leads to an extra cost of infrastructure related to mistakes in configuration. Not to mention downtime or misbehavior related to an inappropriate setup.

Infrastructure and maintenance

Open-source projects can be shipped as simple libraries or applications requiring hosting. In the latter case, it may take significant resources to run it: starting with infrastructure and ending with human costs. If the dependency must be up and running 24/7, the DevOps team needed to maintain it may be big in number and may lead to significant costs.

Legal aspects

Large organizations spend significant amounts to keep an eye on license requirements of third-party technologies that are in use. Startups (or smaller organizations) tend not to pay too much attention to that aspect. As long as the company is small and has little visibility in the market, this may be justified, yet at some point, it may become a significant risk for the company:

• if there are limitations in the use of a library, it may have to be replaced by proprietary software or in-house implementation,
• if there is a viral license in place (for example GPL) company may be forced to open-source their software too,
• custom licenses may lead to additional, non-standard obligations that must be monitored and respected.

Licenses may become a problem in the case of:

• the commercial success of a shipped product - it is relatively easy for competitors to prove illegal use of software and exploit its implications,
• due diligence process led by a VC fund may reveal violations and in turn, may lead to withdrawal from the investment.

Summary

Even though open-source software has many advantages beyond the cost factor:

• the code is ready-made and can be used immediately thus reducing the time to deliver,
• the code is usually well-tested and battle-proven,
• the community is usually helpful and responsive,
• everyone can contribute to the codebase to fix issues,

companies should consider the cost that isn't visible at a glance.

In general, I would avoid using open-source in the case of:

• very small libraries offering trivial functionality that can be implemented in-house - this way we avoid a dependency that must be maintained,
• projects with little community or poorly documented - in case of problems hiring a consultant may turn out expensive (if available at all),
• there is a hosted solution offered that has a similar cost (compared to the resources we would have to use internally) - in this case, we gain SLAs and access to support that can lead to significant savings in case of issues.

Last but not least, this post is not to criticize open-source as a whole. There are lots of great companies that emerged from the community or are built on top of community-provided solutions. Choose smart!

Yours, Wojtek

Footnotes

1. GitHub, access: 2022-11-25 ↩

2. CNCF Landscape, access: 2022-11-25 ↩