We need a new way to think about open source

Open source companies and cloud providers are at war over who gets to profit from open source software. To help resolve that problem, we just might need new licensing.

Contributor, InfoWorld |

We need a new way to think about open source — Thinkstock

Open source is about community, so why can’t we get along? I’m referring to the recent fracas between Elastic and AWS, but we’ve dealt with similar issues for many years.

In this most recent episode of Open Source Wars, Elastic accused AWS of “behavior [that] is inconsistent with the norms and values that are especially important in the open source ecosystem.” AWS responded that, actually, it’s Elastic that is violating open source norms and values, leading AWS to fork Elasticsearch and Kibana to “foster healthy and sustainable open source practices—including implementing shared project governance with a community of contributors.”

Personally, I don’t think this conflict is a matter of licensing. I mean, it is, but that’s just a symptom, not the cause. The heart of the problem is about who gets to profit from open source software. To help resolve that problem, we just might need new licensing, as well as a new way to describe such licensing. (Am I about to suggest “shared source?” Yes, I am, but stay with me.)

Let’s ‘get the facts’

First, a disclosure: I work for AWS. Second, another disclosure: I have been involved in open source for a lot longer (nearly 20 years longer) than I’ve worked for AWS. My open source identity comes first. It’s more important to me. In writing this, I’m writing as Matt, the open source guy who works for AWS today but has advocated for open source since my first job with embedded Linux vendor Lineo, way back in 2000. (Third disclosure: I’m old. Could you please get off my open source lawn?)

With this in mind, let me share some objective truths:

Building great open source software that lots of people want to use is very hard;
Making money from that great open source software is arguably even harder;
Just because you write great software doesn’t mean you have a right to profit therefrom, and open sourcing your code means others have an equal opportunity to try; and
Some companies have been faster to figure out open source monetization than others.

Over the past few decades as an industry we’ve experimented with different business models for open source, such as support (bad idea!) and open core (has its own issues). But the cleanest model, and the one that has proven best at aligning customer and vendor interests, is managed cloud services, as I’ve written.

The problem, however, is that historically the individuals and companies most adept at writing great software haven’t necessarily been the best at operationalizing that code, something Tim Bray pointed out some time ago. As Bray put it, “The qualities that make people great at carving high-value software out of nothingness aren’t necessarily the ones that make them good at operations.” And vice versa. Customers have voted with their wallets for managed cloud services for their favorite open source software.

But this hasn’t resulted in that money funneling to the source of the code in many instances. See truths 2 through 4 above.

This is a problem, but it’s hard to know who to blame. Some point fingers at the cloud companies, but such criticisms sort of sound like “stop giving customers what they want.” And for those who argue that the cloud companies don’t contribute commensurately with the value they receive, it’s worth remembering that, generally speaking, such code contributions are neither welcome nor what the open source developer really wants. What do they want? A lock on monetizing the open source code they write, even if they’re not yet as good at meeting customer needs as competitors.

Which brings us to those who point fingers at these open source developers, arguing “The fact that you can’t figure out how to turn great software into a great business is your problem.” This sounds a bit like blaming the victim. But there is truth to the contention that such developers seem to want the distribution benefits of open source (community!) but the monetization benefits of proprietary software (me!). Regardless, this contention fails to recognize that what the open source developer may need is more time to develop the operational “muscle” needed to deliver software as customers increasingly expect.

Back to the shared source future

To buy themselves time, companies like MongoDB and, now, Elastic have turned to licenses like the Server Side Public License (SSPL). No, they’re not open source licenses. But they’re also not proprietary licenses, at least not in the traditional way we think of such licenses. They’re something in between, and that quasi-open source approach may be enough for many purposes, as MongoDB’s success may suggest.

For at least two decades we’ve tried to figure out what this middle ground should be called. I don’t think we should normalize such licenses as “open source,” because they’re not. Open source has a specific meaning, developed (and defended) for over two decades. But we also shouldn’t demonize them. They are the efforts of developers to financially benefit from code they’ve written, and there’s nothing wrong with that.

So why not shared source?

Yes, it has a fraught pedigree, used as it was by Microsoft to try to mimic open source without actually embracing open source. But remove the taint and it’s actually an approachable, accurate term for what these companies want to do: share source with others while (generally, though not always) restricting use of that source to build competitive products. So why not use “shared source” as a category of license that isn’t open source but also isn’t proprietary, and gives would-be users a rough approximation of what rights and restrictions they’ll have when using the license? Matt Seitz offers a sense of how it could work:

This reminds me of discussions about “free software” (copyleft) vs. “open source.” Licenses, like color, have a spectrum. We can describe them in broad categories (red, green), and then add adjectives (ruby red) or create specialized terms (crimson).

The SSPL becomes “shared source, but not with cloud providers.” Yes, there are nuances beyond that, but that’s easy-to-understand shorthand for what’s going on.

Do we need this category? I think we do. We can argue about who is to blame in the open source monetization wars, but the fact that there’s a war at all, and that it has persisted for so long, suggests there’s a real issue that needs resolution.

Will developers embrace shared source licenses? It’s unclear. Would MongoDB thrive today under SSPL had it not had years of goodwill built up first as an open source project? Maybe, maybe not. But I believe that is for developers to decide. Give them clear, accurate categories of licenses to choose from, with easy-to-understand affordances and constraints, and let’s see what happens.

Let’s ‘get the facts’

Back to the shared source future

Read more about open source: