Working in Public: The Making and Maintenance of Open Source Software
2020 Nadia Eghbal
All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or any other information storage and retrieval system, without prior permission in writing from the publisher.
Published in the United States of America by Stripe Press / Stripe Matter Inc.
Stripe Press
Ideas for progress
San Francisco, California
press.stripe.com
ISBN: 978-0-578-67586-2
First Edition
Second printing
Creative Director: Tyler Thompson
Typesetting & Design: Alice Chau
Composed in Favorit & Favorit Mono from ABC Dinamo Foundry
ebook design by Bright Wing Media
CONTENTS
Landmarks
Until recently, information was good, and more information was better. If the free exchange of ideas formed the basis of a flourishing society, then we had a moral imperative to connect more people to one another.
The spirit of openness lasted more than years. We championed the value of literacy and education. We built roads, bridges, and highways that brought together previously isolated communities. We careened toward the new millennium, flushed with the global triumph of Western liberal democracy.
And so, in the late twentieth century, when murmurs of the internet began to hum to an audible roar, they carried with them all the qualities of our harmonious, never-gonna-give-you-up infatuation with the unconstrained spread of knowledge. Tim Berners-Lee, the inventor of the World Wide Web, envisioned a pool of information . . . which could grow and evolve in his original proposal to CERN, the European particle physics laboratory that incubated his project. For this to be possible, the method of storage must not place its own restraints on the information, he wrote. With his proposal as a blueprint, technologists built a Library of Alexandria bigger than we could have ever conceived in the physical realm, inextricably linking people and their ideas all around the world.
Then we hit a snag. Suddenly, there was too much information. Too many notifications made us want to check them less. Too many social interactions made us want to post online less frequently. Too many emails made us not want to answer. We were, effectively, DDoSing one another: the term for a distributed denial-of-service attack, in which malicious actors overwhelm their target by flooding it with traffic, leaving the victim incapacitated. Our online public lives became too much to handle, causing many of us to shrink back into our private spheres.
Theres a similar story playing out in the world of open source software: a term thats nearly synonymous with public collaboration, but whose developerswho write and publish code that anybody can useoften report feeling overwhelmed by the volume of inbound requests.
After interviewing hundreds of open source developers and researching their projects, I summarized this problem in a 2016 report for the Ford Foundation, titled Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure. Then I set out to try to address it.
Much of my stress-testing happened from 2016 to 2018, while I was working to improve the open source developer experience at GitHub, a company that offers hosting for open source projects. As the platform where most open source software is built, GitHub was the perfect place to learn. I met even more developers and worked with more projects, and I had to think pragmatically about solutions. These were the moments, often humbling, when rhetoric squared off with reality.
That many open source developers suffer from a lack of support is indisputable. My inbox was flooded with emails from people involved in open source, eager to share their stories. The hard part was identifying what they actually needed.
Initially, I focused my explorations on a lack of funding. Many open source developers are not directly paid for their work, despite generating trillions of dollars in economic value. In the absence of additional reputational or financial benefits, maintaining code for general public use quickly becomes an unpaid job you cant quit.
But as I tracked developers stories over the years, I noticed that money is only part of the problem. Some developers deftly handle demand from their users without any financial compensation. And even paid open source developers seem to go through the same strange behavioral cycle, in a way that seems less common among those who write proprietary, or private, code for their employers.
The cycle looks something like this: Open source developers write and publish their code in public. They enjoy months, maybe years, in the spotlight. But, eventually, popularity offers diminishing returns. If the value of maintaining code fails to outpace the rewards, many of these developers quietly retreat to the shadows.
A developer whos employed at a private company works primarily with their colleagues. A developer who writes code in public must work with thousands of strangers: literally, anybody with an internet connection who cares to comment on their code. The lack of financial reward is a symptom, perhaps, of misaligned incentives, but this inevitable cycle of churn seems to hint at something deeper.
The default hypothesis today is that, faced with growing demand, an open source maintainerthe term used to refer to the primary developer, or developers, of a software projectneeds to find more contributors. Its commonly thought that open source software is built by communities, which means that anyone can pitch in, thus distributing the burden of work. On the surface, this appears to be the right solution, especially because it seems so attainable. If a lone maintainer feels exhausted by their volume of work, they should just bring more developers on board.
There are countless initiatives today aimed at helping more developers contribute to open source projects. These efforts are widely championed as good for open source, and they are frequently accomplished by tapping into a public sense of goodwill.
However, in speaking to maintainers privately, I learned that these initiatives frequently cause them to seize with anxiety, because such initiatives often attract low-quality contributions. This creates more work for maintainersall contributions, after all, must be reviewed before they are accepted. Maintainers frequently lack infrastructure to bring these contributors into a contributor community; in many cases, there is no community behind the project at all, only individual efforts.
In my conversations with maintainers, I heard them express a genuine conflict between wanting to encourage newcomers to participate in open source and feeling unable to personally take on that work. Maintainers simply dont have the energy to onboard every person who shows passing interest. Many told me they were frustrated by prior attempts to cater to a revolving door of contributorssometimes hundreds of themwho didnt stick around. Maintainers recounted how those whod expressed interest sometimes disappeared before theyd even submitted their first contribution.
