Open source is free - but expensive
Tags: opensource
Published: 2020-01-15 14:14:50

Source: https://xscode.com/686/open-source-is-free-but-expensive/

*While over 90% of software companies use free open source components, only a handful are actually aware of the hidden costs behind using “free” code. This article discusses the real cost of using open source in commercial software, the risks behind it and how they can be mitigated.*

The benefits of using open source components when developing software are clear. According to  Github ([source](https://www.forbes.com/sites/adrianbridgwater/2019/11/11/is-open-source-broken/#36089fe9d560)), over 90% of software companies use open source in their commercial software. Using ready-made components is cost-effective, speeds up development, and frees costly developer hours to focus on mission-critical tasks. Moreover, the ability to see the source code, rather than using closed-source proprietary software, exposes the development team to new ideas, technologies and solutions, which can later be implemented in their custom application code. But these benefits come at a price. Downloading the code is free, but actually using it in a mission-critical production environment - is often not. Diving into the usage statistics and analyzing the open-source time-value-spend relationship, reveals the true cost of free software.

A small clarification before we proceed - open source software is often referred to as ‘free software’ - where the word ‘free’ is used in the sense of ‘freedom’, not ‘free-of-charge’. For the sake of clarity, and as this article discusses mainly financial aspects, and not the legal and philosophical principles of open source, I will use the word ‘free’ in its traditional sense henceforth. If you’re interested in free software and what it means, I highly recommend reading [this](https://www.gnu.org/philosophy/free-sw.en.html).

> "Open source has grown from a small, academic sharing network to a giant, global web of dependencies. It now forms the backbone of the internet and technology in general. Just like any growing city, we have to coordinate the knowledge, infrastructure, and tools for the good of the whole community.” *Devon Zuegel, Github*

### Finding the true cost of open source

Let’s start by factoring in the direct costs of using open source in a commercial setting.

Since open source components are rarely ready to use out-of-the-box, there are direct costs that incur when integrating, customizing and maintaining them. According to a recent survey conducted by Tidelift ([Source](https://cdn2.hubspot.net/hubfs/4008838/Resources/The-Tidelift-guide-to-managed-open-source.pdf?utm_source=hs_automation&utm_medium=email&utm_content=66640714)), developers spend 35% of their time researching, testing and maintaining code. 25% of that time, revolves around open source code. With an average salary of $43/hour ([source](https://www.daxx.com/blog/development-trends/it-salaries-software-developer-trends-2019), in western countries), companies with 100 developers spend close to $1MM annually, just on open source ‘housekeeping’ tasks. This doesn’t include time spent on finding the right project for the task at hand, learning about the project from the usually scarce documentation, customizing, integrating it into existing code etc. The real cost is likely closer to double the figure we just saw. That is an astonishing figure, even for multi-million dollar companies. And those are just the direct costs. Other, indirect costs should be factored in as well, such as legal and security risks, management overhead, purchasing of software tools to manage open source components and the lost time that could be directed towards other, more critical tasks. This huge expense hides in plain sight, embedded deeply in development expenses, and very difficult to catch, let alone - reduce.

> “The true heart of open source isn't the code at all: it's the community. Projects with a strong community survive longer and are adopted much more heavily than those that don't. With that in mind, it's a good idea not only to embrace but actively plan for the community you hope to build around your project.” *Jim Salter, Opensource.com*

## Is using open source a risk?
![Is using open source a risk](https://xscode.com/wp-content/uploads/2020/01/1_IybTrI6ds_yQszpagkI6qg-768x386.jpeg)
Research ([source](https://www.xfive.co/blog/5-open-source-security-risks/)) indicates that developers using open source components are concerned with how well the code they are using will be maintained in the future. Unmaintained, and even abandoned projects are not uncommon in the open source ecosystem, and can cause severe damage to companies relying on them in a production environment. Imagine relying on a Github repository for your code builds, and suddenly the developer decides to remove the repository from Github, or make it “private”? This has happened before, and will happen again, creating a real risk.

The open source [sustainability](https://github.blog/2019-01-17-lets-talk-about-open-source-sustainability/) problem has become the subject of many discussions, [forums](https://dev.to/bureado/open-source-sustainability-is-a-debate-37p1) and [blogs](https://techcrunch.com/2018/06/23/open-source-sustainability/). It has become a major concern for everyone developing and using open source, and it appears that software companies and open source developers alike, are starting to understand that the continued growth of open source is at risk, unless a viable business model is created to provide developers with a continued incentive to better maintain their code.

Some of the largest organizations in the world are looking for maintainers to hire just for maintaining the open-source projects they are using. Other companies choose to donate to their favorite projects. This sounds like there’s a solution for open source issues, but these two solutions apply only to about 1-2% of the open source projects out there. The other 99% of the components are maintained by individual developers, who are not compensated at all to support their work. Companies are finding themselves building products that rely on components, created by people who might not be here tomorrow to maintain the code, fix bugs or resolve security issues.

## When pros become cons

Organizations that develop software invest a lot of resources in hiring, training and keeping their software developers happy and committed. But if your organization is using open source components, developed by individuals you don’t know, never hired and never paid, how can you trust the quality, support and continuity of their code?

Open-source developers start their projects for many reasons: a need that came up, personal interest, recognition in the community and more. Developers want to share their knowledge with the community and hope their project will gain popularity and a following. Some projects do so well in terms of popularity, that developers become **the victims of their own success**. When an open source project suddenly explodes, it generates enormous stress on the developer. He is suddenly bombarded with bug fixes, features requests, questions and comments. At some point, the developer can’t continue to invest the required time and effort in maintaining his project. Sometimes this means less maintenance, unfixed bugs, or new releases that are postponed until the developer has time. In some cases - this means project abandonment. In both cases - the headache to maintain the project becomes the company’s. 

## Paying open source developers is trending

Although I can't support this notion with hard-numbers, browsing through social media pages and blogs which are popular with developers, is showing a trend. More and more developers are realizing that in order to continue developing their projects, they would need ongoing, reliable financial support. It appears that asking for donation is not a viable and dependable business model, and some developers have resorted to monetizing their code in a variety of ways. One option, is offering their code under dual licensing, where a restrictive licensed version of their code remains free, while a permissive licensed version is offered for-fee. The developer of Vue-tables-2 (link), a popular Vus.js library, did just that, and looks like its working for him. Another widely popular library called FUSE, also decided to 'close-off' the code and license it commercially ([source](https://www.theregister.co.uk/2019/12/16/fuse_macos_closed_source/)).

This trend is likely to grow, and the sooner software companies understand that it is in their best interest to start paying the open source developers behind the code they use - the better it will be for all of us, users and developers alike.

## What’s next

Open source is here to stay. It became so widely used, that it is improbable software companies would stop using it, as the benefit outnumber the problems. But something needs to change. If the software industry and the open source community won’t find a viable, sustainable way of developing, using and paying for open source - it might not be here tomorrow. At least not in the same volume it is today. Platforms like Github are incredible, in the way they facilitate the distribution, development and adoption of open source. But companies need something more. They to be able to connect with the developers who create the code they use, so meaningful and profitable relationships are created. The same process that happened with many large scale open source projects like Redhat, needs to happen with smaller-scaled projects. The same way Redhat is offering paid support and added value services to a free, open source Linux distribution, should also apply to the +30M open source projects used by everyone. Where there would be compensation - the will be motivation. Compensated and motivated developers will be the ones leading open source into the next decade.

Netanel Mohoni, CEO, xs:code.

Want to learn more about how companies can buy products and services from the individual developers behind the code they use? Check out [xscode.com](https://xscode.com)