Consider the maintainer

Eghbal's title, "Consider the maintainer", is derived from David Foster Wallace's 2004 essay "Consider the lobster". The author visited the Maine Lobster Festival, then wrote about the practice of throwing live lobsters into boiling water to cook them. "Is it all right to boil a sentient creature alive just for our gustatory pleasure?" Eghbal was quick to point out that she was not giving an animal-rights talk. Instead, she wanted to raise a pair of similar questions: is it OK if a project struggles or dies because its maintainer can't keep up anymore, and is it OK to compromise or ignore maintainer happiness so we can have free and open-source software?

Wallace said that the lobster question was not just complex, it was also uncomfortable. He dealt with it by just not thinking about it most of the time. Questions about how the open-source culture works can be equally uncomfortable, Eghbal said. The talk was not intended to create any sort of moral outrage, but to raise a set of questions to be explored and talked about. We should think about what goes into the production of free and open-source software, and what we're willing to tolerate to have free-as-in-freedom and free-as-in-no-cost software.

The problem

So what is the core of the problem? It comes down to the huge growth in the number of people consuming open-source software. In 1998, when the Netscape browser source was released, it was downloaded 180,000 times in the first two weeks, a huge number at the time. In 2017, a Lodash library release got 18 million downloads in the same time period. In 2001, there were 208,000 users on SourceForge; there are 14 million on GitHub now. But ⅔ of the top GitHub projects have just one or two maintainers. In other words, we have seen a huge growth in the number of users of open-source software, but not in the number of maintainers.

She had a couple of theories as to why that might be. One is that the style of production has simply changed; now we have large numbers of tiny projects that, necessarily, have few maintainers. The other is that being a maintainer simply is not glamorous. Developing new code is fun, maintaining an existing project is less so; maintenance can be a hard job to keep up for years. Add to that the expectation that maintainers will respond to every issue raised with their software; it is as if bloggers were expected to respond to every comment on their work.

Consumption can scale, but only if there is no cost to the provider. This is essentially true for written material, but it is not the case for software. Many incoming users and developers are new to software development; maintainers have to teach them from the beginning. Sites like GitHub (where Eghbal works) have not helped maintainers in dealing with the influx of merge requests. Maintainers, she said, often have to face these issues alone, in isolation. There is a lack of support and mentorship in our community for maintainers. Meanwhile, unhappy users are more than willing to yell in public about their disgruntlement (she showed a few examples), adding to maintainer stress.

We are not teaching people how to be maintainers, she said; why aren't we talking about this? The maintainer role tends to be minimized or ignored, and maintainers are told that negative behavior from users is normal. So they don't know when they should push back. But we seem to be unable to even talk about the experience.

Richard Stallman stated that defending software freedom is more important than the popularity of the people working on it. The Debian Social Contract states that: "Our priorities are our users and free software" but does not address the needs of maintainers. The Open Source Initiative exists to advocate for the benefits of using open source; helping producers is not in its mission statement. Both free software and open source are focused on user needs; whether it is promoting the four freedoms or pragmatic benefits, neither philosophy talks about maintainers.

Freedoms for maintainers

If we were to articulate the freedoms of software producers, what might they be? At a minimum, she said, they should include the ability to decide who participates in a project, to say "no" to contributions or requests, to define the priorities and policies of the project, and to step down or move on when the time comes. In general, users cannot expect more from maintainers than they are willing to give. These "four freedoms for maintainers" look back to the early principles of free software, where users were expected to work more actively to help themselves.

There are a number of other things we can do to make project maintenance more sustainable. One would be to put together a set of agreed-upon community best practices. These would address questions about how to attract contributors, how many contributors are enough, how to turn first-time contributors to a regular contributors, and so on. How quickly should a maintainer respond to issues? We have a bunch of community wisdom in this area that has not yet been written down, and a lot of that wisdom has needed to change as the environment has changed.

There is, she said, a deep need for better project analytics for maintainers, who need better metrics about the usage of their code. Maintainers should be able to measure user behavior as they wish; that would allow them to prioritize their own work and possibly raise funding. She noted that the idea is often controversial, but repeated that we should encourage maintainers to do it. One might have expected this idea to be especially controversial at linux.conf.au, which tends to have a strong focus on privacy, but the idea was met with significant applause in the room. Maintainers also need more and better tools for testing, triaging issues, monitoring, and more.

