making-in-public

making-in-public

Author: Nadia Eghbal

Tags :: R:tech, R:open-source, R:book

  • This book studies open source software communities, how they operate and their challenges.
  • Chiefly focuses on the ecosystem supported by Github, and how it has shaped the open source world since its inception

  • Parasocial Relationships in the developer community

    • Bus Factor - project health is measured by the number of developers that would need to get hit by a bus before the project is in trouble

  • Lack of contributors in large monolithic software projects reflects an adaption to changing environmental circumstances, wherein the relationship between a maintainer, contributors, and users is lighter, more transactional.

  • Problem facing maintainers today is not aroudn getting more contributors, but around managing high volume of frequent low-touch interactions.

    • These developers aren’t building communities; they’re directing air traffic

  • If you read reviews on Amazon, you’re mostly reading stuff by Grady Harp. If you’re on Wikipedia, mostly reading articles by people like Justin Knapp. If you consume any content on the internet, you’re mostly consuming stuff created by people who for some reason spend most of their time and energy creating content online.

  • Does individual contribution create a culture of celebrity in the open soure world?

  • Richard Stallman era

    • Free as in freedom, not free as in beer
    • “Liberation from humanity even at the expense of personal convenience”

  • R:software-licensing

  • Free-software developers like Stallman champion copyleft licensing

    • Like GPL - any code containing GPL-licensed code must also be licensed under GPL

  • Github helped popularize use of permissive licensing

    • BSD
    • MIT license

  • Today’s generation of open source developers need Github for their work

    • “Just as there are Instagram influencers and Twitch streamers, there are Github developers”
    • Coding became like tweeting

  • Software licenses regulate distribution and therefore consumption, but they cannot regulate production…this is the main challenge of whatever comes after open source

  • Code Contribution

    • Process by which a developer gains commit access varies - some projects adopt mindset of neeing to demonstrate trust, others prefer to perate on the basis of trustlessness
    • The idea is to distribute the burden of maintenance by making it easy for others to contribute

  • Projects are classified based on 4 factors

    • Technical scope
    • Support required
    • Ease of participation
    • User adoption

  • Based on this, projects can be classified as thus:

  • Federation

    • Liberal contribution policies, optimitic merging

  • Clubs

    • Kazuhiro Yamashita et al - contributor retention as “stick” or “magnetic”

  • Statium

    • Expensive to onboard new maintainers because maintenance often reuires knowledge that isn’t easily externalized to others
    • Newcomers make more casual contributions instead of pitching in on complex tasks
    • Characterstic of stadiums is also the role of platforms in enabling centralized communities
    • Flea market vs. diamond dealership

  • Toys

  • Elinor Ostrom - 8 design principles that contribute to a well-managed successful commons

    • Another Ostrom book - Understanding Knowlesge as a Commons

  • Yochai Benkler expanded this model by applying it to the online world - Coase’s Penguin

    • Intrinsic motivation makes it easier for people to self-organize to achieve the same outcome
    • Modularity and Granularity
    • Low coordination costs are necessary to produce in a commons
      • When coordination costs outpace benefits, commons breaks down as a useful model

  • Context collapse - Facebook newsfeed - Eguene Wei blog post

  • What defines an outsider in open source? Especially when any developer is supposed to be able to participate by definition?

  • If everybody is a potential contributor, who gets to make, enforce and follow the rules?

  • Consensus seeking vs consensus

    • IETF uses “rough consensus”
      • In consensus-seeking model, goal is not to “win” votes, or unanimity, but rather to ensure that there’s a forum for people to raise and discuss concerns, and that nobody feels strongly enough to block
      • Rough-consensus is achieved when all issues are addressed but not necessarily accomodated