--- tags: book review, software coop, sw coop --- # Book Review - Working in Public: The Making and Maintenance of Open Source Software by Nadia Eghbal - This hackmd: https://hackmd.io/@vulk/rkWiQjaM_ - Sw Coop issue: https://github.com/vulk/Austin_Software_Co-operatives/issues/33 - Meetup: https://www.meetup.com/Austin-Software-Co-operatives/events/gzxfglyccfbfb/ - Slides: https://docs.google.com/presentation/d/17Lf0-fbdCJYf3yZ4i7-Km2ZV5D8baEjXF5PVHN2Rm-w/edit - Goodreads: https://www.goodreads.com/book/show/54140556-working-in-public --- ## Chapters: - Introduction - Chapter 1: GitHub as a Platform - New services and software are focusing more on developer work flow - MIT vs copyleft - Copyleft - this is intentional - in some ways free software developers are compensated by when the free software world grows because derivaties of the sofware must be libre free - quality of contributions - github has made it so easy to contribute that the quality of contributions has gone down. titles are useless, not running tests, not understanding how to handle merge conflicts, etc. - contributors (sometimes new devs) need to wait longer because of the time it takes to deal with so many contributions that are lower quality. specifically ones that contributors could deal with if they took a little more time. - Platforms as allies? Why are they not tools. - Open source does not designate how software is produced. This allows each community to decide for themselves. It also means navigating multiple projects requires learning new processes and tools for each group potentially - Developers have opinions. No one right way to do things. - Some prioritize stability and/or security. Some prioritize modularity, features development, and contributions - reaching out through private channels is considered rude unless its requested/specified. - Chapter 2: The Structure of an Open Source Project - Club - example: Astro.py - astronomy software - Chapter 3: Roles, Incentives, and Relationships - 8 Principles for Managing a Commons - http://www.onthecommons.org/magazine/elinor-ostroms-8-principles-managing-commmons 1. Define clear group boundaries. 2. Match rules governing use of common goods to local needs and conditions. 3. Ensure that those affected by the rules can participate in modifying the rules. 4. Make sure the rule-making rights of community members are respected by outside authorities. 5. Develop a system, carried out by community members, for monitoring members’ behavior. 6. Use graduated sanctions for rule violators. 7. Provide accessible, low-cost means for dispute resolution. 8. Build responsibility for governing the common resource in nested tiers from the lowest level up to the entire interconnected system. - Chapter 4: The Work Required by Software - Rewrite software to clean things up. - 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. - Eghbal, Nadia. Working in Public: The Making and Maintenance of Open Source Software (pp. 117-118). Stripe Press. Kindle Edition. - Innovation and maintenance must be balanced. - innovation. It’s not enough to maintain a tool that everybody uses begrudgingly. The first-copy costs of software often piggyback off the mature, end-of-life costs associated with an older project. - Eghbal, Nadia. Working in Public: The Making and Maintenance of Open Source Software (p. 137). Stripe Press. Kindle Edition. - Reputation maintenance cost - Reputation, like software, requires maintenance over time. - Eghbal, Nadia. Working in Public: The Making and Maintenance of Open Source Software (p. 154). Stripe Press. Kindle Edition. - Chapter 5: Managing the Costs of Production - “Nobody can keep open house in a great city.” —JANE JACOBS, The Death and Life of Great American Cities261 - Eghbal, Nadia. Working in Public: The Making and Maintenance of Open Source Software (p. 155). Stripe Press. Kindle Edition. - 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. - Eghbal, Nadia. Working in Public: The Making and Maintenance of Open Source Software (p. 155). Stripe Press. Kindle Edition. - The commons. Self-managed institutions and resources. - bad behaviour is the norm online - online behaviour considered rude in person is not only tolerated but often considered the norm and encouraged - Only an extremely rude person would consider marching up to our neighbor’s house, knocking on the door, and demanding a surfing Santa. But online, it’s considered normal for people to comment on articles and posts with derogatory or demanding things, or to open issues on an open source project, requesting new features or asking for support. - Eghbal, Nadia. Working in Public: The Making and Maintenance of Open Source Software (p. 160). Stripe Press. Kindle Edition. - managing open source code requires separating its production from consumption: treating them as not one but two types of economic goods. Anyone can consume code, but only a limited number of people can produce it. - Eghbal, Nadia. Working in Public: The Making and Maintenance of Open Source Software (p. 160). Stripe Press. Kindle Edition. - The bigger issue, he explains in a blog post, was that Python’s participatory decision-making process didn’t scale: - Eghbal, Nadia. Working in Public: The Making and Maintenance of Open Source Software (p. 161). Stripe Press. Kindle Edition. - What metrics can you use to help see when a process is hiting its limits. re: pythons participatory decision making process on a mailing list open to any commenter - Van Rossum’s suggestion highlights the critical difference between content that is public and content that is participatory. 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. - Eghbal, Nadia. Working in Public: The Making and Maintenance of Open Source Software (p. 161). Stripe Press. Kindle Edition. - public content vs participatory content. this can be used for a coops content and activities. also relates to maintainer activities which could be publicly viewable but not open for everyone to join in and "help" - Static state and dynamic state of open source code - non-excludable, rivalrous - Delay for license to go to open source (Sunset license) - based on commit instead of specific time - specific time - usually to a release - dual license - Conclusion - Attention economy - consumers usually the focus, producer attention is just as important - creators, maintainers - need to figure out how to manage and "pay" ## Notes: ### Audible Chapter 1: Github as a Platform / 01:05:22 - github has made it so easy to contribute that the quality of contributions has gone down. titles are useless, not running tests, not understanding how to handle merge conflicts, etc. contributors (sometimes new devs) need to wait longer because of the time it takes to deal with so many contributions that are lower quality. specifically ones that contributors could deal with if they took a little more time. Chapter 1: Github as a Platform / 01:08:43 - platforms as allies? why are they not tools... ugh Chapter 1: Github as a Platform / 01:09:25 - it might be found that with out the tools we have now, starting with Git, then GitHub, and such you could not handle interacting with such a large userbase w/o the personality and behaviour of RMS, Torvalds, etc. Or another way to put it... w/o the current tools it takes a certain type of person to deal with the interactions which are even more tedious and frustrating via direct email, mailing lists, and news groups. There are rules of behaviour on mailing lists and news groups. A few bad apples can cause havoc in those places. In a platform like GitHub more people can jump in and help deal with problems. Chapter 2: The Structure of an Open Source Project / 01:18:08 - getting commit access is different across projects. keeping it flexible and understanding that one process may not fit your needs is important. decide on what is priority. eg. moving fast, stability, security Chapter 2: The Structure of an Open Source Project / 01:23:27 - reaching out through private channels is considered rude unless its requested/specified. Chapter 2: The Structure of an Open Source Project / 01:25:27 - repository is the directory with code, docs, etc. project implies everything including the repository. possibly multiple repositories, communication channels (slack, discord, mailing lists), issue tracker, etc Chapter 2: The Structure of an Open Source Project / 01:12:42 - Open source is tribal. Each project has it own norms Chapter 2: The Structure of an Open Source Project / 01:13:44 - Open source does not designate how software is produced. This allows each community to decide for themselves. It also means navigating multiple projects requires learning new processes and tools for each group potentially Chapter 2: The Structure of an Open Source Project / 01:19:30 - Developers have opinions. No one right way to do things. Some prioritize stability and/or security. Some prioritize modularity, features development, and contributions Chapter 2: The Structure of an Open Source Project / 01:43:08 - Contributor and user growth Federations, clubs, toys, and stadiums Chapter 2: The Structure of an Open Source Project / 01:44:51 - Federations have high number of contributors and users. K8s, node.js, and Linux are examples. They have a need for a more complex governance model. Chapter 2: The Structure of an Open Source Project / 01:45:29 - Federations often utilize liberal contributions policies - optimistic merging - Liberal contribution polices such as optimistic merging. This requires distributing responsibility and control. Pushing maintainer ship to a wider group of contributors. - Chapter 2: The Structure of an Open Source Project / 01:45:38 - Clubs have high contributor growth but low user growth - Chapter 2: The Structure of an Open Source Project / 01:47:05 - Users are enthusiasts who sometimes become contributors themselves - Chapter 2: The Structure of an Open Source Project / 01:47:57 - Successfully clubs are sticky. They keep their contributors - Chapter 2: The Structure of an Open Source Project / 01:51:00 - Stadium projects tend to have a centralized structure. Large user base and just a few maintainers - Chapter 2: The Structure of an Open Source Project / 01:54:14 - The longer a project goes with out externalizing it's contributing/maintenance/development process the harder it is to do so in the future. The project becomes more and more complex. It's a lot of overhead to onboard new people. This could be similar with a cooperative - Chapter 2: The Structure of an Open Source Project / 01:56:24 - Federations tend to distribute responsibility and empower maintainers and contributors. Requests and maintenance is spread across a broader group an autonomy is encouraged. Stadiums tend to use automation and cut down any noise so that the small number of maintainers (sometimes just 1) can handle all the requests directly. - Chp 3 - different types of contributors - casual to significant + active - self interested and long term - important for model in use - Chp 3 - behaviour / motivation of contributors - Long term contributor: - Commenting on + helping existing issues - A "user" could actually be an active contributor based on their community engagement - motivated by being a part of the community - Casual contributors - drive by. transactional relationship - they can have made many contributions even large - no deep connection to the community - self-interest is main focus - Chp 3: Creators and curators. Different jobs and takes different people. - Chp 3: What is an outsider? - What defines an outsider in open source when anyone can participate? Some protection of the project for the currently committed maintainers from other people who may not care yet if they destabilize the project (eg. not committed). - Chp 3: Intrinsic motivation to help people self coordinate - commons self organizing and coordination ### My general notes - Intrinsic and extrinsic motivations - Intrinsic motivation for creation - Maintenance is often overlooked and does not have the same motivation driving it. - maintaining is is tedious and unthankful - coordination is a lot of work, critical for growth and as a project/group becomes larger and larger - Maintainers and leaders of projects must have commitment to their long term health - Users can have similar long term commitment. They should have a voice - Metrics need to be flexible for each project, org, or coop - Recognizing what model your project or coop is in is important: Federation, Stadium, Club, Toy. - Your model can change. If you want to move to another you need to understand, recognize and intentionally change behaviour and processes to match the model you want to move towards because of expectations of all parties -- users, contributors, maintainers (or members ) - software is not just an object that's static... or even alive that is only code produced. there are lots of additional cost that will be hidden with that view. - Code is a living form of knowledge and history. Human relationships is important to see the value of open source projects and commons. - Complex living systems. Cats. not toasters. - Value is in the people writing code, maintaining the projects, coordinating, etc - Open source code like a public good, but maintainers/maintenance is a commons. - maintainers are limited as is their time and energy - Move towards relationship culture vs consuming code as a product / consumer good ![triangle chart showing number of maintiners (1-5), contributors (10s to 100s), and user comparison (1000s to millions)](https://hackmd.io/_uploads/HJk1cs6zO.png =500x) ---- ## Additional references Podcast - https://changelog.com/rfc - Request For Commits explored different perspectives in open source sustainability Videos - [Nadia Eghbal presentation of The Making and Maintenance of Open Source Infrastructure to the Long Now Foundation](https://www.youtube.com/watch?v=5wLKnN3To-k) from Dec 3, 2020 - [LeadDev interview with Nadia Eghbal](https://www.youtube.com/watch?v=Ti43VK1MBM8) from Nov 4, 2020 - [Fireside with Nadia Eghbal](https://youtu.be/8X89YdZMyrQ) from Aug 2020 - [Rebuilding the Cathedral by NAdia Eghbal](https://youtu.be/5Vy5s9p5A0M)from Jun 26, 2019