Working in Public: The Making and Maintenance of Open Source Software - Nadia Eghbal

Reading notes on some of the chapters. Book on Amazon: link

Github as a platform

On contribution

Nearly half of all contributors only contributed once; which accounted for less than 2% of total commits.

The pattern that one or a few developers do most of the work, followed by many casual contributors and even more passive users is the norm, not exception in open source.

On casual contributors: they primarily see themselves as users of the project, rather than a part of a contributor community.

Challenge for maintainers: not how to get more contributors, but how to manage high volume of frequent, low-touch interactions (directing air traffic)

Github’s open source developers have more in common with solo creators on Twitter, Instagram, YouTube or Twitch.

Comparing early internet and social platform nowadays: the early online communities have mailing lists, online forums, membership groups, operated like villages that have their own culture, history and norms. Nowadays creators have much bigger potential audience but the relationship is one-sided, and can be overwhelming.

On free software and hacker

“Free” means you are able to do what you want with the software, rather than the cost. Libre rather than gratis. At least at the beginning.

Bravado, showmanship, mischievousness, deep mistrust of authority. This culture in the 1980s and 90s was closely linked to the early open source software.

“Bazaar”: highly participatory, versus “Cathedral”: restricted to a smaller group

Today’s developer hardly even notice “open source” as a concept anymore, they just want to write and publish their code. They prioritize convenience over freedom or openness.

On licensing

The widespread use of permissive licensing is popularized by GH.

Copyleft licensing (e.g. GNU General Public License GPL) is not commercial friendly as it requires companies to license their software that depend on open source GPL software to have the same license. However GPL gives developers more control over how others use their code in the long run.

As with any other online content today, sharing is the default.

The structure of an open source software

On how projects evolve

Create -> Promote and distribute -> Grow

Projects are promoted like a founder would promote a startup: share on the relevant channels online, give talks at conference and meetups, encourage others to write and talk about it

A sign that the software is used widely: when the maintainer starts doing more non-code (triage issues, review pull requests) rather than code work.

Contributor and users

Depends on technical scope (whether there is much to do), support required (code and admin work), ease of participation (whether on Github) and user adoption (potential contributor base).

Four types of projects

• high user growth, high contributor growth: federations. Rare, impactful, the ‘ideal’ of open source project. Roughly 3% of open source projects. Examples: Rust, Node.js, Linux
• high user growth, low contributor growth: stadiums: powered by one or a few developers. Centralized.
• low user growth, high contributor growth: club. Similar to meetup or hobby groups, do not have a wide reach but are loved and built by enthusiasts.
• low user growth, low contributor growth: toys. Personal project, isn’t trying to grow its user base. Projects on Github with less than 10 stars. Authors do not expect to receive contributions nor do they care about whether people are watching.

Decentralized communities (clubs and federations) have the potential for high user growth - recruit new contributors, reduce contribution friction.

Centralized communities (stadium) depends on the creators to manage user demand - automation, elimination of noise

Roles, incentives and relationships

Firms or communities

Firms (companies, organizations): centralized resources; from a coordination standpoint, managing resources would be more efficient within the same organization - which does not explain why open source developers make software together without formal contracts and financial compensation.

The commons and peer production

Tragedy of the commons: resources depleted by people acting in their own self-interest rather than in the collective interest.

(One of the 8 design principles by Ostrom on) successful commons:

Those who are affecteed by the rules can participate in modifying them.

Strong sense of group identity maks rules, dispute resolution more meaningful.

Coordination cost is lower when self-organized based on who wants to do the work most, anyone can do the advertised work and volunteer.

In contrast, in companies - solicit, evaluate, hire, manage employees; only employees can do the work limited by their job functions.

People collaborating online for no obvious reason beyond personal satisfaction (intrinsic motivation)

Modular and granular tasks: how tasks are organized, and how big each task is.

Low coordination costs: quality control over thee modules, integrate the contributions into the finished product

Contribution beyond code

Some users do not consider them a contributor, but do actually contribute by education, spreading the word, support (forum), bug reports and more.

These active users are similar to contributors but operate independently from project’s contributor community.