Channels ▼

Open Source

The Conflict at the Heart of Open Source

Despite the rivers of ink that have flowed regarding the recent Heartbleed vulnerability, I believe the developer community has not addressed the right problem. Developers have fixated on a debate about one of open-source's most touted advantages: With many eyes looking at the code, is open source able to correct bugs faster than closed-source projects?

But this discussion misses the central issue, which in my view is not technical, but monetary. The OpenSSL team, whose project was the home for the Heartbleed vulnerability, discussed with remarkable candor how much the lack of funding from the product's users has limited their development work and, by extension, their ability to find and remediate such defects. It turns out that major users of OpenSSL, such as Cisco and Google, among others, had incorporated the software into the important products, but sent little or no funds to the developers.

Faced with this embarrassing revelation, the companies quickly got together, pooled some money, and assembled a committee that agreed to dispense funds to worthy projects, starting with OpenSSL. This is a hurried patch — one that will temporarily relieve the problem, but not address its root cause.

The root cause is a fundamental conflict at the heart of open source: the opposing forces of building community vs. deriving a sustainable level of revenue from an open-source project.

The tension between these forces is most acutely felt when choosing a license for the project. Projects that have a greater interest in fostering use of the software or projects that don't care about much about monetization choose the "business-friendly" licenses (such as the Apache Software License, MIT, BSD), which impose nothing but the most minor responsibilities on the user or, more correctly, the licensee.

Projects that look for revenue to sustain themselves often choose the so-called "copyleft" licenses, (GPL, AGPL, etc.), which require that the licensees open their source code under a similar license. The revenue benefit for the project comes from the ability to offer alternative licensing terms to licensees that prefer not to disclose their source code. This arrangement is referred to as commercial multi-licensing. It's a model that works well. MySQL, Qt, and BerkeleyDB are among many examples of such projects that drove their parent companies to be successful businesses.

There is unfortunately no license to straddle the business-friendly vs. copyleft divide. As a result, projects that need a revenue stream to sustain them but opt for a business-friendly license to develop a community face significant difficulties. This was the case with OpenSSL. The team chose an Apache/BSD-style license. This successfully built community but, it turns out, communities simply do not pay for their tools. Even well-heeled users, such as Cisco and Google, don't pay. In the OSS community, this is viewed as no accident, but a matter of policy.

For example, I recently attended Black Duck's Open Source Think Tank, where OSS cognoscenti gather once a year to discuss the business of open source. Among the many discussions was one regarding Google's steadfast refusal to pay for OSS software it uses. Several participants reiterated their experience in this regard, all of which were consistent. While the search giant open sources some of its tools and garners considerable marketing value from sending summer interns to high-visibility projects, the company won't do the one thing projects most need: support them monetarily. It's policy.

It seems that the projects caught in the community vs. revenue bind could find alternate source of funding: paid support, consulting, etc. If you look at the OpenSSL blog post I linked to earlier, though, you'll see the project did all these things and still garnered only insignificant revenue. The service/support model, which appears to be so widespread, is in fact a meager revenue stream. (To wit, VCs long ago stopped funding start-ups based on this model, although the occasional exception occurs.)

Unless there is some seismic shift due to Heartbleed, the problem is going to get worse. There is now a distinct strain in the OSS market that advocates loudly for non-viral licenses. The growing view is, amazingly, that the viral licenses are somehow less in the spirit of open source ("not 100% open source"). This is a rather imaginative perspective, as copyleft licenses (a much better term than "viral") were purposely designed to increase the amount of free, open-source software.

My concern is that if this view becomes widespread and copyleft licenses are heavily disfavored, the fundamental nature of open source will change. Small teams of innovators, à la OpenSSL, will no longer be able to create value and be sustained by skill and innovation. And so, one of the most important feeder streams to the open-source ecosystem will disappear — a victim of corporate users' unreasonable refusal to help pay to support projects from which they derive substantial revenue.

— Andrew Binstock
Editor in Chief
Twitter: platypusguy

Update: This article originally stated that OpenSSL used the Apache license. In fact, they used an Apache-style license of their own.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.