Working in Public Book Club
This was a group reading Working in Public by Nadia Eghbal: https://www.goodreads.com/en/book/show/54140556-working-in-public
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”: https://sre.google/sre-book/eliminating-toil/
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
federationand 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!