The Real Cost of Open Source: Building a Responsible Adoption Strategy

My experience with open source software communities goes way back into the 1990’s. If you forced me to guess what year specifically, I’d probably say my first encounter with open source was in 1997. In the decades since that discovery, I’ve been actively engaged in open source as a consumer, contributor, and maintainer. My GitHub contains a small fraction of my activity over the years. I’ve founded new projects, some of which grew to have tens of thousands of users, others of which continue to be used almost exclusively by me. I was inducted into the Python Software Foundation as a Fellow in 2011. In other words, when it comes to open source, I have mountains of experience.

Communities vs. Corporations

Just today I was reading about a recent spat between Google and the open source FFmpeg project, in which FFmpeg maintainers asked Google to cease reporting bugs unless it paid to fund development. This may seem an extreme position to take, but it's critical to understand that FFmpeg is entirely maintained by volunteers. 

FFmpeg is particularly bothered by Google’s Project Zero (GPZ), which recently revised its Reporting Transparency policy. GPZ proactively searches for security issues in open source projects and then privately discloses any findings with project maintainers. Unfortunately, Google has taken a position that if a reported issue is not fixed within 90 days, it will disclose the issue publicly regardless of whether or not the community has developed a patch to close the security hole.

With the benefit of context, it's clear why the FFmpeg team are frustrated. FFmpeg is an absolutely incredible project that provides software and hardware-accelerated audio and video encoding and decoding. It is embedded in hundreds of open source projects and likely thousands of commercial products. FFmpeg is a load-bearing dependency for so many projects, commercial and free alike, that a major, unpatched security hole could cause widespread chaos, and potentially tens or hundreds of millions of dollars in damages.

Free vs. Freedom

Open source is frequently cited as being “free.” Setting aside the dozens of different software licenses with varying degrees of restrictions, open source is more about freedom than it is about being free to use. 

For consumers, that freedom can be exploited to add significant capabilities to products without having to develop them in-house. Often, companies treat open source projects like software vendors, reporting issues and expecting them to be fixed in a timely manner. The key difference is that consumers of open source are not customers, as open source projects are not commercial entities. Using open source software without “giving back” is certainly a freedom that is granted by most open source licenses. But that freedom is one of choice, not of consequence. Making an open source project a load-bearing part of a commercial solution saves time and cost, but it also comes with risks.

Responsible Adoption

For businesses, open source can be a powerful tool to accelerate time to market, provide new and interesting capabilities, and benefit from new features and ongoing development. But, it also exposes you to the realities of software developed in the open. Businesses would be wise to mitigate that risk, taking a posture of “responsible adoption,” which can take many forms. Here are just a few.

Funding

The lowest effort way to de-risk open source adoption? Funding. That funding can come in many forms, and most larger open source projects have ample documentation on how to financially support them, including the use of platforms like Open Collective and GitHub Sponsors. Depending on the project, you may also discover “bounty” programs which enable a direct financial contribution in exchange for a particular feature, fix, or improvement.

For open source projects, direct cash contributions can be very valuable, but they can also come with strings attached. Just this month, the Python Software Foundation rejected $1.5M of critical funding due to conflicts over core values.

Commercial Support 

Larger open source ecosystems often have commercial entities that specialize in offering code-level support. Sometimes these entities are dedicated to specific open source projects, where in other cases they provide a more broad coverage. The most commonly cited example of this is RedHat, who has been wildly successful in monetizing open source projects through commercial support.

Direct Participation

By far the best way to support an open source project is by directly participating. Hire full-time contributors that make the project better every day. Depending on the cost, this could be a slam dunk, where an open source alternative to an expensive and complex commercial product is still more cost effective even taking into account the salaries of full-time resources.

Learning More

This is a complex topic, with many considerations, and even more lessons from history. If you’re interested in learning more about effectively adopting open source software, I suggest picking up VM (Vicky) Brasseur’s book on the subject. I have known Vicky for years, and she is one of the brightest open source strategists you’ll find.