I meet a lot of developers who have bought into the hype about open source. It’s great! It’s going to save the world from the perils of proprietary software! Or failing that, just produce free, high-quality software for many conceivable purposes.

I’m a little more skeptical. But I’ve not read a proposal that adequately addresses my concerns about open source, nor that suggests anything in particular can be done about it. So here are my concerns, and my proposal.

A disclaimer

First, let me lay out some credentials. I’m certainly no core FOSS contributor, but I have patches in large FOSS projects. This certainly isn’t an essay against writing patches, or sending patches upstream. We should all be doing more of that.

Secondly, I have a pretty large corpus of open code that you can find lying around the Internet. This isn’t an essay against that either. There’s nothing wrong with lobbing code out the window like a grenade, not sure of where it’s going to land. (Unlike a grenade, however, the result is usually silence.)

Rather, this is an essay about what, as a practical matter, open source can and cannot do. The study of where the rubber meets the road, effectively. There are features and patches and entire open source projects that cannot exist, structurally, under our current system. The ingredients aren’t right. The incentives aren’t right. Let’s poke at that.

A brief history lesson

A lot of this started back with RMS in the 80s. He coined a term called “free software” and in order to “protect the user’s freedoms” he invented a series of copyleft licenses, notably including the GPL and LGPL. These licenses follow the general principle that you must release some source code yourself as sort of a “payment” for the software.

Meanwhile some other folks decided this was a bridge too far and that the way to do “free” “software” was just to give it away, with no (or at least fewer) strings attached. This of course means that downstream users could make changes that aren’t contributed back, but that’s life in the big city. This movement eventually coalesced into the “open source” banner. These two camps have had at times a bit of a tenuous relationship; for example Stallman writes long missives about the relationship between the camps.

Now I’m skipping over a lot of details here. These “camps” are really more of a spectrum, and they acknowledge most of each other’s licenses. But from a philosophy point of view, they’re very different. One believes that freedom is about having a strong license that enforces it. The other believes that freedom is about letting people do what they want, even if that’s closing code. That is, at its core, what the dispute is about.

Since the 80s

What has happened since the 80s is that, essentially, open source has won most of the war. The RMS people are not going to agree with this assessment, but that’s the force of it, really. From a marketing perspective, many more people have heard of “open source” than of “free software”, to Stallman’s great annoyance. (Fun fact: he “usually declines to participate in ‘open source’ events”). And from a practical perspective, lots of high profile projects have decided, as the FSF evolves its licenses to counter new threats, that the old licenses are strong enough.

The result is a philosohpical departure over the decades, in large or in small, from the FSF. This philosophical departure is borne out in datasets that show the declining influence of copyleft in the overall open source community (although there is some debate about the accuracy of these figures).

Now I should point out that in some ways I am being unfair, and judging people by standards that they don’t recognize. To a “true” FSFer, things like being popular or even being technically good are irrelevant–what matters is the ideology of freedom, which has not been compromised. I think there is some internal sense to that view, a matter that we’ll come back to. But judged by the “ordinary” standards of merit, I think they have lost.

How open source works

To make sense of this, we first have to consider where open source projects come from. Well, they come from patches; that much is self-evident. But where do the patches come from?

1. Large patches by core contributors who stay with the project over time
2. Incidental or “drive-by” patches to fix a bug that some developer experienced or to add a feature that some developer needed.
3. Sudden investment of an institutional customer, such as Apple’s birth of WebKit from KHTML, or Google’s birth of Blink from WebKit.

Now the first thing to examine is which of these actually matter to the success of a project. That’s not really a sensitive way of putting it, but the fact is that some patches matter more than others.

The “incidental” or “drive-by” patches matter the least. There are some counterexamples; Linux for example has a big mythology around everybody contributing patches for their little bug. But the reality is that these are really “last-mile” type patches that take the final steps to make the thing usable for some minority. For a project to even get to the place where it is attracting these kinds of submissions it has to be “mostly right” to begin with. So the important cases are the other two types.

The Type 3 “institutional investment” is obviously strategic; you invest in an open source project for strategic reasons. It’s hard to imagine now, but in Apple’s case, they were down for the count; they were a major OS vendor without their own web browser, with no ability to influence the future of the web. 15 years later they now control the most important browser technology in the world. By uniting all the second-place players onto one team, they were able to defeat the leading player. But an open web was always a collateral benefit of their strategy. The real goal was to use WebKit as a club to bludgeon MS over the head. It worked.

