...
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”
...
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
2021-04-15 - potential discussion questions
...