_Working in Public_ notes

p. 8: "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. . . . In the absence of additional reputational or financial benefits, maintaining code for general public use quickly becomes an unpaid job you can't quit."

p. 9: 'It's commonly thought that open source software is built by communities, which means that anyone can pitch in, thus distributing the burden of work. . . . 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.'

P. 12: "it's not the excessive consumption of code but the excessive participation from users vying for a maintainer's attention that has made the work untenable for maintainers today."

P. 14: "As a developer, if you use the command-line tool cURL, you're using code written by Daniel Stenberg. If you use the command-line interface bash, you're using code maintained by Chet Ramey. If you use npm, you're using packages written by Sindre Sorhus and Substack. If you use Python's packaging tools, you're using code maintained by Donald Stufft. Like any other creator, these developers create work that is intertwined with, and influenced by, their users, but it's not collaborative in the way that we typically think of online communities." Making creators, like coffee growers, more visible without stressing them more should be the goal of future efforts.

P. 14: "Instead of facing one another, as pop culture critic Mark Fisher allegedly once put it, a creator's audience now faces the stage." Maintainers are more like musicians than community leaders, and Github is their label. "Like other creators, open source developers make things for general public consumption. They, too, need to deal with crowded inboxes, manage their limited attention, and lean upon enthusiastic fans for support. Like other creators, open source developers rely heavily upon platforms to distribute their work. As closed economies, these platforms also bear the responsibility of helping creators grow their reputations and capture the value of their efforts."

P. 15: "But over the last twenty years, open source inexplicably skewed from a collaborative to a solo endeavor. And while more people use open source code than ever before, its developers failed to capture the economic value they created: a paradox that makes them just as interesting to reexamine today."

P. 32: 'Ben Thompson, who writes about business and technology on his blog, Stratechery, goes so far as to suggest that delivering this kind of value is, itself, the definition of a platform, as opposed to aggregators. Platforms deliver value to third parties that build on top of them, whereas aggregators are pure intermediaries. Thompson references a quote attributed to Bill Gates, who defines a platform as "when the economic value of everybody that uses it exceeds the value of the company that creates it."36 Based on this definition, Thompson suggests that Facebook is not actually a platform but an aggregator, because there is "no reason for Facebook, beyond goodwill, to do anything for [media] publishers."'

P. 33: 'Steve Klabnik, a developer known for his work in Rust and Ruby, two popular programming language communities, points to how outdated vocabulary limits our ability to talk about how open source is produced: Why is it a problem that the concepts of free software and open source are intrinsically tied to licenses? It's that the aims and goals of both of these movements are about distribution and therefore consumption, but what people care about most today is about the production of software. Software licences regulate distribution, but cannot regulate production. . . . This is also the main challenge of whatever comes after open source.'
Steve Klabnik, "What Comes after 'Open Source,'" Steve Klabnik (blog), April 2, 2019, https://words.steveklabnik.com/what-comes-after-open-source.

P. 35: "On GitHub, JavaScript is more than twice as popular as Python, the second-place contender."

P. 36: "JavaScript developers embrace the "amateurization of open source," despite garnering occasional eye rolls from their predecessors." Going opposite direction from kernel, which is monorepo and relies on mailing list. Neither cathedral nor bazaar? "each project tends to be smaller and more disposable, like LEGO blocks that fit together instead of a castle carved from stone."

P. 44: 'The term "open source" refers only to how code is distributed and consumed. It says nothing about how code is produced. "Open source" projects have nothing more in common with one another than "companies" do.'