The Conflict at the Heart of Open Source | Dr Dobb’s
▻http://www.drdobbs.com/open-source/the-conflict-at-the-heart-of-open-source/240168123
Je sais qu’il est préférable de sélectionner dans un texte... mais cet article est si remarquablement constrit pour être court et percutant que je le livre en entier aux seenthisiens.
L’auteur est le rédac chef de Dr Dobb, la plus ancienne revue californienne des hackers, avant même que le terme n’existe ;-)
Une lecture indispensable, qui remet réellement en perspective les débats internes aux tenants du logiciel libre.
Marcel Mauss le disait déjà il y a plus de cinquante ans : « le don de l’un ne doit pas devenir le capital de l’autre ».
C’est la véritable solution pour faire société.
A project’s choice of a license will have significant effects on its ability to sustain itself.
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
alb@drdobbs.com
Twitter: platypusguy
Google+
Update: This article originally stated that OpenSSL used the Apache license. In fact, they used an Apache-style license of their own.