There is a very specific part to MOSS gardening that I have raised in various forums on digital commons preservation, but never wrote down in a referable form.
It’s worth making it the fourth pillar, because it relates to the most difficult to grasp thing, that undiscovered country, the future.
And, less directly, it relates to the wider ecosystem, larger than any individual MOSS project.
There are various forums on the globe which concern themselves with “open source sustainability”. Quite a few of them are politically driven: politics “suddenly” discovered that the world they’re concerned with already relies heavily on open source. So what can politics do to make this commons sustainable?
Political institutions do not have much of an overlap with the open source community. I therefore applaud the European Commission’s efforts to regularly attend FOSDEM in recent times, and the semi-related FOSDEM track on public digital infrastructure this year.
But there is a structural problem here: individual MOSS gardeners may not attend this conference, or otherwise engage with the Commission. In fact, very few will, comparatively speaking.
Plus, there are corporations like RedHat or GitHub that regularly appear at the “FOSDEM for politicians”, i.e. the EU Open Source Policy Summit.
The key point here is that there is a deep disconnect between what the Commission sees as open source, and what the community actually is like. FOSDEM stands a better chance at bridging this divide, but is not fool-proof.
With this said, the fourth pillar is predominantly aimed at politicians, from Europe or elsewhere.
It’s called “the future” because it does not really deal with the day-to-day concerns of MOSS projects. Instead, it looks beyond to what could and should be.
Embrace MOSS
I repeat, it’s best to re-evaluate your notion of what open source actually means. Instead, embrace MOSS. It’s soft, nourishing and calming.
Jokes aside, I understand that the notion of engaging with individual MOSS maintainers with their potentially widely diverging needs is unusual, if not downright impractical.
My suggestion isn’t so much to try harder. While I would welcome more interaction such as at FOSDEM, eventually we’ll run into some limit of what you can reasonably do, or what maintainers can do in return. “Speak to us more” is correct, of course, but also impractical at some point.
What I mean by embracing MOSS is something else: you need to take on board how the human scale and the need for preservation work. Open source isn’t some ridiculously profitable branch of the world’s oldest computing company IBM.
It’s more like your kids’ football club, or your allotment garden club.
Things are chaotic, inefficient, and unreliably. Supplying the football club with a few license of Office 365 isn’t going to make it work more smoothly. The problem isn’t digitization of processes, it’s that Martha who takes care of registration fees just became a grandmother, and now has less time to follow up on those, because she’s babysitting a lot.
The reason I made such a fuss about MOSS scale is that you need to meet people where they are. But this isn’t literal, although it helps.
It’s more that you may well discover that that developers will not bother to sign up for NGI funding, because the funding criteria are too complicated.
NLNet Foundation has in my experience been the single NGI funding entity that got this right. Their funding requirements are extremely easy to understand, with very little formality.
But understand that this is still enough to turn people away.
Maturity Matrix
My suggestion is to construct a comprehensive maturity matrix.
On the one hand, Horizon Funding already has a pretty decent categorization of technical maturity with its Technology Readiness Levels. This should likely form one axis of the matrix.
The other could be something akin to maturity models. One might wish to also reflect that there is an organizational maturity lower than “initial”, which could be named “individual” or some such. Many MOSS projects have no organizational structure whatsoever, because they have single maintainers.
The grid that these axes create may give you an indication of the scope of “open source”. It is neither just individuals scratching an itch. Nor is it just corporations building on exploitative Open Core models. Nor is is it just those projects that efforts such as Sovereign Tech Funds target, which have a long history of wide-spread use.
The mildly terrifying reality is that the Linux distributions that have all but eaten the market shares of proprietary operating system vendors in the server space – yes, let that sink in in this context – contain a multitude of projects from all sectors in that matrix.
Which means that in order to help “open source”, your solutions must be tailored to each of those sectors.
Innovation Pipeline
I say “must”, because there is no predicting the future. We cannot, today, say whether this hobby project or that will change the world tomorrow.
The only thing we can say with certainty is that the current support system suffers from intense survivorship bias.
Just as is common in venture capital circles, we treat the successes as blueprints for the next effort, but neglect to consider that there are more lessons to be learned from the failures.
So the only reliable way out of this situation is to support all of the matrix’s sectors.
It is IMHO perfectly fine to refine funding criteria and amounts on the maturity matrix. Make it incredibly low effort to get a few bucks for a couple of changes to the lowest maturity sectorArguably, the administrative overhead of approving miniscule funding amounts may be the best argument in favour of Universal Basic Income.
. At the highest maturity, it’s fine to require a lot more, for a lot more funding.
But there is no escaping the fact that in MOSS, the innovation pipeline starts pretty chaotically and unpredictably. If this is ignored, we’ll miss out on a lot of innovation.
Capacity Building
Support should not be merely given in terms of funding, although there are good arguments for this.
The key argument in MOSS gardening scale is that demands must never outgrow the projects’ capacities. The only reasonable conclusion, then, is that in order to guarantee the future of open source is to ensure that project capacity is increased.
In social programmes, there is sometimes a debate over whether to fund e.g. a food bank vs. giving homeless people funds so they can feed themselves.
What working with such projects has repeatedly shown is that people in a situation where they need help have the best understanding of the form of help they need.
That in turn means that providing funds with fewer restrictions on how to spend them generally leads to more meaningful improvements than offering guided programmes aiming in the same general direction.
But this isn’t a “yes, but” situation. Like improv, it’s a “yes, and” thing.
Capacity building can mean the project hiring a contractor for a while, but it can also mean taking courses on community management. It really depends.
What any programme should include, is the ability for a project to access learning resources in how to increase their maturity level.
It’s easy to treat organizational maturity as distinct from capacity, but it’s really the same kind of thing. It’s just about a different kind of capacity, the kind I addressed in the third pillar.
If you want to be able to rely on a plethora of projects in the future, ensure that the projects can grow from a shower-thought to the thing the economy can can build on.
You build in checks at the progression from one maturity slot to the next.
A Singular Historical Moment
I want to stress something else, something I put into my address to the Datacom Industry Association’s launch event:
We currently experience a singular moment in history, the kind that will not repeat in our lifetime.
- Technology innovation was largely driven by the USA in recent decades, at least when it comes to software.
- National Science Foundation’s funding in the USA has been gutted.
I put on a distinctly European hat here, but the argument applies to any nation or political union: there is a void now in setting the direction of technological development worldwide.
You can step into that void now, and imbue it with your values.
Or you leave the future to someone else.
Speaking for Europe, efforts have been underway towards “digital sovereignty” for a while now. This can be interpreted in a distinctly nationalistic way, or in the sense that reliance on outside technology partners is not reliable in crisis moments.
I will set aside for a moment which I think of as important. But if the self-understanding of the EU is that its digital sovereignty builds on open source, then it is not a choice, but mandatory to fill this void as quickly and comprehensively as possible.
There is no better strategy here than diversification. And there is no more diverse field than the collection of tiny MOSS gardens out there.