Towards Software Commons
A number of us have been working for the past six months to find a term, adjacent to but distinct from Free and Open Source Software (FOSS), to elevate developer sustainability to a value on par with user freedom. This is in response to Chef co-founder Adam Jacob’s proposal:
I think the way forward here is to make what I suspect is a loose confederation of folks using non-compete licenses to actually get together and draft their own set of values. To then brand that. And stand behind it proudly.
— Adam Jacob (@adamhjk) August 3, 2023
FOSS ensures user freedom, which is wonderful. Developer sustainability is also wonderful, and we’ve reached a point in the evolution of the tech industry and our society where it is time to converge on how we’re going to balance these two values.
A Widely Recognized Need
A number of prominent voices are recognizing the need to resolve this tension between the limitations inherent in Open Source and the challenge of developer sustainability, starting with the Open Source Initiative (OSI) itself:
Since the early days of the Open Source movement, companies have experimented with finding a balance between granting their users the basic freedoms guaranteed by Open Source licenses while also capitalizing on their investments in software development.
Yes, some CEOs are perhaps best described as bad actors conniving malicious rug pulls. Others are acting in good faith, genuinely intent on sharing their source code as permissively as possible without exposing their companies to the existential risk of harmful free-riding. Some even voluntarily share their financial success with the non-commercial maintainers in the ecosystem.
Regarding different models of sustainability, Jacob Kaplan-Moss, co-founder of Django, recently let loose a full-throated rant:
My fundamental position is that paying people to work on open source is good, full stop, no exceptions. We need to stop criticizing maintainers getting paid, and start celebrating.
Jacob and I are working with similar definitions of sustainability (and similar background colors lol). He writes:
When I talk about “sustainability”, though, I mean something very specific: “can maintainers live a decent-to-comfortable lifestyle writing free software?”
I recently wrote:
Open Source sustainability is when any smart, motivated person can produce widely adopted Open Source software and get paid fairly without jumping through hoops.
The main difference is in the qualifier, “without jumping through hoops.” My definition is narrower, and much of what Jacob wants to celebrate as “Open Source sustainability,” I would celebrate as “Open Source subsidization.” We’ve known how to subsidize FOSS since the beginning. The new and interesting thing will be when we sustain it: fair pay, without hoops. Jacob himself dreams “that society and governments will recognize free software as the public good that it most certainly is and fund it appropriately.” He doubts “it’ll happen in our lifetimes if at all.” I am optimistic! :-)
A second difference is that, whereas at Sentry we’ve stepped back, Jacob takes a strong stance on broadening the term “open source”:
Note the deliberate use of lower case. I’m not referring to Open Source™ as defined by OSI, nor to Free Software™ as defined by the FSF. I mean these terms in the broadest, most inclusive sense: “software with source code that I can read and modify and release variants of, perhaps under some conditions.” So I’m including OSI and FSF licenses, but also the Polyform licenses and the JSON license and, yes BSL in my version of “open source”.
The Codecov kerfuffle taught us to look for another term. As part of developing FSL (our BSL upgrade), we worked with the community specifically to make sure we do not confuse people about the OSI definition of Open Source. On a recent call, Stef and Nick made the point that with more and more legislation written with reference to Open Source, the Open Source Definition is becoming less and less changeable. Building further abstractions solidifies lower levels.
Post-Open
The very author of the Open Source Definition, Bruce Perens, is now also looking for what comes next. At a recent State of Open keynote, he snarked, “We have a great corporate welfare program,” and talked about the limitations of the support model for sustaining Open Source.
Bruce goes so far as to say that we need to “consider a radical departure”:
Open Source will continue to exist and provide the same rules and paradigm, and the thing that comes after Open Source should be called something else and should never try to pass itself off as Open Source. So far, I call it Post-Open.
The second pillar of Bruce’s vision for Post-Open is an expansion beyond low-level systems software to end-user applications. He wants to “reach the ordinary person” and to “make software for common people.” Yes, please! I’ve talked about this in the past in terms of “open products”:
I define an open product as “a technology product that happens to be open-source.” […] The open products I’m most interested in, however, are top-level, consumer-facing web and mobile products that stand on their own as consumer products first, and—almost as an afterthought—happen to be almost fully open-source to boot.
I’m excited to find Bruce talking about this. It seems to be a case of independent discovery: Bruce’s work on Post-Open, and the response to Adam’s call to action, to develop a new brand around a new articulation of values. This is a sign of an idea whose time has come.
Introducing Software Commons
Last week, I hit upon “Software Commons” as a candidate term for this new movement. The Wikipedia definition resonates, because it indicates a superset of FOSS:
The software commons consists of all computer software which is available at little or no cost and which can be reused with few restrictions. It includes open source software which can be modified with few restrictions. However the commons also includes software outside of these categories[.]
Amazingly, the domain was available. I bought it forthwith. It seems like a strong candidate, and it is gaining momentum both with those who, like Jacob, would be just as content to broaden “open source”, as well as some who would not. The parallel with Creative Commons is particularly suggestive:
[Creative Commons] is very popular, and you have licenses like CC BY-NC there so I feel the license categories listed fit perfectly well within what you’ve defined.
There is much work to do to hammer out the specifics of the software sharing models that should qualify for inclusion in Software Commons, but this feels to me like the right place to locate the conversation, because the two failure modes of a commons are the tragedy of the commons and enclosure. In the former, a majority of people overuses the common resource to the point of destruction, due to too few restrictions. In the latter, a minority of people gains control and excludes the majority, imposing too many restrictions. That is, the tension inherent in commons management seems to be exactly the tension we find in the software ecosystem today: between user freedom and developer sustainability.
If you think Software Commons might have legs, and you want to help find a balance of user freedom and developer sustainability that honors Open Source while evolving beyond its limitations, you can dive in on GitHub. 🙏