When our COO and cofounder Anne was CEO of the German fine foods company Delinero, they got sued.
You see, one of their many suppliers had provided a nice raspberry jam for them to distribute. It was unfortunately labeled "Himbeermarmelade", which apparently is verboten in Germany. The problem is that colloquially, everyone in Germany uses the word marmelade to mean "jam", so it wasn’t obvious that this would be a problem.
However, it turns out that there is a little known German law, the Konfitürenverordnung (Jam Regulation), that dictates that to be labeled “marmelade”, a product needs to contain at least 20% citrus. It didn't matter that this is counter to how everyone understands this word and how it's commonly used, what mattered is that some small interest group passed a law many years ago.
Anne's company had to get their suppliers to change the label on all the units that they wanted to distribute in Germany. The regulatory body forced her to avoid the term used in the Volksmund, the vernacular, the phrase that everyone actually uses, at her supplier’s expense and her customers’ confusion.
I would argue that this is roughly the state of "open source" today. It is the modern software developer’s marmelade, with the OSI as our Konfitürenverordnung, continuing to aggressively enforce a phrase that has since evolved in the popular vernacular.
But how do we move forward in a constructive way? How do we relabel our delicious jars?
How Not to “Open Source”
When GitButler Fair Sourced it’s client code, releasing it under a non-OSI approved license, we struggled to find a good phrase for how to announce it.
I felt that most people associate the term “open source” with “public on GitHub”. Furthermore, thanks to the semi-dangerous implications of the GPL/copyleft strain of licenses, people are also very used to checking which specific license something is under. I also didn’t want to confuse people by saying something awkward like “GitButler is now Source Available’d”, which seemed to me to indicate a “throw it over the wall” hands off style of code release.
So, we used the phrase “open”, hoping to be clear, but which instead brought out the attack dogs.
This helped us realize that there is a vocal minority who still, for very good reasons, finds this phrase protected and specific.
"open source" is not the logical negation of "closed source"
However, there is still a gap in the popular understanding of what public and engaged on GitHub is called, versus the technical 10 point definition of “Open Source” as self-regulated by the OSI.
The question for those of you who are a little younger could be, “but why is this a thing?”
Very well, let’s take a quick stroll down software memory lane.
A Quick History of Open Source
In order to explain why people got so upset about us using the phrase “open source” for public software under a generally permissive license with a non-compete clause, let’s do a whirlwind tour of the history of the phrase “open source” before we look at where we are today.
The early days of free software
At the dawn of semi-accessible computing in the 50s and 60s, software was mostly bundled with expensive computing hardware that took up entire rooms. The software was so inextricably bound to the hardware that it made no real sense to separate it.
Software was openly available and freely distributed by the hardware companies, partially because it had no value on its own. Changes were often made and sent back to the hardware company for redistribution, an early precursor to the kind of collaboration we will see in more modern times.
The closing of code and the rise of software companies
In the 70s and 80s when hardware became more commoditized and interoperable, software started becoming valuable on it’s own.
Software-only companies arose, people started buying specialized software. It began to have it's own intrinsic value. This value led larger hardware companies (such as IBM, AT&T, etc) to start closing down access to their expensively produced source code rather than freely distributing it.
The birth of free software
This led hobbyists and academics who now could no longer learn from and experiment with operating systems and other tools, people like Richard Stallman, to start building their own operating systems and tools that were protected from corporate interests like this.
In fact, they went so far as to create reciprocal licenses like the GPL, which meant that IBM and AT&T could not use anything they created or else it would force them to make everything they used it in free software too.
If we can’t play with your toys, you can’t play with ours either.
They named this movement “Free Software” and built a lot of amazing tooling such as Emacs and the GNU complier system, which is still today fundamental tooling that underlies most modern computing.
The fundamental focus of the free software movement was to ensure that users have the freedom to run, copy, distribute, study, change and improve their software. Freedoms that were taken away from them by the corporate interests that surrounded them at that time.
The Rise of GNU/Linux
However, they didn’t have a full operating system until the early 90's when Linus Torvalds entered the scene with the Linux kernel, a viable replacement for the stalled Hurd GNU kernel. Now with GNU/Linux and the growing numbers of talented developers constantly openly improving this software, there was a real alternative to the proprietary operating systems that dominated computing during the previous decade.
(To give you a sense of time here, the first website went online around this time in 1991)
By the late 90's, there was an entire ecosystem of free software tools that enabled individuals and even companies to build amazing things. The LAMP (Linux, Apache, MySQL, PHP/Perl) stack became used and depended on more and more. Free software was starting to become the foundation of more and more successful and growing companies.
The Birth of Open Source
In 1997, Eric Raymond published an essay titled “The Cathedral and the Baazar”, which made an argument that the way that free software projects like Linux are built is an inherently better model for developing software than top-down proprietary development methods.
This essay was then cited by Netscape in it’s justification for releasing the source code for the Navigator Suite, which became the Mozilla project.
When Netscape decided to release its source code, that prompted a strategy session in Palo Alto where Raymond and several prominent Linux and free software developers coined and agreed on pushing the use of a new term, “Open Source”.
The conferees believed the pragmatic, business-case grounds that had motivated Netscape to release their code illustrated a valuable way to engage with potential software users and developers, and convince them to create and improve source code by participating in an engaged community. The conferees also believed that it would be useful to have a single label that identified this approach and distinguished it from the philosophically- and politically-focused label “free software.” - (The History of Open Source)
Importantly, there is no real legal or practical difference between “free software” and “open source” - most licenses are compatible and accepted by both definitions. “Open Source” was simply a more business friendly rebranding to distance the practicalities of opening software from the more politically focused goals of Stallman and his movement in an effort to get more companies like Netscape to embrace the opening of professional source code.
Or, as the Free Software people put it:
“Open source is a development methodology; free software is a social movement.”
Open Source and the GitHub Era
The definition and marketing of the phrase “Open Source” was in 1998, more than 25 years ago now. So what has happened in the world of Open Source and software development in the last quarter century of computing?
Well, of course I come from a place of incredible bias here (I was one of the co-founders), but I think it’s difficult to objectively disagree with the opinion that GitHub, and the GitHub-style of software development, has had a phenomenal impact in the world of open source software, mostly over the last decade.
What has changed the most is the gradual shift from the mentality of 1998. At that time, the developers working on permissively licensed software were trying to coin a phrase that helped convince corporations to embrace open software. Today, nearly all open source software is written by or financed by corporations.
Free software used to be about sticking it to The Man, but today The Man produces nearly all the free software.
I believe that one big change was the standardization of development workflows, largely ushered in by, defined by, and evangelized by GitHub. Before GitHub, there was always a big difference between how you worked on open software projects versus how you worked on corporate, proprietary software projects. The methodologies, tools and workflows were massively different between those two types of development.
Today, however, there is often nearly zero difference between how a team works on an internal, closed project and an open source one.
- Everyone uses Git.
- Nearly everyone uses Pull Requests (or Merge Requests, or any other competitors clone of this functionality).
- Most teams use some form of GitHub Flow (Trunk Based Development, Gitlab Flow, etc).
Today, that public bit on your repository being set or not set is nearly the only difference. 25 years ago this was not at all the case, these processes were massively different with a lot of frictions between them. Now to open source something involves nearly no change in process, only visibility.
What’s Next for Open Source
So now that the “Open Source” marketing approach worked so well that nearly every corporation is using and producing open source software, has the open source (and thus, free software) movement won? Is the battle over? Is there anything left to fight about?
Well, there are two huge issues in the Open Source world today. Both issues that have largely sprung up due to the success of the corporate Open Source movement. The success of Open Source has brought about completely new challenges.
The first is about developer sustainability and the second is the problem of viable commercial open source. Let’s dig in.
The Problem of Developer Sustainability
Now that Open Source is heavily depended on by nearly every commercial company, we’re running into sustainability and maintainability problems. These are problems that really didn’t exist at scale before.
A very famous recent example of this is the XZ Utils backdoor exploit, where an open source maintainer accepted a subtle but significant compromise from a bad actor, partially due to burnout and harassment of the maintainer.
However, I see this in nearly every maintainer that I talk to. It’s almost impossible to make money by writing and maintaining Open Source software, due to several factors. Everyone wants and expects free shit, and nobody feels that they need to support the people making this all possible.
The strange new truth is that most open source developers and maintainers are now patronized by large corporations. If you look at Linux, Git, Ruby, React, etc - nearly any important open source project, many or most of the contributors are professionally employed to do that by a corporate benefactor like GitHub, Microsoft or Red Hat.
There is nearly no good mechanism for a software developer to make a decent living by maintaining projects like XZ Utils. What would be more ideal is to have not one company paying each developer, which is subject to the whims of corporate KPIs and management changes, but instead to have thousands of companies pay a very small amount to professional maintainers.
The main problem is that there is no good way to do this currently. There is little to no incentive for companies to do this and there are few ways to aggregate and disperse such funding.
There are promising initiatives along these lines, such as GitHub Sponsors, Thanks.dev, Liberapay, and Tidelift, but none of them has yet really solved the problem of providing the right incentives for companies to contribute. It’s mostly a “this is the right thing to do” charity plea, which I believe is unlikely to get the legs that a movement like this needs.
Sentry has been working on a new initiative called the OSS Pledge, which GitButler is planning to participate in once it launches in October, but it’s yet to be seen if something like this can solve this large and growing problem of developer sustainability in the Open Source ecosystem.
The Problem of Commercial Open Source
The second growing problem in the Open Source ecosystem is the problem of the new generation of Commercial Open Source.
Developers have now been growing up for decades loving Open Source and open communities, and when they start companies and projects, by default they want them to be open. However, there are corporate sustainability issues with Open Source, just as there are with individual maintainers.
As we’ve seen from examples like Elasticsearch and Redis, it’s risky to pour time, money, and in some cases investor money, into professionally developing software when there is a risk that it could be “Jeff’d”, hosted by Amazon or otherwise co-opted by some other large player that can directly (and in some ways, unfairly) compete with you using your own work.
Many professional makers, with employees and investors to worry about, want to be able to invest time, blood and treasure into software and make sure that it can’t be taken later on and used against them. For many, this means becoming creative about licensing, for many more is simply means keeping the source code closed.
Somewhat ironically, The Man is now using Open Source licenses to stick it to the developer!
I believe that the Fair Source movement is a great and necessary solution to this growing problem, filling a gap in the Open Source ecosystem that has caused increasing trouble and confusion over the last few years. It provides a new term to refer to a mostly permissive, source available, GitHub-community engaged professional project, and is a badly needed solution that I believe will encourage more previously closed sourced projects to be publicly released.
The Future of Collaboration
The future of Open Source is not just Open Source and the OSI and their 10 point Konfitürenverordnung.
The future is a combination of Open Source when it’s possible and valuable for everyone, Fair Source when it’s needed for safe investment, and large scale collective funding of important foundational open libraries and projects.
We need to collectively make critical open source library maintenance sustainable. We need to embrace a class of accepted, sustainable, commercial source available licenses and normalize them. We need to continue to open source under permissive OSI licenses everything that we possibly can. Most of all, we need to make closed source a thing of the past.
So, what can you do today?
- If you have closed sourced software, make it Fair Source.
- If you depend on OSS, join us in the OSS Pledge.
We'll see you in the future.