Review: Roads and Bridges, by Nadia Eghbal

[Russ Allbery]

Roads and Bridges
by Nadia Eghbal

Publisher: Ford Foundation
Copyright: July 2016
Format:    Epub
Pages:     143

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 [1] 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

[1] https://www.fordfoundation.org/library/reports-and-studies/roads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure/

-- 
Russ Allbery (eagle at eyrie.org)              <http://www.eyrie.org/~eagle/>