Open Source in 2019
21 years in, the landscape around open source evolved a lot. But is, “open source” enough? According to Thierry Carrez, VP of Engineering at OSI Affiliate Member OpenStack Foundation, open source is necessary, but it is not sufficient. In this post he’ll detail why.
Why open source is necessary today
What open source is
Free software started in the 80’s by defining a number of freedoms. The author of free software has to grant users (and future contributors to the software) those freedoms. To summarize, those freedoms made you free to study, improve the software, and distribute your improvements to the public, so that ultimately everyone benefits. That was done in reaction to the apparition of “proprietary” software in a world that previously considered software a public good.
When open source was defined in 1998, it focused on a more specific angle: the rights users of the software get with the software, like access to the source code, or lack of constraints on usage. This straight focus on user rights (and less confusing naming) made it much more understandable to businesses and was key to the success of open source in our industry today.
Despite being more business-friendly, open source was never a “business model”. Open source, like free software before it, is just a set of freedoms and rights attached to software. Those are conveyed through software licenses and using copyright law as their enforcement mechanism. Publishing software under a F/OSS license may be a component of a business model, but if it is the only one, then you have a problem.
Freedoms
The freedoms and rights attached to free and open source software bring a number of key benefits for users.
The first, and most-often cited of those benefits is cost. Access to the source code is basically free as in beer. Thanks to the English language, this created interesting confusion in the mass-market as to what the “free” in “free software” actually meant. You can totally sell “free software” — this is generally done by adding freedoms or bundling services beyond what F/OSS itself mandates (and not by removing freedoms, as some recently would like you to think).
If the cost benefit has proven more significant as open source evolved, it’s not because users are less and less willing to pay for software or computing. It’s due to the more and more ubiquitous nature of computing. As software eats the world, the traditional software pay-per-seat models are getting less and less adapted to how users work, and they create extra friction in a world where everyone competes on speed.
As an engineer, I think that today, cost is a scapegoat benefit. What matters more to users is actually availability. With open source software, there is no barrier to trying out the software with all of its functionality. You don’t have to ask anyone for permission (or enter any contractual relationship) to evaluate the software for future use, to experiment with it, or just to have fun with it. And once you are ready to jump in, there is no friction in transitioning from experimentation to production.
As an executive, I consider sustainability to be an even more significant benefit. When an organization makes the choice of deploying software, it does not want to left without maintenance, just because the vendor decides to drop support for the software you run, or just because the vendor goes bankrupt. The source code being available for anyone to modify means you are not relying on a single vendor for long-term maintenance.
Having a multi-vendor space is also a great way to avoid lock-in. When your business grows a dependency on software, the cost of switching to another solution can get very high. You find yourself on the vulnerable side of maintenance deals. Being able to rely on a market of vendors providing maintenance and services is a much more sustainable way of consuming software.
Another key benefit of open source adoption in a corporate setting is that open source makes it easier to identify and attract talent. Enterprises can easily identify potential recruits based on the open record of their contributions to the technology they are interested in. Conversely, candidates can easily identify with the open source technologies an organization is using. They can join a company with certainty that they will be able to capitalize on the software experience they will grow there.
A critical benefit on the technical side is transparency. Access to the source code means that users are able to look under the hood and understand by themselves how the software works, or why it behaves the way it does. Transparency also allows you to efficiently audit the software for security vulnerabilities. Beyond that, the ability to take and modify the source code means you have the possibility of self-service: finding and fixing issues by yourself, without even depending on a vendor. In both cases that increases your speed in reacting to unexpected behavior or failures.
Last but not least: with open source you have the possibility to engage in the community developing the software, and to influence its direction by contributing directly to it. This is not about “giving back” (although that is nice). Organizations that engage in the open source communities are more efficient, anticipate changes, or can voice concerns about decisions that would adversely affect them. They can make sure the software adapts to future needs by growing the features they will need tomorrow.
Larger benefits for ecosystems
Beyond those user benefits (directly derived from the freedoms and rights attached to F/OSS), open source software also has positive effects to wider ecosystems.
Monopolies are bad for users. Monocultures are vulnerable environments. Open source software allows challengers to group efforts and collaborate to build an alternative to the monopoly player. It does not need to beat or eliminate the proprietary solution — being successful is enough to create a balance and result in a healthier ecosystem.
Looking at the big picture, we live on a planet with limited natural goods, where reducing waste and optimizing productivity is becoming truly critical. As software gets pervasive and more and more people produce it, the open source production model reduces duplication of effort and the waste of energy of having the same solutions developed in multiple parallel proprietary silos.
Finally, I personally think a big part of today’s social issues is the result of artificially separating our society between producers and consumers. Too many people are losing the skills necessary to build things, and are just given subscriptions, black boxes and content to absorb in a well-oiled consumption machine. Free and open source software blurs the line between producers and consumers by removing barriers and making every consumer a potential producer. It is part of the solution rather than being part of the problem.
All those benefits explain why open source software is so successful today. Those unique benefits ultimately make a superior product, one that is a smart choice for users. It is also a balancing force that drives good hygiene to wider ecosystems, which is why I would go so far as saying it is necessary in today’s world.
Open source is not enough
The relative victory of open source
Open source is everywhere today. It has become the default way to build and publish software. You can find open source on every server, you can find open source on every phone… Even Microsoft, the company which basically invented proprietary software, is heavily adopting open source today, with great success. By all accounts, open source won.
But… has it, really ?
The server, and by extension the computing, networking, and storage infrastructure, are unquestionably dominated by open source. But the growing share of code running operations for this infrastructure software is almost always kept private. The glue code used to provide users access to this infrastructure (what is commonly described as “cloud computing”) is more often than not a trade secret. And if you look to the other side, the desktop (or the user-side applications in general) are still overwhelmingly driven by proprietary software.
Even contemplating what are generally considered open source success stories, winning can leave a bitter taste in the mouth. For example, looking at two key tech successes of the last 10 years, Amazon Web Services and Android, they both are heavily relying on open source software. They are arguably a part of this success of open source picture I just painted. But if you go back and look at all the user benefits I listed, the users of AWS and Android don’t really enjoy them all. As an AWS user, you don’t have transparency: you can’t really look under the hood and understand how AWS runs things, or why the service behaves the way it does. As an Android user, you can’t really engage with Android upstream, contribute to the creation of the software and make sure it serves your needs better tomorrow.
So open source won and is ubiquitous… however in most cases, users are denied some of the key benefits of open source. And looking at what is called “open source” today, one can find lots of twisted production models. By “twisted”, I mean models where some open source benefits go missing, like the ability to efficiently engage in the community.
For example, you find single-vendor open source, where the software is controlled by a single company doing development behind closed doors. You find open-core open source, where advanced features are reserved for a proprietary version and the open source software is used as a trial edition. You find open source code drops, where an organization just periodically dumps their code to open-wash it with an open source label. You find fire and forget open source, where people just publish once on GitHub with no intention of ever maintaining the code. How did we get here?
Control or community
What made open source so attractive to the software industry was the promise of the community. An engaged community that would help them write the software, build a more direct relationship that would transcend classic vendor links, and help you promote the software. The issue was, those companies still very much wanted to keep control: of the software, of the design, of the product roadmap, and of the revenue. And so, in reaction to the success of open source, the software industry evolved a way to produce open source software that would allow them to retain control.
But the fact is… you can’t really have control and community. The exclusive control by a specific party over the code is discouraging other contributors from participating. The external community is considered as free labor, and is not on a level playing field compared to contributors on the inside, who really decide the direction of the software. This is bound to create frustration. This does not make a sustainable community, and ultimately does not result in sustainable software.
The open-core model followed by some of those companies creates an additional layer of community tension. At first glance, keeping a set of advanced features for a proprietary edition of the software sounds like a smart business model. But what happens when a contributor proposes code that would make the “community edition” better ? Or when someone starts to question why a single party is capitalizing on the work of “the community”? In the best case, this leads to the death of the community, and in the worst case this leads to a fork… which makes this model particularly brittle.
By 2019, I think it became clearer to everyone that they have to choose between keeping control and growing a healthy community. However most companies chose to retain control, and abandon the idea of true community contribution. Their goal is to keep reaping the marketing gains of calling their software open source, of pretending to have all the benefits associated with the open source label, while applying a control recipe that is much closer to proprietary software than to the original freedoms and rights associated with free software and open source.
How open source is built impacts the benefits users get
So the issue with twisted production models like single-vendor or open-core is that you are missing some benefits, like availability, or sustainability, or self-service, or the ability to engage and influence the direction of the software. The software industry adapted to the success of open source: it adopted open source licenses but little else, stripping users of the benefits associated with open source while following the letter of the open source law.
How is that possible?
The issue is that free software and open source both addressed solely the angle of freedom and rights that users get with the end product, as conveyed through software licenses. They did not mandate how the software was to be built. They said nothing about who really controls the creation of the software. And how open source is built actually has a major impact on the benefits users get out of the software.
The sad reality is, in this century, most open source projects are actually closed one way or the other: their core development may be done behind closed doors, or their governance may be locked down to ensure permanent control by the main sponsor. Everyone produces open source software, but projects developed by a truly open community have become rare.
And yet, with truly open communities, we have an open source production model that guarantees all the benefits of free and open source software. It has a number of different names. I call it open collaboration: the model where a community of equals contributes to a commons on a level playing field, generally under an open governance and sometimes the asset lock of a neutral non-profit organization. No reserved seats, no elite group of developers doing design behind closed doors. Contribution is the only valid currency.
Open collaboration used to be the norm for free and open source software production. While it is more rare today, the success of recent open infrastructure communities like OpenStack or Kubernetes proves that this model is still viable today at very large scale, and can be business-friendly. This model guarantees all the open source benefits I listed above, especially sustainability (not relying on a single vendor), and the ability for anyone to engage, influence the direction of the software, and make sure it addresses their future needs.
As much as I may regret it, the software industry is free to release their closely-developed software under an open source license. They have every right to call their software “open source”, as long as they comply with the terms of an OSI-approved license. So if we want to promote good all-benefits-included open source against twisted some-benefits-withheld open source, F/OSS advocates will need to regroup, work together, reaffirm the Open Source Definition and build additional standards on top of it, beyond “open source”.
What we should do about it
So while being necessary, open source today is not enough. What should we, open source enthusiasts and advocates, do about that ? First, let me clarify what we should not do.
This is not a call to change open source
Since open source was coined in 1998, software companies have evolved ways to retain control while producing open source software, and in that process stripped users of some of the traditional benefits associated with F/OSS. But those companies were still abiding to the terms of the open source licenses, giving users a clear base set of freedoms and rights.
Over the past year, a number of those companies have decided that they wanted even more control, in particular control of any revenue associated with the open source software. They proposed new licenses, removing established freedoms and rights in order to be able to assert that level of control. The Open Source Definition defines those minimal freedoms and rights that any open source software should have, so the Open Source Initiative (OSI), as steadfast guardians of that definition, rightfully resisted those attempts.
Those companies quickly switched to attacking OSI’s legitimacy, pitching “Open Source” more as a broad category than a clear set of freedoms and rights. And they created new licenses, with deceptive naming (“community”, “commons”, “public”…) in an effort to blur the lines and retain some of the Open Source Definition aura for their now-proprietary software.
The solution is not in redefining open source, or claiming it’s no longer relevant. Open source is not a business model, or a constantly evolving way to produce software. It is a base set of user freedoms and rights expressed in the license the software is published under. Like all standards, its value resides in its permanence.
Yes, I’m of the opinion that today, “open source” is not enough. Yes, we need to go beyond open source. But in order to do that, we need to base that additional layer on a solid foundation: the Open Source Definition.
That makes the work of the OSI more important than ever. Open source used to be attacked from the outside, proprietary software companies claiming open source software was inferior or dangerous. Those were clear attacks that were relatively easy to resist: it was mostly education and advocacy, and ultimately the quality of open source software could be used to prove our point. Now it’s attacked from the inside, by companies traditionally producing open source software, claiming that it should change to better fit their business models. We need to go back to the basics and explain why those rights and freedoms matter, and why blurring the lines ultimately weakens everyone. We need a strong OSI to lead that new fight, because it is far from over.
A taxonomy of open source production models
As I argued in previous parts, how open source is built ultimately impacts the benefits users get. A lot of us know that, and we all came up with our own vocabulary to describe those various ways open source is produced today.
Even within a given model (say open collaboration between equals on a level playing field), we use different sets of principles: the OpenStack Foundation has the 4 Opens (open source, open development, open design, open community), the Eclipse Foundation has the Open Source Rules of Engagement (open, transparent, meritocracy), the Apache Foundation has the Apache Way… We all advocate for our own variant, focusing on differences rather than what we have in common: the key benefits those variants all enable.
This abundance of slightly-different vocabulary makes it difficult to rally around and communicate efficiently. If we have no clear way to differentiate good all-benefits-included open source from twisted some-benefits-withheld open source, the confusion (where all open source is considered equal) benefits the twisted production models. I think it is time for us to regroup, and converge around a clear, common classification of open source production models.
We need to classify those models based on which benefits they guarantee to the users of the produced software. Open-core does not guarantee availability, single-vendor does not provide sustainability nor does it allow to efficiently engage and influence the direction of the software, while open-collaboration gives you all three.
Once we have this classification, we’ll need to heavily communicate around it, with a single voice. As long as we use slightly different terms (or mean slightly different things when using common terms), we maintain confusion which ultimately benefits the most restrictive models.
Get together
Beyond that, I think we need to talk more. Open source conferences used to be all about education and advocacy: what is this weird way of producing software, and why you should probably be interested in it. Once open source became ubiquitous, those style of horizontal open source conferences became less relevant, and were soon replaced by more vertical conferences around a specific stack or a specific use case.
This is a good evolution: this is what winning looks like. The issue is: the future of open source is not discussed anymore. We rest on our laurels, while the world continually evolves and adapts. Some open source conference islands may still exist, with high-level keynotes still raising the issues, but those are generally one-way conversations.
To do this important work of converging vocabulary and defining common standards on how open source is produced, Twitter won’t cut it. To bootstrap the effort we’ll need to meet, get around a table and take the time to discuss specific issues together. Ideally that would be done around some other event(s) to avoid extra travel.
And we need to do that soon. This work is becoming urgent. “Open source” as a standard has lots of value because of all the user benefits traditionally associated with free and open source software. That created an aura that all open source software still benefits from today. But that aura is weakening over time, thanks to twisted production models. How much more single-vendor open source can we afford until “open source” no longer means you can engage with the community and influence the direction of the software?
So here is my call to action…
In 2019, open source is more important than ever. Open source has not “won”, this is a continuous effort, and we are today at a critical junction. I think open source advocates and enthusiasts need to get together, defining clear, standard terminology on how open source software is built, and start communicate heavily around it with a single voice. And beyond that, we need to create forums where those questions on the future of open source are discussed. Because whatever battles you win today, the world does not stop evolving and adapting.
Obviously I don’t have all the answers. And there are lots of interesting questions. It’s just time we have a place to ask those questions and discuss the answers. If you are interested and want to get involved, feel free to contact me.
About the author: Thierry Carrez is VP of Engineering at OSI Affiliate Member OpenStack Foundation and an elected member of the OpenStack Technical Committee. “Open Source in 2019,” parts 1/3, 2/3 & 3/3, © Thierry Carrez, 2019, via ttx:reloaded. Reposted here with permission, under a Creative Commons Attribution-ShareAlike 4.0 International License.
Image credit: “OpenSourceIN2019_0.png” by Open Source Initiative, 2019, CC0 1.0 Universal (CC0 1.0) Public Domain Dedication, is a derivative (cropped and elongated) of “Hikers on the Boardwalk Through the Steam at Grand Prismatic Spring” a U.S. National Park Service photo by Jacob W. Frank (2016), available under Public Domain, via the U.S. National Park Service.