Take GitHub, for example, probably the most “community service” of the pro-open-source companies I can think of. They have, quite famously, their own blend of Markdown, called “Github Flavored Markdown”, for which they have very kindly donated not just a well-written specification but also a high-quality implementation, and very liberally licensed.

Altruism, case-closed, right? Well, not quite. Making GitHub’s markup language widely available ensures it becomes a standard that all other SCM hosts (and most developer tools, for that matter) must implement. It means that, effectively, other tools must either be GitHub clones, or else just lack features that GitHub offers. And why use a clone when you can use the real thing?

It turns out, Type 3 contributions usually come to “open source” instead of “copyleft” projects. This is because, generally, some institutional investor is better served by getting the widest possible distribution of their code. In GitHub’s case, getting the widest possible distribution of GHFM ensures that it becomes a de-facto standard, while a GPLv3-based license limits the deployment considerably.

What is more surprising is that “Type 1” patches are also strategic. There are few developers wealthy enough to invest hundreds of man-hours purely in community service. Developers have this curious habit of demanding food, clothing, a place to live, fast processors, and fat bandwidth pipes. As such, these developers are funded, directly or indirectly, by institutional organizations making strategic investments.

To the extent that Type 1 contributions also represent a form of institutional investment, they’re also more likely to come to “open source” projects, again because it presents the best opportunity for distribution, which is in the interest of the corporate sponsor. I think these factors explain much of the success of the “open source” splinter movement out of its “free” origins and why it became the dominant philosophy. It best serves the corporate overlords.

Wars of attrition

Nowhere can this be seen more clearly at the moment than with the fresh turf war between Docker and CoreOS.

Docker is a way to run software–pretend for a moment it’s a VM, like VirtualWare, as that’s close enough for this conversation. (Please don’t send me emails about how Docker is just a GUI for LXC.) As it turns out Docker is a much better VM than VMs are, and due to a convergence of various technologies elsewhere in the open source software world it is now easy to execute by tying various off-the-shelf components together. The result is that Docker’s been something of a rocket ship, swallowing its parent company in an example of the rare “pivoting a profitable business to an unprofitable one” move.

As a consequence of this rocket ship trajectory, lots of folks have lined themselves up to be the Red Hat to Docker’s Linux, sort of a vast sea of companies jockying to provide “platforms” or “support” on top of Docker infrastructure. Examples range from the tiny tutum.co to the enterprise CoreOS. Since Docker effectively wipes out an entire class of commercial VMs, the future is bright for anyone who positions themselves as the must-have value add for Docker now.

Docker, however, is wise to the plan. Since they control the underlying open source project, they think they are better positioned, from a brand and strategy perspective, to grow into CoreOS’s space, than CoreOS is positioned to keep it. The result is that issues with hundreds of comments remain open for years ¹ because they’re not strategically compatible with Docker’s vision of being a 1-click end-to-end VM management system. Docker doesn’t want to be just a VM killer. They want to be a VM killer plus swallow up a lot of the market for value-added platforms and services. ²

Meanwhile, CoreOS isn’t stupid either. They know what Docker is trying to grow into their turf and they’ve decided to fight back–by growing into Docker’s turf. Announcing an alternative to Docker, which they call Rocket, they promise to stick to being “just” a VM, and in the process fixing some annoyances that many people have with Docker generally:

Additionally, in the past few weeks Docker has demonstrated that it is on a path to include many facilities beyond basic container management, turning it into a complex platform. Our primary users have existing platforms that they want to integrate containers with. We need to fill the gap for companies that just want a way to securely and portably run a container.

They’ve also invented, out of whole cloth, a “standard” for VMs, of which they are the only implementation:

Rocket is a command line tool, rkt, for running App Containers. An “App Container” is the specification of an image format, container runtime, and a discovery mechanism. Rocket is the first implementation of an App Container, but we do not expect it to be the only one.

It’s important to see the strategy here. VMs like VMWare and VirtualBox are already concerned about Docker’s effect on their long-term viability. CoreOS is offering to band together what will soon be second-place players under a common banner, that isn’t Docker. This is the “birth of WebKit” story played out in the VM world–an upstart from nowhere trying to bandy together the runners-up into a team that can unseat the king. This one’s just playing out faster, with less familiar players.

This is how open source works

It isn’t a utopian dream to build great software. It’s a bat that for-profit companies use to bludgeon each other over the head with.

The battle over stuff as mundane as what command-line arguments are accepted for the software are part of some larger war that enterprises are waging using OSS contributions as a proxy.

This explains a lot of things. It explains, for example, why ReactOS moves so slowly, compared to, say, WINE (even though, for the record, they share a lot of the same code). Because one of them (WINE) has a lot of companies behind it and around it and ReactOS doesn’t.

