Tag: open source

Roam Notes on “Working in Public” by Nadia Eghbal

  • Title:: Working in Public: The Making and Maintenance of Open Source Software
  • Author:: [[Nadia Eghbal]]
  • Recommended By:: [[Patrick Collison]]
  • Reading Status:: #complete
  • Review Status:: #[[first pass]]
  • URL:: link
  • Tags:: #books #[[Open Source]] #[[Open Collaboration]] #[[platforms]] #[[history of software]] #[[history of open source]] #[[online creators]] #[[online content creation]]
  • Source:: #kindle
  • Roam Notes URL:: link
  • Anki Tag:: working_in_public_eghbal
  • Anki Deck Link:: Get Anki Deck
  • Summary
    • [[Nadia Eghbal]] examines how [[Open Source] works today, how it has evolved to this state over time, and where it may be headed. Although the book is specifically about open source on the surface, much of it applies to all [[online content creation]] and [[online creators]]. Some of the main themes of the book include:
      • Creator attention is a [[common pool resource]] that must be protected through [[curation]] and filtering, rather than blindly encouraging more open participation.
      • Key [[open source contributions]] coming from a small number of very important creators / maintainers, rather than a large community.
      • Trends toward [[modularity]] of code and other online content.
      • Increased importance of [[curation]] for creators as the key problem to solve as they grow.
      • The extractive nature of many activities masked as "contributions", such as low-quality comments, questions, [[feature requests]], or [[pull requests]] that consume the limited [[attention]] of creators. #[[extractive contributions]] #[[casual contributors]]
        • ""Casual contributors are like tourists visiting New York City for a weekend. Just as we wouldn’t expect, or even want, tourists to participate in local governance decisions, we shouldn’t assume that casual contributors are part of a project’s contributor community simply because they are physically present." (Location 1569)"
        • ""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." (Location 2535)"
      • Trends toward following creators themselves rather than particular artifacts (e.g. code repositories) produced by creators.
    • Nadia also expounds a valuable nomenclature for talking about open source and online content. I particularly liked her categorization of open-source projects based on the ratio of contributors to users:
      • "4 main influencers that determine the ratio of a project’s users to contributors: (Location 809) #[[growing open source projects]]"
    • The book is filled with lots of interesting stories and quotes from open-source developers.
  • Introduction
    • People typically think [[open source software]] is built by large communities where many pitch in. In reality, they are typically developed by a small number of important [[maintainers]], who often are overwhelmed and stressed by having to deal with a large number of low-quality contributions. (Location 70) (Location 74) #Ankified
    • "One study found that, in a sample of 275 popular [[GitHub]] projects across various programming languages, nearly half of all contributors only contributed once. These [[contributors]] accounted for less than 2% of total commits, or overall contributions." (Location 85) #Ankified
    • This isn’t necessarily a problem, but many see it as an issue, as there is even a term called [[bus factor]] to measure project health: the number of developers that would need to get hit by a bus before the project is in trouble. (Location 106) #Ankified
    • "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." (e.g. [[npm]]). This contributes to the small number of maintainers per project. (Location 114)
    • "The role of a [[maintainer]] is evolving. Rather than coordinating with a group of [[developers]], these maintainers are defined by the need for [[curation]]: sifting through the noise of interactions, such as user questions, [[bug reports]], and [[feature requests]], which compete for their [[attention]]." (Location 129)
    • "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." The role of [[maintainer]] is evolving to [[curation]], sifting through many things that compete for their [[attention]], like [[bug reports]] or [[feature requests]] (Location 134) #Ankified
    • "In the late 1990s, open source was the poster child for a hopeful vision of widespread public collaboration, then dubbed “[[peer production]]."" (Location 180) #Ankified
  • Part 1: How People Make
    • 01. [[GitHub]] as a Platform
      • THE LIBERATION OF CODE
        • Before code hosting platforms, developers passed around code as a [[tarball]] (.tar file). Most open source code was published this way on a self-hosted website, and developers used [[mailing lists]] to collaborate. (Location 222) #Ankified
        • [[distributed version control]] (e.g. [[Git]]) was an important innovation for open source, since it make it technically possible for developers to work independently from one another, working on their own copy. [[centralized version control]] required developers to commit code back to the same server (Location 231) #Ankified
        • "[[Richard Stallman]] (also known as RMS) was the hacker who kicked off the [[free software movement]] at [[MIT]] in the [[1980s]]. [[Eric S. Raymond]] (also known as ESR), the programmer who helped rebrand [[free software]] to “[[Open Source]]” in the [[1990s]], is widely viewed as early open source’s unofficial anthropologist. And [[Linus Torvalds]] is the programmer who created both [[Linux]], the open source kernel that powers many of today’s operating systems, in 1991, and [[Git]], in 2005." (Location 260)
      • THE TRIUMPH OF CONVENIENCE (Location 325)
        • Another big innovation popularizing open source was code hosting, particularly [[GitHub]]. "[[GitHub]] wasn’t the first [[code-hosting platform]]. It was preceded by [[SourceForge]], founded in 1999. If GitHub is like Facebook, SourceForge was the MySpace of code-hosting platforms: the first significant product of its kind, and, though still alive today, mostly remembered as a blueprint." (Location 328) #Ankified
        • [[GitHub]] popularized [[permissive licensing]], increasing reach and distribution of open source code, whereas [[free software movement]] emphasized [[copyleft licensing]] (e.g. [[GNU General Public License (GPL)]]). The problem with copyleft licenses is they require any other code used with the GPL code to be GPL licensed as well (not commercial friendly): a private company would have to make all their code licensed under GPL if they used GPL licensed code. [[permissive licensing]] allows developers to do pretty much anything they want with the code (e.g. [[Berkeley Software Distribution (BSD)]], [[Massachusetts Institute of Technology (MIT) license]]) without changing the terms of their own projects. (Location 349) #Ankified
        • [[Massachusetts Institute of Technology (MIT) license]] is by the most popular license used by [[GitHub]] projects. "A 2015 company blog post claimed that 45% of open source projects use it." (Location 356) #Ankified
        • [[platforms]] like [[GitHub]] add value to [[creators]] by providing [[distribution]] (i.e. an audience). This is like a talent agency, except creators can take their audience elsewhere once they get it. So, platforms build convenient features for creators that encourage them to stay (Location 392) (Location 397) action=open&asin=B08BDGXVK9&location=404)) #Ankified
      • FROM HACKERS TO HUSKIES (Location 447)
        • Developers are increasingly known not for a specific project they work on (e.g. [[Linus Torvalds]] and [[Linux]]), but for who they are (Location 478).
        • This is particularly true in the [[JavaScript]] community.
      • THE GITHUB GENERATION (Location 548)
    • 02. The Structure of an Open Source Project
      • HOW CONTRIBUTIONS ARE MADE (Location 631) #[[contributing to open source]]
        • Changes to [[Open Source]] are not completely open to anyone. Developers submit a [patch] (aka [[pull request]] in [[GitHub]]) and these are reviewed and approved by prior trusted contributors. (Location 634)
        • "Some developers have permission to merge changes into the trunk (or master), which is the baseline version of the project. Having these permissions is often referred to as [[commit access]], which is like being able to edit a shared document." (Location 637) #Ankified
          • "The process by which a developer gains [[commit access]] varies widely between projects and is subject to preexisting social norms." (Location 656)
        • "Bigger projects often use a formal “request for comments” ([[RFC]]) process to allow communities to discuss these changes before they are merged." (Location 641)
        • Developer reputation as well as complexity of the change are some of the biggest factors determining whether a [[pull request]] is merged. (Location 673) (Location 680)
      • WHERE INTERACTIONS TAKE PLACE (Location 711) #[[open source work]]
        • An open source project isn’t just code. Typically [[repository]] refers to the code, while [[project]] refers to the broader tools and communication channels surrounding the code. (Location 714)
        • [[GitHub]] [[issues]] and [[pull request]] help it maintain a competitive advantage, since it’s not easy to migrate these between platforms. (Location 733)
      • HOW PROJECTS CHANGE OVER TIME (Location 754) #[[open source project evolution]]
        • Stages of open source project evolution (Location 757): #Ankified
          • Creation: Early stage, with few developers and closed development.
          • Evangelism: Project release, promotion, and distribution, transitioning to more open development.
          • Growth: Project more widely used, maintainers start doing more non-code than code work (e.g. triaging issues, reviewing pull requests).
            • Maintainers typically follow one of two paths here: i) If there’s few contributors they’ll start pull back to closed, focused development. ii) If the contributors are growing rapidly, they may follow a distributed model that passes off work more widely.
      • CLASSIFYING PROJECT TYPES (Location 804)
        • 4 main influencers that determine the ratio of a project’s users to contributors: (Location 809) #[[growing open source projects]]
          • Technical scope: Projects with more to do attract more contributors.
          • Support required: Including writing code (the stuff considered fun work by developers) and other supporting tasks like reviewing pull requests.
          • Ease of participation: The ease of contributing to the project.
          • User adoption: More users usually means more contributors.
        • The ratio of contributors to users lets us classify open source projects into four main categories (Location 862): #Ankified
          • [[federations (open source)]]: Many contributors, many users (e.g. [[Rust]], [[Node.js]], [[Linux]])
          • [[clubs (open source)]]: Many contributors, few users (many users are contributors).
          • [[toys (open source)]]: Few contributors, few users (side project / weekend project).
          • [[stadiums (open source)]]: Few contributors, many users (e.g. [[webpack]], [[Babel]]).
    • 03. Roles, Incentives, and Relationships
      • Open source projects are often best described as a [[commons]]: a resource that is owned, used, and managed by a community. (Location 1041)#Ankified
      • A THEORY OF THE COMMONS (Location 1044) #commons
        • Economist [[Elinor Ostrom]] studied conditions leading to well-managed commons that avoid the [[tragedy of the commons]]. [[Ostrom commons design principles]]:
          • Membership boundaries are clearly defined.
          • The rules that govern the commons should match the actual conditions.
          • Those who are affected by these rules can participate in modifying them.
          • Those who monitor the rules are either community members or are accountable to the community, rather than outsiders.
          • Those who violate the rules are subject to graduated sanctions, which vary depending on the seriousness and context of the offense. #punishment
          • Conflicts should be resolved within the community, using low-cost methods. #[[conflict resolution]]
          • External authorities recognize the right of community members to devise their own [[institutions]].
          • If the commons is part of a larger system, its governing rules are organized into multiple “nested” layers of [[authority]]. (Location 1044)
      • WHY WE PARTICIPATE IN THE COMMONS (Location 1074) #commons
        • [[Yochai Benkler]] expanded upon [[Elinor Ostrom]]’s model by applying her findings to the online world. He terms this [[communal structure commons-based peer production]] (CBPP) in a 2002 essay called “Coase’s Penguin, Or, Linux and ‘The Nature of the Firm.’” (Location 1075) #[[To Read]]
        • His work focuses on why people participate in [[commons]]. Conditions for it to work include: [[intrinsic motivation]], modular and granular tasks, and low [[coordination]] costs. (Location 1082) (Location 1103). In open source, the main coordination costs are [[reviewing code]] and merging [[pull requests]] (Location 1122). #modularity
        • Projects that involve a [[commons]] ([[federations (open source)]] and [[clubs (open source)]]) are focused on resolving coordination issues, while projects without a commons ([[stadiums (open source)]]), focus on curation due to the scarcity of attention of the creator. (Location 1142)
      • HOW PLATFORMS BROKE APART THE COMMONS (Location 1156) #commons
        • Communities need to protect themselves from potentially damaging actions of newcomers, who can destabilize the community’s pre-existing [[social norms]]. (Location 1220)
        • It’s difficult for maintainers to defer decisions to the community, given the lack of clear membership boundaries. "Countries have citizenships and constituencies, but open source projects are open to anyone." (Location 1235) #[[Ostrom commons design principles]]
      • THE ROLE OF A MAINTAINER (Location 1346) #maintainers
        • "although maintainers are few in number, their impact on an open source project is far-reaching, because they’re the bottleneck to everyone else’s contributions." (Location 1366)
        • Ideally, a project will attract [[creators]] and [[curators]] to serve as co-maintainers (developers tend to be more excited about creating, so curators are particularly valuable) (Location 1421)
        • Long-term maintenance does not typically sharpen your developer skills. After a while, maintainers typically take one of the following paths:
          • They might enjoy cultivating non-development skills like [[project management]] or [[leadership]].
          • They figure out how to distribute the work to contributors and users or other methods to reduce the overall time they spend on undesirable tasks.
          • They step down, find a replacement, or disappear. (Location 1445)
        • Like a CEO, maintainers tend to be locked into the project – leaving would have serious consequences for the health of the project. (Location 1462)
        • Another interesting property of project maintainers is that publication of the project is not the end of the work, in contrast to publishing books. Once published, maintainers are expected to maintain as long as people use it. (Location 1487)
      • ACTIVE AND CASUAL CONTRIBUTORS (Location 1495) #contributors
        • Typical active contributor motivations are [[community]], [[reputation]], and [[learning]]. (Location 1537)
        • [[casual contributors]] (aka “drive-by contributors”) have a transactional relationship with the project. They mainly just want to see their contributions merged. "self oriented rather than community oriented" (Location 1547) (Location 1566)
        • "Casual contributors are like tourists visiting New York City for a weekend. Just as we wouldn’t expect, or even want, tourists to participate in local governance decisions, we shouldn’t assume that casual contributors are part of a project’s contributor community simply because they are physically present." (Location 1569)
        • [[GitHub]] has encouraged growth of casual contributors by lowering the friction to contribute and increasing the number of users of open source projects (Location 1597)
      • ACTIVE AND PASSIVE USERS (Location 1616) #users
        • Active users are like active contributors, but they tend to operate independently from the project’s contributors, and possibly haven’t interacted with the project’s repository at all. (Location 1656)
      • ASSESSING THE HEALTH OF A PROJECT (Location 1673) #[[open source project health]]
        • 3 success metrics: (Location 1677)
          • POPULAR: # people using the project. (Location 1678)
          • DEPENDED UPON: how much other software actively uses the project (Location 1679)
          • ACTIVE: the project is actively developed (Location 1681)
            • Commits, issues, pull requests (# open issues and pull requests, average time to first response, average time to close an issue or pull request)
            • Some projects don’t require much maintenance. In these cases, look at activity off [[GitHub]] (e.g. Stack Overflow) (Location 1740)
        • [[bus factor]]: is the number of contributors that would need to get hit by a bus before the project is compromised. (Location 1697)
        • Contributor count can be misleading, especially for [[stadiums (open source)]], since this metric assumes contributors are fungible (i.e. interchangeable). (Location 1709)
  • Part 2: How People Maintain
    • 04: The Work Required by Software
      • CODE AS ARTIFACT, CODE AS ORGANISM (Location 1801)
        • Software evolves over time and requires continuous maintenance. [[greenfield projects]], where developers get to write code from scratch, are actually rare (and coveted) – developers spend more time tending to code others wrote. (Location 1808)
        • "[[Fergus Henderson]], a software engineer at [[Google]], states that “most software at Google gets rewritten every few years.” Software changes over time as its environment—the other technology around it—changes. Henderson also points out that regularly rewriting software is inherently beneficial. It helps cut away unnecessary complexity that has accumulated over time, as well as transfer knowledge and a sense of ownership to newer team members." (Location 1816) #[[rewriting software]]
        • "The cost of maintenance, coupled with a lack of intrinsic motivation to maintain, is why large open source projects tend to become modular as they grow." (Location 1820) #modularity
        • [[forking]] is an option to exit a project, but you have to consider dependencies and upkeep required. Most projects in reality are unforkable due to these other factors. The project is more than just the code. (Location 1913)
      • THE HIDDEN COSTS OF SOFTWARE (Location 1926) #[[software costs]]
        • Three major types of software costs: [[creation]], [[distribution]], and [[maintenance]]. (Location 1927)
          • Creation is intrinsically motivated, distribution powered by platforms such as [[GitHub]] and cheap. Maintenance is a bit of a mystery, and it’s a big cost: "A 2018 Stripe study of software developers suggested that developers spend 42% of their time maintaining code." (Location 2074)
        • Two main kinds of maintenance costs: [[marginal maintenance costs]] and [[temporal maintenance costs]]. Software incurs ongoing maintenance costs, both marginal (costs that are a function of its users) and temporal (entropy, or costs associated with decay over time). (Location 1931)
          • [[marginal maintenance costs]]
            • Software has low [[marginal costs]] but, contrary to popular belief, they are not 0. If you think of code as static, then yes it’s 0 marginal cost, but when maintenance is involved marginal costs add up. Software is not quite completely [[non-rivalrous]] – if 10 people use software compared to 10,000 the developers will feel the difference. (Location 1941)
            • Some of the costs that increase with users include physical inrastructure (Location 1977), developer tools (Location 2009), user support (Location 2011), and community moderation (Location 2050).
          • [[temporal maintenance costs]] (Location 2069)
            • These costs are a function of [[entropy]]: the inevitable decay of systems over time.
            • [[technical debt]] (Location 2079): Choosing easier, faster options today that cost time and money to address later on.
            • [[test infrastructure]] (Location 2092): Tests are added over time as the project expands, with increased opportunity for slow or flaky tests. "One maintainer of a large open source project told me that running his CI service took an hour and a half per pull request, yet he was expected to review and merge forty to fifty pull requests per day."
            • [[dependency management]] (Location 2110)
            • Adapting to user needs (Location 2168)
      • MEASURING THE VALUE OF CODE (Location 2219)
        • DEPENDENCIES (Location 2323) #[[dependencies]]
          • Dependencies are an indicator of the value of software, because it means others are using it.
          • That being said, dependency doesn’t tell the whole story of value, since it might still be really easy to replace (i.e. high [[substitutability]]).
          • Open source code tends to be highly [[elastic]] (i.e. consumers sensitive to price changes, willing to switch to competitors).
        • REPUTATION (Location 2380)
    • 05: Managing the Costs of Production
      • If open source software is a [[public good]], should it be provided by the government? (Location 2475). Government is ill-suited to do this given that open source code is transnational (governments are beholden to national interests). Also, software moves too fast – the law can’t keep up.
      • A good example of government failure in this area is open source [[cryptography]]. In the [[1970s]] and [[1980s]], developers used [[Data Encryption Standard (DES)]], but the [[National Security Agency (NSA)]] changed it to make it weaker so they could break it. Open source developers eventually created [[Pretty Good Privacy (PGP)]], but this cryptography was considered a form of munitions in the United States because it overlapped with national security – developers working on open source cryptography had to become licensed arms dealers if they wanted to "[[export]]" (i.e. distribute) their code! Eventually, the US dropped these export controls. (Location 2484)
        • Hilarious workaround: the US State Department ruled code on a floppy disk couldn’t be exported, but books containing code was allowed (protected under [[freedom of speech]]). So the PGP developers published a book called PGP Source Code and Internals.
      • This is a big reason why [[Elinor Ostrom]]’s work is gaining popularity – she provides a framework for understanding how people can self-manage [[non-excludable]] resources without resorting to government. (Location 2503)
      • "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." (Location 2535)
      • PRODUCTION AS A ONE-WAY MIRROR (Location 2548)
        • Managing open source code requires separating its [[production]] from [[consumption]]. (Location 2551)
        • From a consumption perspective, static open source code is a [[public good]]. Its value can be measured by its number of [[dependencies]] and [[substitutability]].
        • From a production perspective, open-source code is more like a [[commons]] (i.e. [[non-excludable]] and [[rivalrous]]), where maintainer [[attention]] is the rivalrous resource. (Location 2572) "When developers make contributions, they appropriate this attention from the commons." (Location 2584)
        • "To reduce the over-appropriation of attention in open source software, we can think of its production as a one-way mirror, where we design for the parasocial, or one-sided, relationships that are endemic to [[stadiums (open source)]], rather than for the interpersonal relationships that are associated with [[clubs (open source)]]." (Location 2589)
        • In this model, users can consume the code, but would have limited access to things that consume maintainer time, like pull requests or mail lists. Maintainers should avoid [[extractive contributions]], i.e. contributions where the marginal cost of reviewing and merging outweighs the marginal benefit to the project’s producers (e.g. comments, questions, feature requests). (Location 2632) Fear of appearing unsympathetic or unwelcoming often keeps maintainers reviewing extractive contributions. (Location 2681) #Ankified
        • Non-extractive casual contributions are often modular, granular, and require little input from maintainers. (Location 2666)
      • MANAGING PRODUCER ATTENTION (Location 2700) #maintainers #attention
        • Typical patterns maintainers use to manage their [[attention]]: (Location 2700)
          • Reduce up-front costs
          • Make themselves less available
          • Distribute costs onto users
          • Increase total attention available
        • REDUCING UP-FRONT COSTS (Location 2726)
          • [[continuous integration]] and [[automated tests]] are valuable for open source, as it makes maintainers more confident in merging code from people they don’t know (Location 2774) (Location 2781)
          • [[bots]] (Location 2786)
          • [[Code style guides]] and [[linters]] (Location 2799)
          • Templates and [[checklists]] for [[issues]] and [[pull requests]]. "Among the top hundred projects on GitHub by issue volume in 2018, 93% of projects used issue templates." (Location 2806)
        • LIMITING AVAILABLE ATTENTION: THE N=1 APPROACH (Location 2824)
          • Some developers make themselves less available. One technique coined by [[Philip Guo]] is the "n=1 approach", where you only have 1 developer, since going from 1 to 2 developers is the biggest jump. Don’t accept pull requests, although they may look at them for ideas – they serve more as comments or suggestions. This may inspire the developer, without imposing the technical and social costs of merging others’ code. (Location 2845) #Ankified
          • Some use a tiered approach, devoting more personal attention as a person makes more contributions (e.g. [[Mike McQuaid]] – Homebrew’s lead maintainer). (Location 2846)
        • DISTRIBUTING COSTS: USER-TO-USER SYSTEMS (Location 2860)
        • MEETING DEMAND: INCREASE AVAILABLE ATTENTION (Location 2911)
          • Bring on more active contributors or find ways they can personally spend more attention on the project (Location 2921)
      • THE ROLE OF MONEY IN OPEN SOURCE (Location 2961)
        • Maintainers can make their attention [[excludable]] by charging for access (e.g. paid support, [[patronage]], [[bounties]]) (meaning, paid rewards for certain tasks or contributions) (Location 2991)
        • WHO FUNDS OPEN SOURCE DEVELOPERS, AND WHY (Location 2995)
          • Two types of funders of open source: institutions (usually companies) and individuals (usually developers who are users). (Location 2996)
          • Companies tend to fund due to their desire for [code quality] – they pay for support or [[service level agreements (SLAs)]]. Essentially, they pay for a direct line to a project’s maintainers (Location 3012). Some maintainers host office hours for high-paying supporters, while others may work on retainer to provide corporate support. This can sometimes lead to a full-time hire. These kind of arrangements aren’t usually publicized (Location 3030)
          • Companies may pay for brand association (Location 3044).
          • People often use the words "should" or "ought" when talking about individuals funding open source. This book focuses on why an individual might be happy to drop cash on a project (Location 3112).
          • Individual developers are less likely to pay for open source code and instead sponsor people behind the code, based on reputation (Location 3113). As content creators, the typical reward is reputation gains, which they can convert into [[attention]] (i.e. an audience), which they can then convert into [[money]] (Location 3115).
          • [[patronage]] is increasingly popular, and not to be confused with donations. It’s more of a subscription – people pay to be closely connected with the creator’s work (Location 3118). We should think of open source developers as content creators, and content creators can make money in ways other than being hired be someone: "Can we imagine telling Tfue, who rose to fame by livestreaming himself playing Fortnite Battle Royale on Twitch, that the most he could hope for was to get hired by ESPN" (Location 3146)
        • WHERE THE MONEY GOES (Location 3214)
          • Compensating casual contributors makes no sense, because it’s like paying people to leave comments on a creator’s work, there’s no shortage of casual contributions, and casual contributors are already motivated to participate. (Location 3259) "If anything, it’s casual contributors who should be paying for access to maintainers, not the other way around" (Location 3266)
          • [[bounties]] work well for well-scoped, finite tasks that are specialized or difficult to attract talent for (e.g. design work, database migrations, security bugs) (Location 3279)
          • Funding individuals is an option which avoids centralized governance issues that come from funding projects. To fund projects, the developers need a legal entity to accept the funds, and define governance processes to manage who gets paid and how much. As projects get smaller and smaller, funding people becomes even more attractive (Location 3309)
          • Funding individuals is more difficult for organizations – they prefer funding projects for the benefits of code security and stability, influence, attracting talent to hire. Funding individuals is more like hiring to them – hard to pull off in terms of execution and making the case internally (Location 3349).
  • CONCLUSION
    • The value of [[platforms]] comes mostly in the [[social graph]] you build on it, not the content itself. "Our relationship to content matters less than our relationships to the people who make it. As a result, we’re starting to treat content not as a private economic good but as the externalization of our social infrastructure." (Location 3402)
    • "I’ll spend the final pages zooming out in order to explore how what we’ve learned can be applied not just to open source developers but other [[online creators]]. I’ll focus on two areas in particular: the problem of [[managing over-participation]] and the problem of [[making money]]." (Location 3441)
    • MANAGING OVER-PARTICIPATION (Location 3445)
      • Similarly to what was described with open source maintainers, growing audience engagement extracts attention from the creators. It’s essential to find a way to manage this demand, especially when it is extractive (e.g. comments, direct messages). (Location 3447)
      • Options for creators at these later stages include: hiding / muting interactions (Location 3517) and encouraging the role of curator (Location 3524).
    • MAKING MONEY (Location 3557) #[[making money]]
      • [[paywalls]] are not to monetize content. They monetize community by allowing the audience to get closer to the creator, meet like-minded people, or get away from extractive contributors. (Location 3571) "A paywall is more like the ticket kiosk at a theme park than a price tag on a car." (Location 3573) See "Something Awful" – a forum popular in the 2000s that anyone could read but only users paying an "activation fee" could comment. (Location 3575) This had the nice side-effect of keeping out idiots.
      • Putting all content behind [[paywalls]] is unlikely to work well, and neither are [[micropayments]] to unlock individual articles or other content. "Micropayments make the transaction about content, rather than about creators, but because there is so much freely available, highly substitutable content they create decision fatigue for consumers" (Location 3582).

For access to my shared Anki deck and Roam Research notes knowledge base as well as regular updates on tips and ideas about spaced repetition and improving your learning productivity, join “Download Mark’s Brain”.