Working in Public: The Making and Maintenance of Open Source Software
Working in Public: The Making and Maintenance of Open Source Software
Nadia Eghbal
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.
Profile image of Tess Rinearson
Tess Rinearson@tessr · 1mo
This is a great term. I’m going to introduce it to my team.
Reply
Vote
. 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").
Profile image of Tess Rinearson
Tess Rinearson@tessr · 1mo
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.)
Reply
Vote
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.
Profile image of Tess Rinearson
Tess Rinearson@tessr · 1mo
Putting developers behind a one-way mirror, where the community can watch what they do, without weighing in themselves. Open, but not participatory
Reply
Vote
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.
Profile image of Tess Rinearson
Tess Rinearson@tessr · 1mo
Hence the burden of lots of casual contributions!
Reply
Vote
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 consume it. 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.
Profile image of Tess Rinearson
Tess Rinearson@tessr · 1mo
This might be the crux of this whole book.
Reply
Vote
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.
Profile image of Tess Rinearson
Tess Rinearson@tessr · 1mo
Extremely glad we’ve gotten past this.
Reply
Vote
In reply to Tess Rinearson
1mo
Tess Rinearson
@tessr · 1mo
Err, the quote, I mean.
Reply
In reply to David King
1mo
Tess Rinearson
@tessr · 1mo
Oh, interesting! I didn’t know I could edit the note. I’ll just make it blank.
Reply
Code, like any other type of content available online today, is trending toward modularity: a mille-feuille layer cake of little libraries instead of one big, jiggling Jell-O mold.
Profile image of Nadia Eldeib
Nadia Eldeib@Nadia · 1mo
This baking x coding analogy was a delightful (delicious?) surprise.
Reply
Vote
In reply to Tess Rinearson
1mo
David King
@dk · 1mo
Actually, I discussed with with other Highlighter team members just now and found that we no longer have the delete support we had before. The feat... more
Reply
In reply to David King
1mo
Tess Rinearson
@tessr · 1mo
In the iOS beta - totally possible I’m missing it, just couldn’t find it!
Reply
In reply to Tess Rinearson
1mo
David King
@dk · 1mo
Whoops... looks like we might have missed the delete function in a few interfaces. Are you accessing Highlighter from a web browser or from the iOS... more
Reply
In reply to Tess Rinearson
1mo
Tess Rinearson
@tessr · 1mo
How do I delete this mis-highlight 😱
Reply
In one sense, JavaScript's modularity makes the ecosystem more brittle. 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 easjer for developers to contain the problem and find a similar substitute
Profile image of Tess Rinearson
Tess Rinearson@tessr · 1mo
Reply
Vote
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
Profile image of Tess Rinearson
Tess Rinearson@tessr · 1mo
Reply
Vote
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.
Profile image of Tess Rinearson
Tess Rinearson@tessr · 1mo
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.
Reply
Vote
Code is not a product to be bought and sold so much as a living form of knowledge
Profile image of Tess Rinearson
Tess Rinearson@tessr · 1mo
Reply
Vote
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
Profile image of Tess Rinearson
Tess Rinearson@tessr · 1mo
Reply
Vote
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.
Profile image of Tess Rinearson
Tess Rinearson@tessr · 1mo
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
Reply
Vote
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
Profile image of Tess Rinearson
Tess Rinearson@tessr · 1mo
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.
Reply
Vote