Maintainers should be encouraged to decide and communicate what the support status of their project is. There is a widespread assumption that maintainers are obligated to respond to every question or pull request that comes their way; we should experiment with that assumption. Maintainers should be able to say that a project is simply not accepting contributions, or to limit contributors to a small, known group of developers. Users, of course, will always retain the right to fork the project should they wish to maintain it in a different manner.

Maintainers need help in finding funding for the work they do. Not all maintainers want to be paid for that work, and others are paid by their employers, but those who would like support should have a way to seek it out. Current funding sources tend to be ad hoc and hard to get for the long run, and it's not clear how a maintainer should get funding.

Finally, more attention should be paid to the existential questions around maintainership. What does it mean to be a maintainer in the first place? What does it take to be a good one? Maintainers need to share their experience in this area as the number of small, single-maintainer projects continues to grow.

There has been some discussion of this problem in the past. Eric Raymond said that "with enough eyeballs, all bugs are shallow", but Steven Webster responded in 2004 that "how those eyeballs are organized" is equally important. She has read a lot of material written about open source in the late 1990s and early 2000s, and noted that the success of open-source software was equated with the success of the Linux kernel, but the two are not the same thing. The future looked rosy when we were looking at a small number of large projects supported by companies like Red Hat or organizations like the Apache Software Foundation. It was assumed that open-source software was so important that we would find a way to make it sustainable.

But then social media and GitHub happened and, along with them, came an uptick in adoption that nobody was prepared for. We all stopped talking about how projects take care of themselves; there has been nothing interesting written in this area since 2005. So we are working from an ideal that is based on how things were 20 years ago. People will point to Linux as an example of success while ignoring hundreds of thousands of projects launched since then that do not have the same level of support; the challenges these projects face are being swept under the rug. History did not end with the success of Linux; instead, it started a new chapter, and we have to confront the awkward fact that open source today isn't what it was 20 years ago.

"This stuff is confusing," she concluded, noting that the world is shifting in complex ways. But we shouldn't ignore these changes just because we may not understand them. We shouldn't try to regress back to how things used to be. Instead, we need to honestly acknowledge the place we have reached and look for the best way forward.

Q&A

The talk clearly got the audience thinking, as shown by the numerous questions that were asked afterward. The first went straight to the point: what is GitHub's responsibility in all of this? Eghbal responded that this question had a lot to do with why she joined the company six months ago. She would like to help establish a clear relationship between GitHub and the maintainers, and to make it easier for maintainers to be heard.

Another questioner noted that a lot of the numbers in the talk were dominated by small hobby projects. How can we identify the important projects among them? Eghbal replied that it was clear by now that "stars are useless"; she said the dependencies are a better metric. That is part of why she would like to see a better emphasis on metrics in general.

Cat Allman noted that maintainers seem to have lost a lot of authority and prestige over the years. Maintainers are treated as obstacles to the next great thing, rather than as people with a global view of the project. Eghbal agreed, noting that ever more people are identifying themselves as developers, but they touch less of the software than before. The world is becoming more malleable, which is a good thing, but people are forgetting that there are humans maintaining it all. She is particularly struck by people who say that open source has no respect for its users; that ignores all that is happening to make that code available in the first place.

When asked about the tension that can arise when some developers (but not others) in a volunteer project receive funding, Eghbal acknowledged that the problem is a hard one. The key there, she said, is transparency.

Bradley Kuhn noted that many of the problems raised in the talk were present with proprietary software as well; has the proprietary world handled them any better? He sees free software as a necessary but not sufficient condition for addressing some of these issues. But GitHub's software is proprietary; has that solved these problems? Eghbal responded that things are different when people are paid to deal with entitled users; the stakes are different when you are doing that as a volunteer.

The last question noted that there was a Reddit thread collecting Patreon links for open-source maintainers seeking support and asked for Eghbal's thoughts on that approach. She replied that crowdfunding can work in some settings, usually when there is a specific deliverable to be created. A couple of big projects have managed to get funded that way. But this kind of funding requires a huge following; it can be hard for people who don't want to spend a lot of time marketing themselves. She hasn't seen a lot of example of people raising significant money this way. Crowdfunding is also better for one-time efforts than for ongoing maintenance. There are questions about what the money should be used for. In summary, she said, it won't work for all projects.

The video of this talk is available.

[Your editor would like to thank linux.conf.au and the Linux Foundation for assisting with his travel to the event.]