Working in Public: The Making and Maintenance of Open Source Software
Working in Public takes an inside look at modern open source software development, its evolution over the last two decades, and its ramifications for an internet reorienting itself around individual creators. Nadia Eghbal, who interviewed hundreds of developers while working to improve their experience at GitHub, argues that modern open source offers us a model through which to understand the challenges faced by online creators.
Extractive contributions are those where the marginal cost of reviewing and merging that contribution is greater than the marginal benefit to the project's producers. In the case of a code contribution, it might be a pull request that's too complex or unwieldy to review, given the potential upside. Or it might be an enthusiastic user who wants to organize a community event that requires more resources from the project's developers than it's worth. The most common forms of extractive contributions are comments, questions, and feature requests.
. In open source, we might imagine that anybody is welcome to read community mailing lists, issues, pull requests, and chat logs, but further participation requires the approval of existing developers (or, in some cases, paying for "write access").
Write access for the CODE of most projects is already limited to maintainers. It’s interesting to imagine what life would be like if write access to the rest of the project (issues, forums, etc) were limited as well.
(This makes some sense—the code is viewed the most sacred part of the project. But it looks like an argument can be made that it’s actually maintainer attention that is the most precious aspect of any project.)
When production is a one-way mirror, creators are shielded from distraction, building things in public view but without the expectation that they engage with unhelpful contributors. We can think of this as a form of read-only access, not unlike the permissions system of open source projects themselves.
Content can be made available for anyone to read and consume, but that doesn't mean it needs to be open for anyone to participate. Much of the fatigue that open source developers experience comes not from making their code public but from expectations around making their code participatory.
When software is in static state, what if there is no free-rider problem? When code is non-rivalrous, it only has first-copy costs, which the creator is intrinsically motivated to provide-so the problem doesn't seem to lie in how many people
For this reason, I'm skeptical of attempts to charge for access to information, whether it's newspaper articles or open source software. If some people like to make things of their own accord, and most content is a highly substitutable good, it's unlikely that online content will ever be underproduced. Someone out there will always want to make something for the rest of us. Why prevent anyone from consuming that content, given the enormous social benefits of making it freely accessible?
Instead, I'd flip the question to ask: What if, rather than being underproduced, software is actually overproduced? The problem with the Christmas lights isn't that anyone can drive by and view them. A problem only surfaces if we think our neighbor owes us anything; if we cross the invisible boundary and knock on his door, making demands and requesting changes.
But cryptography, because it overlapped with national security, was considered a form of munitions in the United States. If cryptographic code crossed the borders to another country, it was treated as a munitions export.
Early open source cryptographers, like those writing OpenSSL, had to become licensed arms dealers to be able to write and "export" (i.e., distribute) their code.
tle. The surface area of potential problems is bigger, since there are more dependencies, each one managed by a different developer. On the other hand, a modular approach is theoretically more resilient: even if one package disappears, since it is smaller in scope it should be easier for developers to contain the problem and find a similar substitute
Forking is a useful exit strategy when we ignore the dependencies and upkeep required by the project in question. In reality, a widely used project makes itself unforkable because it's become more than just the code.
Forking is such a funny threat. I think forks can go in one of three ways, and they’re all ultimately fine for communities: the fork flops, the fork supersedes the original, or there’s a true fork with divergent projects meeting the needs of broader sets of users.
A study by Suvodeep Majumder et al. found that 85% of the open source projects studied had "heroes," meaning developers who participate in at least 80% of discussions related to a commit, and that these developers' commits contained significantly fewer bugs than others
Dominic Tarr is a developer who's created hundreds of popular npm modules, many of which are widely downloaded and relied upon by millions of people around the world. In November 2018, he gave commit rights to a stranger who claimed they wanted to help maintain one of these modules, event-stream, which Tarr had long moved on from. Instead, the stranger proceeded to insert malicious code into the module, in an attempt to steal money from users of an application that depended on the library.
another parable on the benefits and dangers of modularity: if you introduce modules, and then hand off responsibility for those modules, that can create an opportunity for someone to introduce malicious code
If a project is lucky, it'll attract both creators and curators, who can serve complementary roles as co-maintainers. Developers tend to be more excited to create than maintain, so finding someone who enjoys the latter can be a real boon. One maintainer explained to me that the project's author, who's still actively involved, is an "inventor" who loves creating but has little interest in maintaining. By contrast, the person I spoke to loves organizing, curating, and rigorously applying process. They work well together, although sometimes he wonders what will happen when the author eventually steps down. He worries he won't be able to fill the shoes of an inventor. Likewise, if he were to step away from the project, finding someone with his level of patience and attention to detail would be difficult for his co-maintainer
This paragraph really speaks to me - I am the manager of the maintaining team for Tendermint Core, and we work mostly obliquely with its original author. Different strengths (and different personalities!) were needed at different points in the project’s lifecycle.