For a long time, there were two basic tests for releasing open source: “does it do what I need it to do?” and “does it compile?” Sure, it was nice if it did things for others, but more than anything else it at least needed to be fun for the developer, and run at all for others.
Then with the rise of package management, things leveled up a bit: “Is it packaged?” Shortly thereafter, the increasing popularity of test-driven development added another requirement: “Do the tests pass?”
Each of these new requirements made more work for open source maintainers, but (by and large) maintainers didn’t grump too much about them. I think this happened for two reasons: first, the work was often aligned with skills developers needed to learn for their jobs; and second, they were broadly perceived as beneficial for all users of the software, not just corporate developers.
But that is changing—and in ways that may not work out so well for open source and enterprises.
Here in 2021, it’s clear that a new set of standards for open source is coalescing. These are bringing with them new labor to be done, either by open source developers or as part of a metadata overlay. These new standards include:
This new work may be quite different from previous waves of new obligations for open source developers—and we should think about why that is, and what we might do about it.
As I suggested in the opening to this piece, the continued maturation of open source has regularly placed new burdens on maintainers. (At Mozilla, we used to call these “table stakes”—a poker term, indicating the things you had to do to even sit at the poker table, or in tech terms, to be considered for enterprise use.) So in some sense this new wave of obligations is nothing new. But I do want to suggest that in two significant ways, these new mandates are problematic.
First, this work is increasingly highly specialized, and so less helpful for individual maintainers to learn. The strongest open source developers have always had a diverse set of skills (not just coding, but also marketing, people management, etc.). That’s been part of the draw of open source—you learn those things along the way, making you a better developer. But when we start adding more and more requirements that in a corporate setting would be covered by specialists (e.g., a legal team or a security team), we reduce the additional value to developers of participating in open source.
To put it another way: developers clearly serve their self-interest by learning basic programming and people skills. It is less clear that they serve their self-interests by becoming experts in issues that, in their day jobs, are likely delegated to experts, like procurement, legal, and security. This works out fine in open source projects that are big enough to have large, sophisticated teams, but those are rare (even though they gather the lion’s share of press and attention).
Second, these new and increasingly specialized requirements primarily benefit a certain class of open source users—large enterprises. That isn’t necessarily a bad thing—big enterprises are important in a lot of ways, and certainly the risks to them deserve to be taken seriously.
But in a world where hundreds of billions of dollars in enterprise value have been created by open source, and where small educational/hobby projects (and even many small companies) don’t really benefit from these new unfunded mandates, it is likely that developers will focus on other things, since few of them got into open source primarily to benefit the Fortune 500.
In other words, many open source developers enjoy building things that benefit themselves and their friends, and are even willing to give up nights and weekends for that. If meeting these new requirements mostly benefits faceless corporations, we may need to find other carrots to encourage developers to create and maintain new open source projects.
According to the Tidelift 2021 open source maintainer survey, open source maintenance work is often stressful, thankless, and financially unrewarding. Source
You might be asking what that term “unfunded mandate” is that I just slipped into the last paragraph. In U.S. politics, an “unfunded mandate” occurs when a government requires someone else (usually, a lower-level government) to do new work, while not funding the new work.
Sometimes, unfunded mandates can be good—many times they are used to create equity and justice programs, for example, that local governments really should be doing as a matter of course. Arguably, many security initiatives fall into this category—burdensome, yes, but necessary for all of us to use the internet effectively.
But other times, they just create work for small entities that are already overwhelmed juggling the responsibilities of modern governance. If that sounds familiar to open source developers, no surprise—they’re already burnt out, and this is creating more work without creating more time, or money.
We were pleased to see Google call this issue out in a recent filing on SBOMs with the National Telecommunications and Information Administration (NTIA).
Unfortunately, much of the burden of maintaining our digital infrastructure falls on the backs of unpaid, volunteer contributors. The NTIA should carefully evaluate ways to fund and assist these communities as they work with industry to comply with new regulations.
Tidelift’s filing to the same NTIA call for comments made similar points about money, scale, and reliability. In response, in its own summary, the NTIA acknowledged that “funding sources” are a challenge, and also said:
“Further research is necessary to understand the optimal … incentives for sharing, protecting, and using SBOM data.”
Given the dynamic of increasing professionalization—or to put it more bluntly, increasing work—that I’ve described above, it is refreshing to see acknowledgement from significant industry players that developer incentives should be considered as we move into the next era of open. We as an industry must figure out how to address this together, or we’ll both fail to reach our goals and burn out developers—the worst of all worlds.
This post was originally published on opensource.com.