Roads and Bridges

Subtitled The Unseen Labor Behind Our Digital Infrastructure, Roads and Bridges isn't a book. It's a long report for the Ford Foundation, available for free from their web site. But I read it like a book, so you get a review anyway.

If, like me, you've spent years in the free software community, you'll know much of this already. Eghbal starts with a survey of the history of free software and open source (skewed towards the practical and economic open source analysis, and essentially silent on ethics), and then a survey of how projects are currently organized. The emphasis, consistent with the rest of the report, is on how these free software building blocks underlie nearly all the consumer software and services used today. Eghbal singles out OpenSSL as her example of lack of infrastructure support due to Heartbleed and the subsequent discussion of how vital OpenSSL is but how little funding it received.

Eghbal hit her stride for me at the end of the third section, which tries to understand why people contribute to open source without being paid. I'm a bit dubious that many people contribute to build their personal reputation, since that's not a commonly stated reason in my areas of the free software community, but Eghbal's analysis of the risk of this motive from the infrastructure perspective seemed on point if this is becoming common. Better was her second motive: "the project became unexpectedly popular, and the maintainer feels obligated to support it." Yes. There is so much of this in free software, and it's a real threat to the sustainability of projects because it's a description of the trajectory of burnout. It's also a place where a volunteer culture and the unfairness of unpaid labor come into uncomfortable tension. Eghbal very correctly portrays her third reason, "a labor of love," as not that obviously distinct from that feeling of obligation.

The following discussion of challenges rightfully focuses on the projects that are larger than a weekend hobby but smaller than Linux:

However, many projects are trapped somewhere in the middle: large enough to require significant maintenance, but not quite so large that corporations are clamoring to offer support. These are the stories that go unnoticed and untold. From both sides, these maintainers are told they are the problem: Small project maintainers think mid-sized maintainers should just learn to cope, and large project maintainers think if the project were "good enough," institutional support would have already come to them.

Eghbal includes a thoughtful analysis of the problems posed by the vast increase in the number of programmers and the new economic focus on software development. This should be a good thing for free software, and in some ways it is, but the nature of software and human psychology tends towards fragmentation. It's more fun to write a new thing than do hard maintenance work on an old code base. The money is also almost entirely in building new things while spending as little time as possible on existing components. Industry perception is that open source accelerates new business models by allowing someone to build their new work on top of a solid foundation, but this use is mostly parasitic in practice, and the solid foundation doesn't stay solid if no one contributes to it.

Eghbal closes with a survey of current funding models for open source software, from corporate sponsorship to crowdfunding to foundations, and some tentative suggestions for principles of successful funding. This is primarily a problem report, though; don't expect much in the way of solutions. Putting together an effective funding model is difficult, community-specific, and requires thoughtful understanding of what resources are most needed and who can answer that need. It's also socially fraught. A lot of people work on these projects because they're not part of the capitalist system of money-seeking, and don't want to deal with the conflicts and overhead that funding brings.

I was hoping Eghbal would propose more solutions than she did, but I'm not surprised. I've been through several of these funding conversations in various communities. The problem is very hard, on both economic and social levels. But despite the lack of solutions, the whole report was more interesting than I was expecting given how familiar I already am with this problem. Eghbal's background is in venture capital, so she looks at infrastructure primarily through the company-building lens, but she's not blind to the infrastructure gaps those companies leave behind or even make worse. It's a different and clarifying angle on the problem than mine.

I realized, reading this, that while I think of myself as working on infrastructure, nearly all of my contributions have been in the small project. Only INN (back in the heyday of Usenet), OpenAFS (which I'm no longer involved in), and Debian rise to the level of significant infrastructure projects that might benefit from funding. Debian is large enough that, while it has resource challenges, it's partly transitioned into the lower echelons of institutional support. And INN is back in weekend project territory, since Usenet isn't what it was.

This report made me want to get involved in some more significant infrastructure project in need of this kind of support, but simultaneously made it clear how difficult it is to do this on a hobby basis. And it's remarkably hard to find corporate sponsorship for this sort of work that doesn't involve so much complexity and uncertainty that it's hard to justify leaving a stable and well-understood job. Which, of course, is much of Eghbal's point.

Eghbal also surfaces the significant tension between the volunteer, interest-based allocation of resources native to free software, and the money-based allocation of resources of a surrounding capitalist society. Projects are usually the healthiest and the happiest when they function as volunteer communities: they spontaneously develop governance structures that work for people as volunteers, they tend towards governance where investment of effort translates into influence (not without its problems, but generally better than other models), and each contributor has a volunteer's freedom to stop doing things they aren't enjoying (although one shouldn't underestimate the obligation factor of working on a project used by other people). But since nearly everyone has to spend the majority of their time on paying work, it's very difficult to find sustained and significant resources for volunteer projects. You need funding, so that people can be paid, but once people are paid they're no longer volunteers, and that fundamentally alters the social structure of the project. Those changes are rarely for the better, since the motives of those paying are both external to the project (not part of the collaborative decision-making process) and potentially overriding given how vital they are to the project.

It's a hard problem. I avoided it for years by living in the academic world, which is much better at reconciling these elements than for-profit companies, but the academic world doesn't have enough total resources, or the right incentives, to maintain this type of infrastructure.

The largest oversight I saw in this report was the lack of discussion of the international nature of open source development coupled with the huge discrepancy in cost of living in different parts of the world. This poses strange and significant fairness issues for project funding that I'm quite surprised Eghbal didn't notice: for the same money required to support full-time work by a current maintainer who lives in New York or San Francisco, one could fund two or three (or even more) developers in, say, some eastern European or southeast Asian countries with much lower costs of living and average incomes. Eghbal doesn't say a word about the social challenges this creates.

Other than that, though, this is a thoughtful and well-written survey of the resource problems facing the foundations of nearly all of our digital world. Free software developers will be annoyed but unsurprised by the near-total disregard of ethical considerations, but here the economic and ethical case arrive at roughly the same conclusion: nearly all the resources are going to companies and projects that are parasitical on a free software foundation, that foundation is nowhere near as healthy as people think it is, and the charity-based funding and occasional corporate sponsorship is inadequate and concentrated on the most visible large projects. For every Linux, with full-time paid developers, heavy corporate sponsorship, and sustained development with a wide variety of funding models, there are dozens of key libraries or programs developed by a single person in their scant free time, and dozens of core frameworks that are barely maintained and draw more vitriol than useful assistance.

Worth a read if you have an interest in free software governance or funding models, particularly since it's free.

Rating: 7 out of 10

Reviewed: 2018-01-28