Now I want to be clear here. This war I’m describing is structural. It’s institutional. I’m describing what happens on the macro level. On the micro level, each individual software developer might be a really nice guy and have everyone’s best interests at heart. On the micro level, each individual feature might have some plausible basis for just-so-happening to make the same decision that’s in line with the strategic interests. But ultimately, we all have to eat once in awhile, and the ones that work on things that are strategically valuable just seem to have more time from their corporate overlords to spend than the rest.

What Stallman Got Right

What those of us on the “open source” side of things fail to acknowledge is that even as GNU has lost a lot of the technical battles, and lost a lot of the popular battles, they have won in one key respect: they’ve kicked the “suspicious” motivations out of the kitchen.

Consider the following: back before LLVM, Apple used GCC. And because of the strong copyleft protections of GCC, much of Objective-C was made open source. Wikipedia:

In order to circumvent the terms of the GPL, NeXT had originally intended to ship the Objective-C frontend separately, allowing the user to link it with GCC to produce the compiler executable. After being initially accepted by Richard M. Stallman, this plan was rejected after Stallman consulted with GNU’s lawyers and NeXT agreed to make Objective-C part of GCC.

Now in 2015, we have LLVM, but the front-end sourcecode for Apple’s new language, Swift, is nowhere to be seen. Nor is much of this year’s Apple toolchain for that matter. Hmm…

Say what you want about the GNU project on technical or popularity grounds. But it seems unmistakable to me that their ideological purity drove ObjC open-source. Say what you want about LLVM on technical or popularity grounds. But it seems unmistakable to me that their ideology allows Swift to stay closed.

They’re not completely crazy, these “free software” people. They are what they say on the tin. I really believe that’s more than you can say for “open source”, on the average.

The marketing problem

Now, there’s nothing wrong with doing things that make money, in my view. The problem is that there are a lot of people who have bought into the marketing story that open source is about something else. Enough developers have swallowed the “utopian vision” of open source that it’s become an effective branding tool. A company that aligns itself with some kind of open source project is thought to be good, and a company that aligns itself against some open source project is perceived to be 90s-era Microsoft. In fact, attracting and retaining development talent is the #2 reason companies engage in open source to begin with. The brand pull is strong.

The problem is that kids today forget what 90s-era Microsoft was really like. For example here’s what a federal US judge ruled Microsoft did:

As discussed above, Microsoft’s effort to lock developers into its Windows- specific Java implementation included actions designed to discourage developers from taking advantage of Java class libraries such as RMI. Microsoft went further than that, however. In pursuit of its goal of minimizing the portability of Java applications, Microsoft took steps to thwart the very creation of cross-platform Java interfaces. The incorporation of greater functionality into the Java class libraries would have increased the portability of the applications that relied on them, while simultaneously encouraging developers to use Sun-compliant implementations of Java. In one instance of this effort to stunt the growth of the Java class libraries, Microsoft used threats to withhold Windows operating-system support from Intel’s microprocessors and offers to include Intel technology in Windows in order to induce Intel to stop aiding Sun in the development of Java classes that would support innovative multimedia functionality.

That paragraph should have generated about 10 “WAT”s. I mean far beyond “embrace, extend, extinguish” with Java, Microsoft actually threatened to move the entire PC industry away from x86 over some Java issue. WAT.

That’s what playing hardball looks like. The idea that selling proprietary software for money is in any way comparable to this kind of tactic is completely absurd. Selling closed-source software does not put you in the same league as these people.

Open Source and Good as orthogonal concepts

Being nice, and being pro-open source, are completely independent concepts. An open source company can be evil, or it can be good, the same as a proprietary company.

Nowhere can this be seen more strongly than with OSS kingpin Oracle. Oracle, of course, is a Linux distro, as well as the steward of OpenOffice, MySQL, Java, the JVM, and more. You may have a vague recollection that LibreOffice or MariaDB forked to avoid Oracle’s control under somewhat odd circumstances, but unless you were involved, you probably just have an imprecise idea that Oracle is some kind of cartoon villain with a twirly mustache. Oracle’s business model appears to not be common knowledge in my circles, so I will now explain their villainy in more detail. (Full disclosure: I’m replicating one of their features for my own project, so I’m technically sort of a competitor, although not really).

You see Oracle is one of the last remaining companies that still knows how to use 90s-Microsoftian tactics. They are hampered by the fact that they don’t have 90s-Microsoft market dominance, but they’re very efficient; they produce a surprising amount of evil with the marketshare that they have.

