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?
“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?
“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”
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]
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)?
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]