Pay to play? Don't expect maintainers to solve your supply chain issues for free

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.

The new enterprise burdens

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: 

• Security information and auditing: Security assessments of open source packages have traditionally been carried out by third parties, either through in-house security teams or by the distributed process coordinated through the MITRE Common Vulnerabilities and Exposures database. With new security training like the Linux Foundation’s CII badges, and projects like OpenSSF and Google’s SLSA, the new buzzword is “end to end”—meaning maintainers and projects must make themselves security experts and create security controls. While this is almost certainly a good idea for the industry overall, it’s yet more expectations of work with no immediate prospect of direct compensation.
• Legal metadata: Traditionally, open source communities like GNU, Debian, and Fedora believed (with good reason) that the default level of mandatory licensing metadata was at the package level, with per-file licensing information often disfavored at best and unrepresentable at worst. SPDX, followed more recently by clearlydefined.io, have decided that license information must be complete, machine-readable, and accurate in every file. This is clearly correct for all users—but definitely not useful for all of them. In practice the vast majority of the benefit accrues the most deep-pocketed enterprises, who have the most regulatory burdens and exposure to license-related litigation. In the meantime, if we actually want accurate global coverage, the vast majority of the burden will fall on maintainers, and require intricate legal assessment. (Adding detailed licensing metadata to the Linux kernel took literally years.)
• Procurement information: The newest ask from industry is to provide Software Bills of Material (SBOM) throughout the software stack—which inevitably includes vast quantities of open source. Again, this is not entirely unreasonable, and indeed open source has long led the way here via the package management techniques that open source language communities pioneered. But the completeness of coverage and depth of information being demanded (including, in some proposals, information about the identity of developers) is a step change in what is required—primarily to benefit the governments and massive enterprises that can afford to do detailed, package-by-package analysis of software provenance.

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.

Is this work going to work?

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

Why “unfunded mandate”?

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.

According to the Tidelift 2021 managed open source survey, more than half of maintainers have quit or considered quitting because they were experiencing burnout. Source

Aligning incentives—by paying the maintainers

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.