The way it works is as follows. Your company licenses an Oracle product for some reason, for some stupid amount of money. Maybe you buy some software that require’s Oracle’s database, or maybe Oracle is the only vendor with some feature you need that’s a regulatory requirement. Anyway. You pony up your pound of flesh and make the deal.

Then, they ship you shiny, expensive buttons to press that if you press them, will end up costing you money:

I guess my view on this one is that what Oracle has done here is essentially allowed tactical decisions made by developers that have a huge strategic impact… I’m afraid I can’t give them any defense here…

God help you if you install artitioning or spatial and not have a true understanding of the repercussions, and this cascades further when you talk about the virtualization problem where the multiplier effect kicks in and what turned out to be maybe a $40,000 decision at a developer level can turn into millions, and there’s no protection.

Then, an organization inside Oracle called LMS decides who they can get the most money from if they do an audit to see if you’ve pressed those buttons. Richard Spithoven, former “guy whose job it was”, explains:

the LMS organization within Oracle has a strategy to only focus on eight different products to get their revenue from, because they do their analysis at the beginning of the year as well to see, “Okay, where are we going to put our resources and efforts?” and then “Where do we believe gets the most return of investments from where we focus on?”…

Craig Guarente discusses that Oracle tries not to trip any alarms with its communications:

It’s funny. It doesn’t even say the word audit on it. It says, “You can do a license review,” so I’ve had clients respond. They don’t even know they’re being audited. It’ll say, “In line with your SLSA or OLSA…” whatever document they might have as a master agreement. We call those stealth audits. There is this sort of trying to be the kinder, gentler audit team.

We see it all the time. The audit letters don’t say, “Audit.” They call it a business review, a ULA health check, a license optimization, whatever the terminology is. Whether it’s an official audit or an unofficial audit in terms of that letter having come from LMS, if clients don’t take it seriously and they don’t do all the right things, they’re going to get hit with a big bill at the end.

Getting the picture? First, Oracle ships you shiny, expensive buttons to press. Then it launches a covert investigation into whether or not you press them. Finally they hit you with a bill, generally around 7 figures. This is how it works at one of the largest OSS companies in the world.

If “open source” is a term wide enough to cover Oracle’s business then it has no value as a moral descriptor.

Some people try to weasel out of this by saying “but companies like Oracle aren’t real OSS companies” but those sort of people have never met a true Scotsman. Oracle spends something like $5.5bn per year on R&D, and even if you imagine that only some fraction of that goes towards open source work, it’s just not that long before the loose change falling out of your pockets swallows up Red Hat, at the time of this writing worth a measly $13bn in total. Any attempt to distance Oracle from open source is at best intellectually dishonest. They are evil, and they are open source. You can be both.

Towards better terminology

What we need, I think, is to move beyond the notion of both open source and “free software”, and along a path towards sustainable development.

I mean something like what has happened with farming, or cooking, or being an artist, or a musician, or making things. There was a movement that started quite some time ago that said: you know what, let’s go back to artisanship, to craftsmanship. Let’s buy from small breweries, and local farmers, and PR-less musicians. Let’s buy stuff that is made sustainably, with high quality, from people who like what they are doing and care about how it’s made. And while not universal by any stretch, I think there’s a growing consensus that having some proportion of the market run that way is a positive outcome for creativity, for innovation, and for ethics.

Software is the only field I can think of in which the whole market is upsidedown. People think of mass-produced software as high quality (and some of it is, to be fair), and that small-time proprietary software is sketchy whenever a larger alternative is available. There is no such thing as an “artisanal database developer” who lovingly designs a beautiful database, because anybody selling (or buying!) a database in the era of free, high-quality MySQL and Postgres is possibly mad. There is no such thing as a beautiful high-speed networking library, because all the people qualified to do that can make more money in HFT. And as soon as you start charging money for whatever it is you’re doing, people look at you funny.

But that’s not the only possible system. We could imagine a system where individual people can make good money from their work, and still not be 90s-Microsoft.

Probably the best prototype of this system is the Mac shareware market. Here you have a lot of really high-quality Mac apps, that people often fork over north of $30 or $60 or $100 to buy. It’s a simple model; ship high-quality software, sell it for money, answer to your customers. Not, e.g., to advertisers, or some weird corporate benefactor with a strategy to clobber somebody else’s corporate benefactor using you in a proxy war.

Towards a different model

The Mac model is extensible to software more generally, particularly with recent advances in modern payments technology. It’d work about like this:

You write a patch. In the commit message, you include some boilerplate:

