Fourteen years ago a book seller out of Seattle quietly launched its first web service and in doing so laid a foundation for the very notion of “Cloud Computing”. It is hard to believe now that it took 9 more years for the term “Cloud Native Architecture” to be coined first at Netflix and later popularized at Pivotal. In 2018, however, it is all but clear that “Cloud Native Applications” represent a radical departure from the software architectures that came before them. And if the software architecture and its ecosystem changed so much, shouldn’t “Open Source” philosophy also evolve to keep up with it?
In other words, is it time we abandon old school “Open Source” and embrace “Cloud Native Open Source”?
After all, 2018 is the year of articles talking about “dark clouds on the horizon […] threatening the [very] viability of open source”, tech press covering escalating “open source licensing wars” and Twitter abuzz with threads predicting rapid demise of third most popular open source license. It surely seems that 2018, as my dear friend Milind Bhandarkar eloquently put it, just may go down in history as the year “when OSS started a war against Hyperscale service providers”.
Whether an all-out war is inevitable or not, let’s at least try to understand what got us here to begin with.
What’s the big deal and why now?
In the past few months, I’ve been “on and off” talking to VCs, founders and open source developers at startup companies about how this new relationship between Open Source communities and public cloud providers should evolve. This month’s Amazon re:Invent 2018 conference, kicked those conversations into the highest possible gear by clearly showing how close the company has come to going full “Red Wedding” on its ecosystem players. If I were to distill all the grievances I’ve heard in these conversations I think it would be fair to summarize them like this:
“Public Cloud provides are capturing value they have no moral right to and by doing so are putting the very viability of open source communities they are pillaging at grave danger”
I will try to unpack this statement one part at a time and make sure that by the end of this article you get a perspective on what really is and isn’t rotten in this open source kingdom of ours. It is a long read — make sure to stick until the end — hopefully it will be worth your time.
Content from our partners
Open Source: free gift or an exchange of value?
Since the dawn of Open Source, there has been a fundamental tension between open source practitioners who viewed it as a free gift (or true charity) and those who saw it as one side of an exchange: we give you our code and you promise to compensate us back somehow. Obviously, since the very nature of open source is predicated on the source code actually being available for anyone to see, most of the time we’re stuck with demanding “in-kind” types of value equivalence on the “give us something back” side. The #1 tool used to manage expectations in these types of value equivalence agreements is an open source software license.
GNU Public License (or GPL for short) is probably the best known example codifying precise expectations of what producers of open source software expect from the consumers. GPL basically boils down to making an equivalence of code on both sides: if you took GPL code from us, you must give us the code you develop on top of it (keep in mind this notion of “developed on top of it” — we will get back to it later). GPL, of course, is only the second most popular license used by open source communities. You know what #1 is? MIT: a permissive “open source as a free gift” license. However hard it may be to believe, all these open source communities publishing their projects under MIT license expect absolutely nothing in return from anybody who uses their software. Just like scientists citing past research, these open source communities only expect a “reference” (or more precisely attribution) of their work. Nothing else. Apache License version 2 (ALv2 for short) is another example in this category know as permissive open source licenses. Permissive licenses have been gaining huge momentum in the open source communities to a point where more than 65% of all open source software in wide circulation today is being covered by one.
This is the first problem with the “they have no moral rights to all this value” argument. Anyone who publishes their software under any kind of a permissive license (and apparently there is a lot of us) has no expectations for being compensated in any way aside from simply receiving a written acknowledgment that our software was used. We are just that charitable. Or are we?
Repeat after ASF: community over code
First thing that Apache Software Foundation drills into all of its new projects is the notion that your community is much more valuable than your code. As a corollary to that, we teach our projects to recognize non-code contributions as being, often, more valuable to the community than simple code grants. Things like documentation, tests, bug reports, evangelizing software or bringing new users to a project — all of these are as important as writing code. It takes a while to truly internalize this view point in our “rock star developer” dominated industry, but once you do (and you really should!) you will see that public cloud providers do bring a lot of value to the table even when they don’t contribute a single line of code to the projects they use. They function as developer marketing machines, they write documentation, they popularize projects and bring in untold number of users.
Is one new user worth as much as one new feature contributed? I don’t know. But saying that it isn’t worth anything is disingenuous at best and purposefully deceptive at worst.
What I do know, however, is that when I publish my project under the most business friendly license out there (ALv2 of course!) I give all the business consumers of my software a gift that, deep down, I know they will return by the very nature of trying to “exploit” it — they will proliferate my work beyond my wildest dreams.
This is my second, and in a way much bigger, problem with the “they have no moral rights to this value” argument presented above. It completely (and I would argue deliberately) misses the point that public cloud providers are, in fact, contributing a lot even when they don’t give you a single line of code back (and don’t even get me started on the fact that a lot of these companies are actually sponsoring foundations like ASF and LF directly).
On having your cake and eating it too: still a no-go
So why do VCs, corporate boards of VC-backed companies and founders keep obsessing that public cloud providers don’t give any value back unless they contribute code? Why do they go onto CNBC to lament Amazon’s (perfectly legal I might add) behavior?
A simple, somewhat cynical explanation, of course, is that this is exactly what they are paid to do. They are paid to “preserve and grow” shareholder value by whatever means necessary. One aspect of this is growth and the other is value capture. In the open source, unfortunately, they are fundamentally at odds.
After all, if you give away your software under the “open source as free gift” license (thus guaranteeing fastest growth) chances are that you will later run into troubles with capturing direct value (remember — you promised not to expect anything back!). And if you start capturing value early (by demanding reciprocal value back from your users) your growth will be slowed down quite a bit. Just like with a cake: you can either have it, or eat it — not both.
That is why, by the way, I have so much respect for the open source projects like Scylla DB and its founders: they are absolutely upfront about their choice in growth vs. value capture equation. They picked one of the most restrictive open source licenses out there (AGPL), they directly compete with a liberally licensed Apache Cassandra and they are still winning customers based on how good their product is. They don’t need to deceive customers with “open source as free gift” license only to show up on their doorstep later to demand something back. This is what an honest way of doing business and doing open source looks like.
But is it the only one?
Open Source value exchange in a “Cloud Native” era
As I mentioned before, Open Source calibrates exact nature of value exchange through the careful choice of software licensing. On one end of this spectrum of value exchange, permissive licenses are still doing extremely well and I won’t spend much more time discussing what can be improved their (aside from a small point on how we can improve attribution). Restrictive licenses, on the other hand, present a much more interesting case of how “Cloud Native” revolution is rippling through the software industry.
Let’s turn our attention back to AGPL (Affero GPL): this license is trying to make sure that original GPL principles of reciprocal value exchange around code can be carried into the “Cloud Native” era. And for a good reason, since with “Cloud Native” the very core underpinnings of GPL’s ability to demand the code you “develop on top of my code” stop functioning as designed. “Cloud Native” becomes so good at hiding implementation details that you no longer even know what code you “develop on top of”: the notion of leveraging open source code as building blocks gets a completely new meaning.
To explain why this paradigm shift is so important, let’s start with how complex applications used to be constructed “on top of” open source building blocks before the “Cloud Native” era began. Back in the day, the majority of open source building blocks were typically consumed as “packaged software” (libraries, Operating Systems, middleware and database just to name a few examples). The value exchange was predicated on the users knowing exactly what kind of building blocks they were consuming and under what open source licenses. In the “Cloud Native” world the very same building blocks are now mostly consumed as “API-driven services”. The difference here is subtle, but profound. Before “Cloud Native”, IT organizations had an pretty good understanding of what software components were inside of those building blocks (if for nothing else but to simply understand the licensing and security implications of having them run on their servers). With “Cloud Native” these building blocks are now viewed as completely opaque black boxes that are impossible to inspect even if IT organizations really wanted to.
Richard Stallman, the visionary behind GPL and Free Software Foundation, was the first one to point out this new challenge in his 2010 Boston Review article. Back then, of course, “Cloud Native” didn’t exist and even its “pre-cursor” SaaS wasn’t as popular as it is today (which is perhaps why Richard’s closing statement back then was “Only a small fraction of all web sites do SaaS; most don’t raise the issue”). The problem, however, was very much visible and the problem was: it was no longer possible for the end-users to clearly understand what open source building blocks they were leveraging by consuming all these services. Even the most basic thing — attribution — became much more difficult to track.
AGPL, in many respect, was an attempt at fixing this and trying to reinforce a lot of original GPL value-exchange expectations in the age of “Cloud Native” software. Unfortunately, it failed to anticipate all the nuance and complexity of this new world and it is clear by now that looking at it as “GPL of Cloud Native” would be a mistake.
Brave, new, “Cloud Native” world
And this is how we find ourselves in a world where after last week’s Amazon’s conference it wasn’t immediately obvious whether Kinesis Data Analytics for Java was really Apache Flink or not; whether Amazon’s Comprehend Medical was really Apache cTakes under a different name (just to give you a few most noteworthy examples).
On a flip side of this confusion was, of course, Apache Kafka. There was absolutely no confusion whatsoever that Amazon was now offering it as a service but the very clarity of the situation made some executives somewhat upset an provided tech journalists with really high quality drama material.
Clearly a “damned if you do [let everybody know what open source you’re using] and damned if you don’t” conundrum for Amazon’s AWS and the rest of public cloud providers.
What is it that we really want from Amazon (and Microsoft, and Google and Alibaba and all the rest of the cloud providers)? What do we want them to do or not to? Or to put it another way: what is the desired behavior and value equivalence we want our next generation open source licenses to enforce in the “Cloud Native” era?
What do we want? Well… When do we want it? Now!
It should be pretty clear at this point that I have absolutely no sympathy towards CEOs, founders and boards of the commercial companies who decided that it was possible to have your cake (have adoption levels of a permissive license like ALv2) and eat it too (make sure that Amazon and other public cloud providers can’t use the same software to build a better product). They complain about Amazon stealing their customers? Stop whining, build a better products and beat Amazon at its own game — I say!
In fact, on the permissive licenses side of open source the only two things I’d like to see changing are:
1. Crystal clear clarity on what open source projects are being used in each of the products
2. A lot of education and outreach explaining to the public cloud providers (and anyone else who is willing to listen!) the value of operating as bonafide member of the community as opposed to staying on the sidelines or, worse yet, “forking” open source projects like, for example, Amazon had done with Xen and Linux kernel in the past.
Both of these are on us — open source practitioners. #2 by the way, includes explaining the value of direct sponsorship for organizations like ASF and LF and #1 may require some additional tweaking of how attribution of credit gets mandated with permissive licenses. One example to follow here would be AGPL that basically demands:
if you run a modified program on a server and let other users communicate with it there, your server must also allow them to download the source code corresponding to the modified version running there
Of course, with permissive licenses instead of demanding “downloading of source code”, we would demand availability of the attribution statement (the same way that clicking About on your Android or iPhone gives you a long list of open source building blocks that were used in either of those).
But what if we want more still? What if we really want to compel Amazon to give us as much value back as they seem to be capturing themselves? That would be fine if we talk about value equivalence of code. There’s obviously AGPL that is trying to do some of that. While it needs improvements, I see no problem with more software being licensed under it just like the fine folks at Scylla DB are doing.
You want even more? You want, effectively, to bar Amazon from competing with you by leveraging the same code base your product is built with? Or, as Salil framed his problem statement:
“[…]wish[ed] to define a license that prevents cloud infrastructure providers from running certain software as a commercial service , while at the same time making that software effectively open source for everyone else, i.e. everyone not running that software as a commercial service.
I see no problem with that either. Evolving Open Source licensing in this direction and trying to make sure that direct investments into open source value creation companies can still make sense even when public cloud providers seem to be so formidable of a competition is a great endeavor!
It is, however, a very different problem statement compared to the constant false narrative that the only way to guarantee survival of open source communities is to engage in this type of open source licensing innovation.
Because, you see, as communities we want to encourage as much collaboration and common business with public cloud providers as we possibly can — while all attempts at directly protecting open source value creators (and by extension VC investments into them!) seem to be focusing on limiting business opportunities available to public cloud providers.
There’s no shame in putting fair barriers in front of your competition (after all, that’s exactly what patents were invented to accomplish) but as open source communities we are all about removing barriers and leveling the playing field as much as possible.
Or to put it another way: whenever anyone is trying to justify additional barriers by citing their great, heartfelt concern for wellbeing of open source communities — you really should examine their true motivation.
Commercial Open Source Software
Having said that, if the true motivation is articulated up-front, I’m all in favor of leveraging our collective “open source braintrust” to try and figure out the next generation of business models around Open Source Software. The kinds of business models that would be reliable in the “Cloud Native” era. The kinds of business models that would allow my good friend JJ at OSS Capital (and yes the name really does stand for Open Source Software Capital) to confidently invest in open source value creators while adequately protecting his investments from being immediately exploited by the competition.
JJ likes to call these next generation Open Source business models: Commercial Open Source Software and I think he is onto something. It certainly feels very close to my own notion of “Cloud Native” Open Source. The key challenge, however, is in making sure that Commercial Open Source will still qualify as Open Source.
The first attempt at this: Common’s Clause License condition clearly fails this test. So much so that it acknowledges this shortcomings of not being Open Source right in its own FAQ. Which, by the way, is precisely why I feel it is so dangerous and downright misleading to mix Common Clause into existing true Open Source licenses (like Apache License v2 for example). Hopefully we can sort it out soon and folks wishing to use Common Clause will simply start calling their overall licenses something else (keep an eye on that JIRA to find out more).
Another attempt at this, Server Side Public License (SSPL), has been covered at length in Salil’s excellent expose and I won’t reiterate his findings here but rather note that I think we can, collectively, still do better. SSPL is a good first step, good conversation opener, but it clearly isn’t the last word in defining what Commercial (or “Cloud Native”) Open Source is.
The question then, becomes, what is the right forum, the right group of people (and organizations) to try and figure out what could be the answer?
OSI: United Nations of Open Source
One of the huge benefits of open source projects is their community. The community that develops, supports and governs the direction of where the project is going. Thus, when business requirements or technology landscape change you can always rely on that community to help navigate the project through challenging times. Evolving any active open source project is easy: you simply need to engage with its community online.
What about Open Source itself? Is there a community that governs and evolves the very notion of the Open Source or at least the various licenses that are used to define what open source is and isn’t? I would like to offer the following analogy:
Think of individual open source communities as countries. A lot of times they are either informally governed (think indigenous societies) or governed through formal open source foundations (think developed world liberal democracies). And just like countries have organizations like United Nations attempting to govern (albeit very, very ineffectively) where the entire human race is going, open source movement has organizations like Open Source Initiative (OSI).
The problem, of course, is that OSI these days makes UN look like a pinnacle of efficient decision making and executive expedience. Now, to be fair to OSI, it wasn’t really setup to tackle these types of challenges, but just like with UN everybody assumes it was.
My fundamental belief is that the most effective way for us to keep evolving open source in the age of “Cloud Native” is to approach this evolution with a very federalist view in mind. In other words, work with established, highly active open source foundations (ASF, LF, FSF, Eclipse, Mozilla, and a few others) and try to work from that level up. Leverage them in the same way that the founding fathers of the United States envisioned individual states to be leveraged: as “labs of democracy”.
Just don’t do it alone. Don’t cook up solutions behind closed doors (like what happened with Commons Clause for example) and then get surprised that open source communities seem to not be impressed by the fruits of your solitary labor. Leverage our collective brain trust. Engage us. I promise you it is easy to do and, in fact, that is exactly what all these open source foundations were incorporated to tackle: make sure that the communities they govern are successful and vibrant for years to come. And yes that does include licensing. In fact, ASF and FSF govern their own licenses as much as they govern the software that is published under them. It is the ASF and FSF, not OSI that have the most skin in the game and thus have the most motivation to actually figure out a practical, workable solution to what “Cloud Native” Open Source could mean.
I already invited Sunil to drop by two places in the ASF where he would find the most folks interested in figuring all of this out and engage in the constructive discussion with him and the rest of the industry: ASF Legal and ASF ComDev. Getting a conversation going with us is as easy as simply starting an email thread here or here (or even in both places at once!). I am waiting for that email from Salil. In the meantime, I also hope that other active foundations will extend the same kind of invitation to him and everyone else who is interested in a constructive discussion rather than (oh-so-rewarding — trust me!) sniping on Twitter.
Parting thoughts and disclaimers
Thoughts and views expressed here come from a lot of my personal, hands-on experience of contributing to open source projects and working at Linux and Apache Software Foundations (I used to be VP of technology at the former and I am still on the board of directors of the later). However, nothing here could be viewed as an “official position” of any kind. These are my personal views and opinions only. In fact, the very reason I love ASF so much is that our default position there is that most of the time even those of us with fancy ASF titles are only speaking as individuals. There are very few occasions when someone can actually speak on behalf of ASF. At best, view those titles (mine included) as a proxy for how much an individual is trusted by his or her peers — that collective open source practitioner’s braintrust that is much smarter than any one of us individually.
On the flip side of my open source engagements, there’s also the fact that I am a Silicon Valley entrepreneur and a co-founder of an open source, edge computing company (we are hiring by the way!). And just like any other open source executive with a company to protect I obsess over our open source business strategy daily. I too, am in business of not only theorizing about open source, but actually making money with it. I too, am in business of making sure public cloud providers don’t eat my business alive. It is just that I truly feel that both competing and cooperating with public clouds is not only possible, but in fact good for business and good for open source.
This article first appeared on Roman’s Medium blog
