Working in Public Book Club

Owned by Sarina Canelake (Do Not Use) (Deactivated)
Last updated: May 27, 2022 by Ned Batchelder (Deactivated)
5 min read

This was a group reading Working in Public by Nadia Eghbal: Working in Public: The Making and Maintenance of Open S…

2021-05-14 - potential discussion questions

  • Maintenance burden - no one is intrinsically motivated to do this work. As we scale to 70% of contributions coming from the community, how will we tackle this?

    • I like the quote that software is “free as in puppy” [p 122]

      • No forks!

      • No core modifications!

      • No stale copies! Old versions with security issues, without latest ped advancements.

    • “Maintenance costs make the difference between “forking as a credible threat” and “forking as a desirable outcome” [p 123]

  • “Large open source projects become more modular over time” [p 118]

  • Marginal costs of software development - hosting (PyPI ~$2-3million/year), user support, community moderation, ongoing maintenance, test infrastructure, dependency mgmt, sec vuln, risks of maintaining existing & missing out on “disruptive innovations”. What applies to us? What is edX, Inc paying real cash money for, what costs can we distribute to the community (and how)?

  • Open Source software is a “highly substitutable good” - does that apply to ours? How should that influence our development/team roadmap?

  • She talks a lot about creator “reputation” and how that matters almost more than the software being built. How does/doesn’t that apply to our project?

  • I loved the Christmas lights analogy (pp 158-159; 164) - community doesn’t get to dictate what the maintainers do with their software. Seems much like how we operate currently.

  • Maintainer attention as the limiting resource of a project. We are seeing that today (and have throughout Open edX’s history). Managing attention takes form of:

    • Reducing up-front costs - things like bots, CI/CD, linters, templates/checklists

    • Making yourselves less available - tiered approaches to contributions, eg

    • Distributing costs onto users - moderation, support

    • Increasing total attention available - seeking out active contributors, handing out commit access, fostering a brand, speaking at conferences, active online presence [pp169-183]

    • What do we do/not do? What strategies make sense for the type of community we want to build?

  • “Extractive contributions are those where the marginal cost of reviewing & merging that contribution is greater than the marginal benefit to the project’s producers […] comments, questions, & feature requests” [p165]. How do we handle extractive contributions? How should we?

    • Discourse moderators and question-answerers are valuable: get them to do more

    • extractive:

      • support requests

      • disruptive comments in a forum thread or pull request

      • large PR with a crazy changeset

    • non-extractive:

      • good pull requests

      • leading discussions in working groups

        • even participating productively in a wg or other discussion

    • Parallels to google’s “eliminating toil”: Google SRE - What is Toil in SRE: Understanding Its Impact

      • toil is work that doesn’t add enduring value.

  • “Documentation is a form of automation” - [p 171]

  • There may be stuff to talk about around funding models - see pp 187 - 190 “What companies like to fund”

2021-05-14 Notes (second half of book)

  • an ex-edXer is quoted at the start of the Conclusion: Shauna Gordon-McKeon.

  • How can we modularize? Not just the code but the people (working groups, etc)

    • Remember to make collaborations & interactions more modular

  • Joy & reputation keep you going on os projects

  • How can our leaderboards support reputation/make our community feel inspired?

  • How can we fit in things like “design a cool badge” or other fun uplifting things into our daily work?

    • kind of badges we could put on discourse to inspire/encourage people

  • extractive contributions: how can we empower community members to take care of work we might consider “extractive”?

    • focus attention on things we don’t have the capacity to do right now

  • Also interesting read: https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951

2021-04-15 - potential discussion questions

Questions to consider:

  • What was one of your biggest takeaways?

  • What do you think we could apply to Open edX?

  • Who are the current “maintainers” of Open edX? Who should be the maintainers? [ref p. 89]

  • How well do we fit the definition of federation and where do we fall short? [ref p. 60]

    • Are we more like a stadium, wishing we were a federation?

  • How do we measure the non-code contributor part of our community, and recognize them/their contributions?

  • Given that new developers (“casual contributors”, ref p 103) on a project are often transient/not long-term committers, how much energy and investment should we put into making Open edX super easy to contribute to (thinking 1-1 assistance particularly, but also efforts into improving bots/tooling/onboarding)?

    • Conversely, how might we best set up our project for ease of participation? [ref p. 57]

  • Does edX, Inc act as a “benevolent dictator” or are we seeking forms of decentralized consensus processes? Does edX, Inc actually “work in public”?

  • Do we have the things it takes to “pull off commons-based peer production… intrinsic motivation, modular & granular tasks, and low coordination costs”? [ref p. 74-75]

2021-04-15 Notes (first half of book)

Different types of contributors - think about what types we want

We have a lot of asymmetry & want to make it more symmetrical

  • Stadium has asymmetry between contributors & users

  • Might be more like a club? Most of our contributors are users & vice versa

    • Feels too small though

  • We are maybe stadium moving to a federation?

    • We have lots of sites, they’re not contributing

    • Definitely started as a stadium. All edX, Open edX v0 was just, make it public on Github

    • Initially may have been a club, contributions from Stanford, Berkeley, Xavier

  • Stadiums are centralized communities - they operate on “limited attention” (p 66)

    • We remain the bottleneck due to limited attention

    • If we want to become a federation, do we need to solve this limited attention? (limiting factor is maintainer’s ability to pay attention to demand)

  • Book falls short

    • Anthropologist’s field guide, not an instruction manual

    • Doesn’t talk about organizational backed projects

  • Large proportion of users are going to go away after 1-2 contributions, but some produce a lot more

    • Do we have stats on INCR project, who’s stuck around?

      • Not yet

      • Anecdotally, had a small handful of contributors stuck around and did most of the work. Not all were from preferred providers

    • What was the cost of supporting INCR?

      • uncertainty around this

      • anecdotally, was a lot of work for us

    • What was the benefits of INCR?

      • Identified bottlenecks in setup, new dev onboarding

    • How much energy should we put into supporting new types of contributors?

      • Energy to support new contributors: one time work (ex docs) vs per-contributor (ex reviewing PR, chatting on Slack)

        • Should be doing the first one. That’s obvious

        • Other one is a lot harder. Grows w/ # of contributors; don’t know if we’re sinking effort into someone who isn’t going to stick around

          • How do we gauge whether it is to get someone to stick around?

        • Ex. should we do devstack on Windows? If you’re on Windows, you really can’t contribute code

          • or side-step by having hosted devstacks

        • How can we leverage the community to start doing the 1-1s?

          • Like the responses that people give to help encourage posters?

          • Ask core committers to help mentor? How do we do the same?

        • How can we provide tasks (INCR, byte sized, etc)? is there a lightweight way? how do we prevent them from getting stale? how do we respond quickly to something we say we want?

          • are byte sized tickets a good thing to have?

            • it’s good for a first PR - but is that what we want them to always do?

    • Contributors

      • “Contributor pathways”, like career pathways

      • Type of contributors

        • Drive-by, won’t stick around

        • Long-term, can get invested

        • Open-source experienced, who can help us with dependencies

        • Core committers (inside & outside of edX, Inc)

    • Modular & granular

      • Architecture and tasks

      • Impactful to figure out modularity of code

        • Hard to empower the community to just do this

        • Need to collaborate on architecture, but then maybe can lay out a clear path (no matter how hard) could get community to help us out

        • Working group!