Not alone, and for a long time now, I’ve been battling with making my open source contributions sustainable.
The open contribution model engendered by GitHub — where anonymous (to the project) users can create issues, and comments, which are almost always extractive support requests — results in an effective denial-of-service attack against maintainers.
There have been various responses to this problem along some variation of Open source, not open contribution. The SQLite and Litestream projects are probably some of the most well-known examples, but recently, in the Django world, DRF has closed issues and discussions in the same vein too. The goal is simply to keep noise down to an acceptable level, so that development can continue (in peace).
The missing link here for me has always been user support. On the one hand, we simply don’t have the capacity to offer it — allowing open comments on a popular repo floods any signal there might be in the issue tracker, making maintenance impossible.
On the other, we really do want to help users if we can. It is more than just a nice to have.
For years (and years and years) we’ve tried all kinds of strategies. Let's have a mailing list, or a forum, or—weak sauce—GitHub Discussion. If we send the support requests there, the serious development won’t get flooded.
Nice in theory. There’s always noise as things are posted in the wrong place. More, though, unless you have a hero (or two or several) actively committing to working the support channel, it becomes a ghost town. It’s not support. It’s just a less-than-honest way of saying, Sorry, no support offered. I’d rather be honest.
If you do have the Heroes, they get burnt out too, and get criticised for not doing the hard work as well as The Person Not Doing It™ thinks it really should be done. It’s thankless.
It’s here that LLMs really do offer a way forward. I’m working on a new model I’m calling Quiet Contribution, as a working title. That will allow for discussions among regulars to the project.
For anonymous users, who really just want help almost all the time, the pattern I’m settling on is to facilitate them getting their answer from their LLM of choice.
Let’s take Neapolitan as an example.
Using Simon Willison’s Files-to-Prompt tool we can generate a file that we offer users to download:
# From my neapolitan working tree
pipx run files-to-prompt . --markdown -o prompt.txt
Then we tell the user to pass this to (say) Claude with a simple prompt for their question, say, “Please give me a quick-start for using Neapolitan.” (You can see the output of that here). The LLM gives probably a better answer than the human is going to bother with, and 90% of our support issues are dealt with immediately. It’s only those further cases that need maintainer involvement.
The missing link here is (dare I say, just) to prepare the prompt file for users to download (as part of CI, why not?)
We’re all thinking about how LLMs help us write code, but, as an open source maintainer, the ability to bootstrap users helping themselves, where (forever!) we’ve had to divert energy ourselves, is one of the most exciting developments.