This patch is proprietary, although it is licensed simply. Paying 0.002 BTC to the address 1GyPKBt3Tpgqzc8Nbd8tmvRQUQpJPZH41Y grants you the right to use or modify this patch on an unlimited number of devices that you control, or on one device controlled by an unlimited number of people.

With the legal boilerplate out of the way, there’s a simple command-line tool:

$ license https://github.com/project/project.git
calculating fees...
.008 to 1GyPKBt3Tpgqzc8Nbd8tmvRQUQpJPZH41Y
.002 to 1Archive1n2C579dMsAu3iC6tWzuQJz8dN
.001 to 1FBkJ3wAsEKQqkGgWCBj5mzhEi2Ax2xXf9

Total: .011BTC.  License?  Y/n
Y
Thanks.  You've licensed the software.

A Third Way

So what’s so interesting about this approach? For one thing, it is a “collaborative” model–it allows people all over the world to work on something together without any formal commercial relationship. In that sense it’s very much like FOSS.

On the other hand, the people who work on the software are compensated directly by the users of that software, for the act of creating the software itself. So in that sense it’s very much like proprietary software.

What spins out of this model is a Third Way; a development model that takes some aspects of both prior systems and blends them in a new form.

What I’m proposing is not entirely new; for example, Assembly has been working on how to organize projects along these lines. But where Assembly’s model requires a benevolent dictator (and offices to staff them, etc.) our Third Way is completely decentralized.

Common objections

Of course, there are a lot of problems with this. First and foremost, it’s incompatible with the whole way we practice collaborative “open” development now. For example, it’s GPL-incompatible, and can’t be accepted at projects that adopt a BSD or MIT licensing strategy either.

Let me be clear. I’m not suggesting that this is a strictly better model and that anyone should switch. I’m suggesting that it is a different model, that it can produce different kinds of projects than we have now.

For example, we’ve known for some time now that OpenSSL and GnuPG are chronically underfunded, at least until some journalist raises the alarm. What we don’t know is that behind them are many other underfunded critical projects. I think our Third Way might produce different results than either open source or proprietary software has produced so far.

Another objection is that letting just anyone submit a patch demanding arbitrary money would get unwieldy. But I think this can be resolved the same way patch licensing is resolved now: by each project setting guidelines for what kinds of patches are accepted. One project may decide a patch can’t be more than $.001 BTC, another might ensure licensing fees only need to be paid for 2 years to avoid the Mickey Mouse problem, and so on. I think community consensus can be an effective resolution mechanism for these issues.

A third class of objections is that if this would have worked, it would have worked by now. Notwithstanding the fact that this argument can be used against anything new ever, I think it is wrong here for a few reasons.

For one thing, platforms like Assembly have produced actual software of value that would not have otherwise existed. You can argue the magnitude and the details of it, but the idea there is something categorically wrong with the approach is empirically false.

Secondly, a Bitcoin-based system improves on earlier approaches in several material respects. Under previous proposals you’ve needed a benevolent dicatator that everybody trusts to handle the funds, and software developers are not exactly the trusting sort, but here that problem is resolved without any central authority. Secondly you have failure modes like “what if we mail the check but the person has moved” which have now been solved structurally with Bitcoin.

Open incentives

It also does an interesting job of balancing what I think are the real core freedoms of software–the freedom to examine and modify the software, to contribute, and make your changes available to others easily, with the freedom to put a roof over your head while doing it. The existing models all focus on one side or the other, I think to the detriment of the variety of software that gets produced.

The big myth of open source is that one day we will have high-quality, free, and unrestricted software packages for every conceivable purpose. The reality is that that will never happen, and if by some outside chance it does, we will live in a wonderful world of free software, without being able afford the electricity or hardware to run it, because will all be unemployed.

Instead I think we need to be charting a course for high-quality, free, and widely-available software, that is reasonably priced, such that the people who write it can continue to do so. “Sustainable software development”, if you like, where the people writing the software have a financial relationship with the people using it, instead of being authored by corporate benefactors with strange agendas. Where the incentives between users and developers are better aligned, and visible in the git log for everybody to see. Open incentives, not just open source.

And taking an incentives-aware approach also has positive effects on the lives of software developers, and the quality and quantity of software they can write, and the software that can even exist. In some cases, perhaps in most cases, we need to be taking a look at the true price of software freedom, and if we can negotiate ourselves a better deal to get more freedoms at a lower cost. Because from what I can tell, we’ve gotten the raw end of the deal so far.

---

Want me to build your app / consult for your company / speak at your event? Good news! I'm an iOS developer for hire.

Like this post? Contribute to the coffee fund so I can write more like it.