Working in Public  ## Metadata - Author: [[Nadia Eghbal]] | [[3. Resources/Authors/Nadia Eghbal|Nadia Eghbal]] - Full Title: Working in Public - Category: #books - Kindle: [Open in Kindle](https://www.amazon.com/dp/B08BDGXVK9) - Document Tags: [[Open Source]] ## Document Notes ## Highlights - 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. ([Location 63](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=63)) - faced with growing demand, an open source “maintainer”—the term used to refer to the primary developer, or developers, of a software project—needs to find more contributors. ([Location 68](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=68)) - However, in speaking to maintainers privately, I learned that these initiatives frequently cause them to seize with anxiety, because such initiatives often attract low-quality contributions. ([Location 74](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=74)) - a genuine conflict between wanting to encourage newcomers to participate in open source and feeling unable to personally take on that work. ([Location 78](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=78)) - Maintainers simply don’t have the energy to onboard every person who shows passing interest. Many told me they were frustrated by prior attempts to cater to a revolving door of contributors—sometimes hundreds of them—who didn’t stick around. ([Location 79](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=79)) - One study found that in more than 85% of the open source projects the researchers examined on GitHub, less than 5% of developers were responsible for over 95% of code and social interactions. ([Location 102](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=102)) - We assume that open source projects need to grow strong contributor communities in order to survive. ([Location 106](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=106)) - the bus factor, where project health is measured by the number of developers that would need to get hit by a bus before the project is in trouble. ([Location 107](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=107)) - the lack of contributors today reflects an adaptation to changing environmental circumstances, wherein the relationship between a maintainer, contributors, and users is lighter, more transactional. ([Location 124](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=124)) - Casual contributors are often aware that they have little context for what is going on behind the scenes of the project. But more importantly, they do not want to spend time familiarizing themselves with a project’s goals, roadmap, and contribution process. These developers primarily see themselves as users of the project; they do not think of themselves as part of a “contributor community.” ([Location 126](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=126)) - 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. ([Location 134](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=134)) - hackers believe in sharing, openness, and decentralization, which he calls the “hacker ethic.” ([Location 252](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=252)) - hackers care about improving the world, but don’t believe in following the rules to get there. ([Location 254](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=254)) - Hackers are characterized by bravado, showmanship, mischievousness, and a deep mistrust of authority. ([Location 254](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=254)) - “The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary,” ([Location 270](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=270)) - Torvalds is still the only person who’s allowed to merge those contributions into the main project. ([Location 290](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=290)) - Note: Is Torvald’s a better or worse BDFL than Mullenweg? He’s forthright in his speech, but is that a good thing? - The locus of open source culture has shifted from celebrating heavy-handed authoritarianism to seeking out thoughtfulness and stewardship. ([Location 515](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=515)) - Open source is complicated because it contains a messy mix of both technical and social norms, most of which play out in public. It is documented extensively (nearly every decision is written down somewhere) but not clearly (you have to dig through years of mailing list archives to find what you need). Its treasures are hidden amidst a tangle of brambles and thorns. ([Location 600](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=600)) - Social norms are passed down through trial and error, which means that getting something wrong runs the risk of embarrassment and mockery in front of one’s peers. Developers don’t contribute to open source for lack of technical ability, but rather due to fear of committing a faux pas. ([Location 603](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=603)) - While this is theoretically true, in practice open source is not blindly open to every person who wants to change it. ([Location 632](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=632)) - Bigger projects often use a formal “request for comments” (RFC) process to allow communities to discuss these changes before they are merged. ([Location 641](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=641)) - Debian, an operating system based on Linux, requires that developers follow an extensive onboarding process in which they are expected to read a manual, find a mentor, and meet a maintainer in person who can vouch for their identity.71 On the other hand, it’s common among JavaScript developers to give away commit access more freely. ([Location 658](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=658)) - A company, for example, might release open source code but rely primarily on its own employees to maintain it. Although the project is open source in the sense that anybody can use, inspect, fork, and modify the code, it might be difficult to make substantial contributions as a non-employee. Anybody can submit a change, but that doesn’t mean it will be approved. ([Location 690](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=690)) - By contrast, WP-CLI, a command-line interface for the popular content management system WordPress, requests the exact opposite in its README: Please do not ask support questions on Twitter. Twitter isn’t an acceptable venue for support because: 1) it’s hard to hold conversations in under 280 characters, and 2) Twitter isn’t a place where someone with your same question can search for an answer in a prior conversation. ([Location 703](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=703)) - A project’s contributor growth is a function of its technical scope, support required, ease of participation, and user adoption. ([Location 809](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=809)) - Technical scope refers to the size and complexity of a project’s codebase: in other words, how much more there is to do. A project that feels feature-complete won’t attract as many contributors as one that’s extensible and customizable. It could be widely used, but that doesn’t mean there’s a lot to contribute to. ([Location 811](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=811)) - Focusing on the relationship between contributors and users, we can think of projects in terms of their contributor growth and user growth. This gives us four production models: federations, clubs, toys, and stadiums. ([Location 862](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=862)) - Federations are projects with high contributor growth and high user growth. These are the “bazaars,” first described by Eric S. Raymond, which we typically think of when we imagine an open source project. ([Location 878](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=878)) - Federations also often employ an RFC (request for comments) process, similar to a ballot initiative, to manage major change proposals to the project. ([Location 888](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=888)) - Clubs are similar to meetup or hobby groups: they attract a narrow group of users, who then also become contributors because they have higher context for the project’s activity and feel a sense of affinity to the group. ([Location 905](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=905)) - Many widely depended-upon packages and libraries fit into this model, including webpack, Babel, Bundler, and RSpec. Stadiums are becoming increasingly commonplace today. ([Location 936](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=936)) - Decentralized communities are defined by many-to-many interactions, but centralized communities have a one-to-many social structure. ([Location 939](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=939)) - if we think about who supplies labor to an open source project, it’s “expensive” to onboard new maintainers, because maintenance often requires knowledge that isn’t easily externalized to others. So newcomers tend to make casual contributions, instead of pitching in on more complex tasks around project management. ([Location 964](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=964)) - But a few people noticed that these open source projects operated like communities, so they instead explained the projects’ behavior by describing them as a commons, meaning a resource that is owned, used, and managed by a community. These communities rely upon self-governed rules, rather than outside intervention, to manage the resource and avoid over-provisioning or depletion. ([Location 1041](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=1041)) - Ostrom identified eight design principles that contribute to a well-managed, successful commons: 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. Conflicts should be resolved within the community, using low-cost methods. 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.110 ([Location 1049](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=1049)) - Members also have a low discount rate, which is another way of saying they have “skin in the game,” meaning they intend to participate in the community for a while. ([Location 1061](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=1061)) - Additionally, at a company, only employees can do the work, limited by their job function. But in a commons, anyone can stumble upon an advertised task and volunteer themselves. By removing “property and contract,” the commons will theoretically select for the best person for the job at a lower cost. ([Location 1085](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=1085)) - A few of the conditions that Benkler identifies as necessary to pull off commons-based peer production are intrinsic motivation, modular and granular tasks, and low coordination costs. ([Location 1103](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=1103)) - Modularity refers to how the project is organized. Can it be broken into clear subcomponents, and do they fit easily back together? ([Location 1116](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=1116)) - Granularity refers to the size of each module. It should be easy for anyone to jump in and complete the task without too much preexisting knowledge. ([Location 1117](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=1117)) - Coordination work is expensive because it’s not intrinsically motivated. (For example, developers tend to be more excited about writing code than reviewing someone else’s contribution.) And, as anyone who’s tried to delegate work has probably noticed, it’s usually faster to do things yourself than to train someone else to do it. ([Location 1125](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=1125)) - Stadiums have one or a few maintainers, who are surrounded by casual contributors and users. ([Location 1140](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=1140)) - Decentralized communities prioritize work based on abundance of attention: encouraging new contributors, developing governance processes, and improving engagement and retention. ([Location 1143](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=1143)) - But a creator prioritizes work based on scarcity of attention: saying no to contributions, closing out issues, reducing user support. While the commons is tasked with resolving coordination issues, creators are defined by the need for curation. ([Location 1144](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=1144)) - Tags: favorite - Can the management of open source projects accommodate the increasing number of contributors? The frequency and quality of contributions to each of the open source projects studied appears to be highly skewed, with a few individuals (or at most a few dozen) accounting for a disproportionate amount of the contributions, with most programmers making just one or two submissions. . . . If large numbers of low-quality contributions are becoming increasingly common, there may be substantial management challenges in the future. ([Location 1149](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=1149)) - In order for sanctions to be effective, for example, communities need cohesion. But if developers don’t see themselves as “members” of a community, they might not necessarily mind being shamed or kicked out, and may indeed even thrive on such conflict. ([Location 1192](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=1192)) - defining membership boundaries in an open source project turns out to be one of the hardest problems to solve. ([Location 1199](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=1199)) - what defines an outsider in open source, when any developer is supposed to be able to participate? If everybody is a potential contributor, who gets to make, enforce, and follow the rules? ([Location 1219](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=1219)) - “Because newcomers have not yet developed commitment to the group and have not yet learned how the group operates, it is rational for established group members to distrust them.” ([Location 1222](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=1222)) - Sometimes, the term “maintainer” is used interchangeably with “core developer,” which raises another question: Do maintainers write new code, or simply tend to the existing code? The term “maintenance” seems to imply reactive work, whereas “core development” implies proactive work. Maintaining a minimum degree of functionality might include tasks like responding to issues, reviewing pull requests, and upgrading software dependencies. But actively evolving the project would require tasks like defining the vision of the project, writing new features, and reducing “scope creep” (not letting in too many features, which eventually bloat the purpose of the project). ([Location 1379](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=1379)) - Only maintainers are interested in “the success of the whole community rather than that of any special interest within it.”144 While maintainers may do other work for the project, all other work can be performed by other community members, whereas a proprietor’s tasks are reserved for maintainers alone. ([Location 1394](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=1394)) - contributors to an open source project can be classified as either active or casual, which is often determined based on the frequency of their contributions. ([Location 1495](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=1495)) - what constitutes a “frequent” contributor varies depending on the project. ([Location 1497](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=1497)) - Active contributors tend to be somewhat specialized, whether they focus on a specific part of the codebase or contribute their expertise, like security knowledge or managing the community. They’re distinct from maintainers in that they aren’t responsible for the overall direction of the project. While active contributors might care about the community, they’re not expected to make trade-offs between their interests and others’. ([Location 1515](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=1515)) - Whereas a casual contributor might begin by opening an issue or pull request (“I need something”), for example, an active contributor might start out by commenting on someone else’s issue (“I want to help with something”).159 Another common behavior pattern of active contributors is lurking on mailing lists, issue threads, and pull requests before interacting with the project. ([Location 1527](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=1527)) - Active contributors who stick around do so not because they successfully made their first contribution, but because they already came in with the intent to stick around. In other words, they were never really casual contributors in the first place. ([Location 1534](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=1534)) - Casual contributors are in an “I want this fixed, and then I’m done” mindset. ([Location 1561](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=1561)) - Casual contributors don’t plan on sticking around, and they have the least amount of context regarding the project’s process or norms. They only want to know enough to get their contribution merged. Their primary interest is personal, and it’s the maintainer’s job to figure out how to weigh the contributor’s needs against those of the project. ([Location 1564](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=1564)) - For maintainers, it’s helpful to think of contributors as falling into these two distinct “tracks,” identifiable based on self-interested versus prosocial motives, so the maintainers can decide how much time they want to spend on a particular contributor, as well as how to tailor the resources and support that they offer. ([Location 1609](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=1609)) - Generally speaking, maintainers don’t know who their users are. Like lurkers in an online community, users can consume code without necessarily making themselves publicly known. ([Location 1618](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=1618)) - Of the projects that could track usage, most maintainers don’t bother with it, either due to lack of interest or difficulty of implementation, or perhaps to avoid public controversy. ([Location 1632](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=1632)) - A project’s bus factor is the number of contributors that would need to get hit by a bus before the project is compromised. ([Location 1697](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=1697)) - We need to look beyond the total number of contributors, and instead consider contributor quality. Rather than measuring the quality of code that a contributor writes—which would be difficult to objectively evaluate—we could use the quality of a contributor’s reputation as a proxy. ([Location 1729](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=1729)) - “greenfield” projects—those where a developer gets to write software from scratch—are ([Location 1812](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=1812)) - 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](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=1820)) - once software finds a set of users, it’s hard for it to ever really disappear. Someone out there is probably going to use that code for a very long time. ([Location 1827](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=1827)) - ECMAScript is a specification, created and managed by a standards organization called Ecma International. Any changes to JavaScript are discussed and approved by Ecma’s Technical Committee 39, also known as TC39, comprised of companies and organizations that pay for their membership. ([Location 1853](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=1853)) - Richard Stallman first described free software as “free as in speech, not free as in beer,” the distinction he wished to make is that the term “free” referred to what one could do with the software, rather than to its price. ([Location 1895](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=1895)) - In addition to marginal costs, software also requires ongoing maintenance to continue running successfully, regardless of how many people use it. Rather than a function of use, these costs are a function of entropy: the inevitable decay of systems over time. ([Location 2070](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=2070)) - It’s not just code itself that requires maintenance either, but all the supporting knowledge that surrounds it. When code changes, its documentation must also change. ([Location 2072](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=2072)) - Maintenance makes up a significant aspect of software’s hidden costs. A 2018 Stripe study of software developers suggested that developers spend 42% of their time maintaining code.220 Nathan Ensmenger, the informatics professor, notes that, since the early 1960s, maintenance costs account for 50% to 70% of total expenditures on software development. ([Location 2074](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=2074)) - Open source projects are particularly susceptible to technical debt because they accept contributions from developers who may not necessarily know one another, nor have full context on the project. Scope creep refers to the tendency for software to become bloated over time, because new code additions are evaluated incrementally rather than holistically. ([Location 2085](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=2085)) - Refactoring is the process by which developers pay down technical debt: rewriting, simplifying, and otherwise cleaning up the codebase without changing its functionality. ([Location 2088](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=2088)) - Bigger projects might use a monitoring tool like Snyk or SourceClear to scan their code and notify maintainers of known security vulnerabilities, but the maintainers of smaller open source projects, frankly, often can’t be bothered. ([Location 2158](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=2158)) - Developer Ben Lesh once tweeted, “Open Source is such a strange thing. The open source work I do is clearly the most impactful work I do, but no one wants to pay me to work on it. Yet I’m asked to speak about it, and the work I’m actually *paid* to do no one really wants to hear about. ([Location 2289](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=2289)) - Open source code also tends to be a highly elastic good, meaning that its consumers are sensitive to price changes and restrictions, and will happily switch to a competitor if needed. ([Location 2363](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=2363)) - Developers are finicky consumers. Not only are they discerning, with a high degree of sensitivity to slight differences between open source projects, but if they don’t like the options presented to them, they’re frequently inspired—and have the ability—to try making their own version. ([Location 2365](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=2365)) - When explaining why nobody wants to pay for software, people often cite the free-rider problem, which is the idea that if you can’t exclude others from consuming a good they’ll use it without paying. Eventually, the good becomes overused, as producers lack the resources—usually provided by consumers—to supply it. ([Location 2466](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=2466)) - It’s easiest to see how free-rider problems apply to non-excludable, rivalrous goods, a situation better known as the tragedy of the commons. If a public park is free to access, people will use it without paying for maintenance and upkeep. As more people flock to the park, its quality is diminished. ([Location 2469](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=2469)) - But when it comes to public goods—i.e., goods that are both non-excludable and non-rivalrous, like software—it’s a bit harder to see where the free-rider problem applies. After all, a thousand people can read the same article, or use the same snippet of code, without diminishing its quality. ([Location 2473](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=2473)) - Economists tell us that we tend to rely on governments to provide our public goods because otherwise they’ll become underproduced over time, meaning that consumers are unlikely to provide them on their own, due to the free-rider problem. ([Location 2478](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=2478)) - 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. ([Location 2536](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=2536)) - 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. ([Location 2542](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=2542)) - In open source, anybody should be able to not only view, download, and fork open source code, but also to witness the interactions between members. There’s no reason to prevent users from accessing any of this information, so long as they don’t appropriate attention from producers. ([Location 2630](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=2630)) - There are two types of funders that care enough to spend money on open source: institutions (usually companies, but also governments and universities) and individuals (usually developers who are direct users). ([Location 2996](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=2996)) - Companies are mostly interested in open source code itself as a “product” or commodity. As a result, companies tend to value benefits like code quality, influencing the project’s roadmap, and brand association. ([Location 3002](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=3002)) - Companies will also pay for influence and access to a project they care about. It can be difficult for a company to attract the attention of a project’s maintainers; they find it frustrating when issues and pull requests go unanswered. ([Location 3025](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=3025)) - Patronage is an emerging funding system for online creators today, ([Location 3118](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=3118)) - When it comes to vetting funding opportunities for open source, Ostrom’s principle of seeking “high context, low discount rate” opportunities serves us well. It’s not a company’s or individual’s job to fund every open source project that they use. But some projects will mean more to certain funders than others, and those are the best opportunities to pursue. ([Location 3231](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=3231)) - But if there’s a particular project that they happen to love, that’s the one they should pursue. Likewise, it’s the job of an open source developer to make themselves top-of-mind to a targeted set of funders instead of boiling the ocean. ([Location 3236](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=3236)) - the Django Foundation raised money to create a Django Fellowship program. ([Location 3302](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=3302)) - For precisely this reason, Open Collective, the aforementioned platform used by Vue.js to collect funds, offers a lightweight way to legally accept, manage, and disburse funds. ([Location 3324](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=3324)) - From a governance perspective, funding individual developers is better aligned with the distributed nature of open source projects. To some developers, the fact that these projects aren’t managed by formal organizations is a feature, not a bug. Funding individuals means that funding can come from multiple sources, that funding decisions are made based on the contributions of that particular individual, and that developers can join or leave without toppling the whole project. ([Location 3328](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=3328)) - When GitHub launched its Sponsors product in 2019, the platform encouraged users to financially support the “developers, maintainers, writers, teachers, and programmers” that they depend on. ([Location 3363](https://readwise.io/to_kindle?action=open&asin=B08BDGXVK9&location=3363)) ## Book Review - [[4. Archives/Book reviews/Working in Public|Working in Public - Book Review]] ## Related - [[3. Resources/Readwise/Books/Open Source for the Enterprise|Open Source for the Enterprise]] - [[3. Resources/Readwise/Books/Open Sources|Open Sources]] - [[3. Resources/Readwise/Books/The Art of Community|The Art of Community]] - [[3. Resources/Readwise/Books/The Cathedral & the Bazaar|The Cathedral & the Bazaar]]