You see it all the time; a repo with a thousand issues, a hundred open PRs, a thousand forks. v2.0 is on the way but there’s no clear roadmap or communication. Those of us who have worked on open source can spot it, burnout is afoot. The project got bigger than what the person or organization could realistically maintain. The maintainers are too busy or too burnt out to get the project back on track.
My open source burnout saga is pretty standard. My coworkers and I made a jQuery plugin that solved a hole in the web platform. It got pretty popular, and we made another one, and another one. Then the issues started pouring in; the surprise refactors, the undiscussed feature drops, the commit stat beefers, the good ideas I don’t have time for, the bad ideas I don’t know how to say “no” to, and the endless “this doesn’t work and you’re a bad human” support requests.
The critical issue for me was that open source was counter-cyclical to my life. I’d open source in slow times, but couldn’t manage client work and open source work in busy times. Out of principle we don’t work on weekends at Paravel… but people on GitHub sure do! Every Monday morning my inbox would be full of crushing guilt and neglected responsibility as issues piled up on my projects.
For every issue closed, three new issues showed up. I love open source, but it felt endless and unmanageable. As burnout encroached, I went into self-preservation mode. I did a bit here and there, but sought refuge for my mental health in video games and comic books instead of working nights and weekends. Years went by and having children deleted any concept of spare time.
It would be great if I had more time! But time requires money. Sentry and GitHub hosted a panel this week called “The Future of Open Source: Is It Sustainable?” which was a candid discussion about funding. There’s different shapes funding can take, but most open source funding happens through either a dedicated employer, support contracts, a crowdfunding tip jar, or a foundation; the unifying factor seems to be maintainers get paid. Money helps make open source sustainable.
But financials are one part of the sustainable open source equation. There’s an emotional cost to having a publicly available project that hundreds or thousands of people and companies depend on as well. One of the best talks I’ve heard on open source maintenance and one I reference often is Jacob Thornton’s 2012 dotJS talk “What Is Open Source & Why Do I Feel So Guilty?”
From the old Xerox PARC days to the open sourcing of Netscape in 1998 (which was the first use of the term “open source”) to the modern day npm install whatever-i-want; open source has come a long way. In ye olde times, we downloaded shareware from Sourceforge which was an effective way to install malware on your computer. GitHub’s launch in 2008 fundamentally changed how we build, share, and distribute software. It has even turned a proprietary titan like Microsoft into an open source advocate. The internet relies on people working for free.
Towards the end of the talk, Thornton gets to the heart of the issue:
With the acceleration of GitHub making everything more efficient, making everything easier and easier, the time to burnout is accelerating at a break neck pace.
“Burnout”. There’s the word.
I sometimes wonder why a company like GitHub doesn’t offer educational, financial, or organizational support to maintainers. There’s plenty of write-ups on GitHub about how to start a new open source project, or how to add tooling, but almost no information or best practices on how to maintain a project over years. I think there’s a big education gap and opportunity here. GitHub has an obvious incentive to increase num_developers and num_repos, but I think it’s worthwhile to ease the burden of existing developers and increase the quality and security of existing repos. Open source maintenance needs a manual.
If I were to spitball some chapter titles or sections for a manual, it’d look like this:
- Differentiating between support requests and Issues
- Issue management (issue templates, labels, sticky issues, closing strategies)
- How to handle volume without losing your soul
- Landing pull requests from strangers (security concerns, etc)
- Setting up testing and continuous integration
- How to get Sponsors
- How and why to use Discussions
- How and why to use Projects and Milestones
- How to write good documentation
- Setting boundaries and office hours
- Effective and clear communication
- Choosing an open source business model
Or what about offering in-person support? Developer Advocates could offer this list of services to project maintainers in exchange for livestream or video content. I’d love to see more content where existing projects get help on tooling or process instead of always starting from a blank repo. Call it “Pimp My Repo”, get Xzibit to host, sell it to MTV. I’d watch it. I’d also watch interviews with successful maintainers to learn about their maintenance routines. It’d be beneficial to the open source community as a whole to replace the starving artist —slash— burnt out maintainer trope with chilled out maintainers who have a good work/life balance.
I think there’s also a lot of opportunity for lessons in Open Source Citizenship education as well. Instead of endless “Fuck you, fix my project” requests, there’s some hoops to jump through, some education, some reminder that there’s humans working for free on the other side of that comment box. CONTRIBUTING.md is a good step but contrast that with something like Discord’s welcome screen feature where you have to read and agree with a code of conduct before you can contribute. Anything to curb the entitlement and abuse is welcome. Onboarding people to the proper etiquette for filing a good bug report with proper repro steps or a reduced test case would go miles.
There’s also another idea out there: a “Pay to Engage” model. You can read all the code, all the commits, all the issues, all the discussions, fork it, clone it, but if you want to engage and ask for help, you need to pay. Pay to Engage isn’t for every project and could hinder some projects, but it could unlock some sustainability.
These are ideas, I probably have a million more. And you probably have a million as well. I’d love to read your blog posts about it. If you maintain an open source project, what’s been successful for you on the marathon? What’s worked? What hasn’t? My weary soul wants to know.