Working in Public: The Making and Maintenance of Open Source Software

by Nadia Asparouhova

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.

There’s a similar story playing out in the world of open source software: a term that’s nearly synonymous with public collaboration, but whose developers—who write and publish code that anybody can use—often report feeling overwhelmed by the volume of inbound requests.

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.

The expectation that open source should be a collaborative effort leaves solo maintainers scratching their heads, wondering if they’re doing something wrong when nobody shows up to meaningfully pitch in. But what if we start from the premise that things are as they should be? I decided to revisit the diagnosis, treating these symptoms as a starting point, instead of applying the only prescription—more participation—that we had.

Why has this been the assumption?

The problem facing maintainers today is not how to get more contributors but how to manage a high volume of frequent, low-touch interactions. These developers aren’t building communities; they’re directing air traffic.

GitHub’s open source developers have more in common with solo creators on Twitter, Instagram, YouTube, or Twitch, all of whom must find ways to manage their interactions with a broad and fast-growing audience.

Although there is no shortage of memorable hacker personalities, the free and early open source ethos is also defined by a startling lack of interest in its people.

Freedom of code extends to freedom from the people who make it, too.

The fact that today’s developers don’t just use, but actively prefer, GitHub suggests a different set of values from previous generations. The simple act of using GitHub already separates these developers from the most dogmatic free software advocates, who refuse to use the platform whatsoever.

Unlike those who stress the freedom of code over all else, the JavaScript community exudes the opposite appeal: when code is small, it’s the people who stand out.

JavaScript’s most recognizable developers are known for the talks they give, the videos they record, the tweets and blog posts they write.

They’re known for who they are, rather than which projects they’re involved in.

The cult of personality thrives in JavaScript, even if its most prominent developers are reluctant to acknowledge it, perhaps because this attitude clashes with the professed ideal of open source as “community-built.” Compared to early renowned hackers like Torvalds, Raymond, and Stallman, many of today’s JavaScript developers are unusually humble.

Each of these developers commands a large audience of people who follow them personally; they have the attention of thousands of developers, and they choose to use that influence to demonstrate kindness and respect.

The locus of open source culture has shifted from celebrating heavy-handed authoritarianism to seeking out thoughtfulness and stewardship.

Open source maintainers have become the de facto teachers for developers who are learning how to contribute. In the past, this made sense when new developers were trying to join a project’s community. Today, rehashing the basics to a revolving door of strangers can be fatiguing: death by a thousand paper cuts.

“a perverse effect where, the more successful you are, the more you get ‘punished’ with GitHub notifications.”