When Open Source goes proprietary, or starts thinking about the law...
A roundabout post about a 2012 chrome meeting that could have ended the open source chromium project.
At Google, I helped launch somewhere around 14,000 open source projects. Most were small, even inconsequential, in the grand scheme of things. I needed the small projects to keep the wheels of open source releasing greased. If I only worked on releasing ‘consequential’ projects they would have inevitably taken much longer, likely faltered, and the larger open source developer community would have a harder time understanding, trusting and accepting them into their world.
For the big and very important projects such as Android, Chromium, Go, we would spend significantly more time as a team and as a company in making sure they made sense and had the right motivations for releasing into Open Source.
For Android the motivation to be open source was largely about market adoption. At the time, Asian handset manufacturers were paying (or pirating) Windows CE and running their own dialers rather than paying the extra few dollars for Windows Mobile. Additionally, the Android team had at that point worked on a number of mobile operating systems1 and wanted to write their ‘last’ one with Android.2
For Chromium, we wanted to open source chrome under a regime friendly enough that folks using other frameworks could use chrome's advances in their browsers. Even though at the time the number of khtml based browsers was, uh, safari and chrome, we thought that if we could open source all the things we were doing in Chrome, then folks across the browser ecosystem could take our work and improve the overall state of the web with us. It was why we BSD licensed Chromium the way we did, as it would allow for the broadest license compatibility for all extant browser makers.
Both those projects did quite well, as you might imagine. Chromium would become the underlying technology for a number of browsers at a number of Google’s competitors. Much as Apple had forked KHTML and pulled it into WebKit, Chromium would fork away from WebKit to Blink.
There’s a thing that happens in popular open source and free software projects. It happens more often when there is overwhelmingly a single corporate or venture backer, but it seems to happen in a very particular way:
In 2012 I was called into a meeting with some of the Chrome leadership, including Sundar. They said they had a problem and were considering ‘closing’ or halting external open source releases, in essence stopping releasing into the chromium project.
It turns out that Yandex had decided to release their own browser based on Chromium. This was at a time of pretty intense “competition” in Russia. To put it diplomatically, there were a number of legal and extra-legal threats against Google’s operations there. This would happen in certain countries3 where the domestic capacity was given a huge leg up against the foreign competition.
Anyhow, when Yandex did the thing you do with Open Source software (fork and adopt), Larry Page felt what a lot of leaders would feel at this time: Why are we pouring so much into providing this competitor with what amounts to billions of dollars of free engineering? The chromium team was anything but small at this point, probably reaching close to a thousand folks.
It wasn’t a heated discussion or anything like it. It was more of a question of balance of investment. What is open source and released in chromium, and what is not. Are services like the malware checking, account sync services and the rest something that can or should be open sourced? What about the PDF reader? We found our way through, but these were fairly tricky discussions.
It was a conversation I’d have another dozen times at Google and elsewhere. Throughout the planets open source development communities, there’s been these points in time where teams:
Fork and go their own way.
Re-coalesce around a new center point/fork.
Switch licenses to a proprietary or less permissive open source license.4
Stagger open source and proprietary development with “The release becomes open source later” licensing. 5
Close development completely and studiously ignore the old code users and their adherents.
Close development completely, threaten the user base with lawsuits if they should use a fork of the open source version vs the ‘official’ proprietary one.
Litigate between big players in a software community. as we’ve seen in the recent WordPress/WPEngine case.
The laments I hear are very common. They range from the rare ‘why are we subsidizing a nation state competitor’ to the more often heard ‘Why are these free riders making more than we are from our own software’ to the very common: “They take take take and never give anything back”.
These often come down to confusing open source software development with a business model. It’s almost banal to say it, but releasing your software under an open source license means, simply, you will not be able to make per copy software revenue from it. Your points of control are constrained in ways that proprietary software licensing does not.6
For service, consulting and hosting revenue, you will need to out-perform those that might compete with you in these spaces. Failure to do so isn’t the fault of the license you chose, but in your misunderstanding what open source is and what customers might value.
One thing that I’m sensitive to, and what I speak with projects and companies about on the regular about, is to be careful what you provide as infrastructure for your project. To take an example out of thin air: If you setup a project wide plugin repository and everyone using your project depends on it, you have incredible insight into who is using your software, how they are using it, and what are the current trends to tack into or outright leverage with your developers, sales and support businesses.7
If you provide these resources unfederated8 you are creating a control point for your software community that can be leveraged for profit, control or anything else.you might desire. Trademark, ungranted patents, trade-dress and side-contracts are often also used as control points in both open source and proprietary software/ hardware/ Saas companies.
Throughout open source and free software development there have been people who have tried to introduce these sorts of critical path toll booths in the middle of established communities. In the 90s, the first real time kernel patches for Linux came with patents and a desire to exercise them that led the kernel community to reject those patches, the developer and the associated code.
Red Hat’s entire RHEL business was built on providing a for pay package distribution system with guarantees/SLAs businesses seemed to care for, charged by the CPU. It only really started to falter as the hyperscalers provided Linux distributions that were ‘good enough’ for most users, and really made them ask if they were getting value out of their RHEL subscription.9
Back in the dusty days of early C language standardization, there was a person who would assiduously document the libraries, publish under his own copyright and would try to get licensing revenue from those shipping C at the time. He was removed from the committee and they laboriously re-wrote the documentation to preserve C’s openness.
At Google, there were many and manifold meetings about what belonged in the Android open source project and what belonged in play services. Or what belonged in Chrome vs Chromium. What about k8s and its associated projects should be released as open source, released to a CNCF, or not released at all?10
The upshot of all this is that every case deserves thoughtful care on what to do about being a popular, powerful, depended on, project. Are you a utility? A commodity? A toll booth? In the early days of open source software, once a project was seen as too difficult to run, or insecure, or stopped advancing, that would be the sign that a project needed to be forked, replaced or supplanted in place.
What seems to surprise a lot of people is when a monied interest with a project (a public company, a venture backed startup, a big old tech company) starts to question their ongoing commitment to open source.
It’s actually something I expect from any project that gets to a certain size or level of popularity. I’d say it’s even a measure of their success. I sometimes help folks understand how to mitigate the negative externalities of being , so important, or a dependency, helping them figure out a path forward that works for their business, their project teams, their community of developers and users, and to do it all while not forgetting that which brought them to open source in the first place.
A bunch of them came out of General Magic, Be, Danger and Palm/WebOS. They had a number of operating systems under their belt.
You know which ones they are, and I’m not talking about New Zealand.
What’s funny is when this happens when they do not have the rights to do it with patches and external contributors, but that’s a different article.
As an aside, this never works.
It’s also a big selling point for open source . as developers are tired of being held hostage by software development companies.
Look at the Debian apt mirror system, which is particularly wonderful at not condensing power while not over-burdening Debian with the world’s package bandwidth.
Disclosure: I’m on the Rocky Enterprise Software Foundation board…