Open Source Maintainership in an LLM world

A couple of weeks ago I spoke about this topic at KC OSS Happy Hour and I wanted to turn the general ideas into a post I can point people at who are suffering from this problem. My slides were pretty good, if I do say so myself, so I grabbed the best images and put them into this post where appropriate.

I’m pretty AI pilled at this point. Most of my colleagues are as well. Overall it’s very useful and removes the bulk of the annoyance and pain from software development and ops for me. I no longer lose an entire afternoon for some silly syntax bug or I can prototype three solution ideas faster than I could start even one of them before.

I can just build. And honestly at a higher quality level vs effort than ever before.

But with this great power, comes some responsability. And as a community we’re failing in the responsability area.

We’re accidentally killing Open Source

People’s hearts are in the right place. They’re mostly trying to help, but they’re drowning the maintainers in the process.

It used to be harder to contribute. You had to carve your PRs out of granite with a chisel. That level of effort was a natural gating mechanism for issues and pull requests.

Sure we had bad issues and crap PRs before, but now it’s a slop tsunami for popular projects.

Need some evidence? Github recently talked about this and show us some numbers. They’re even worse than I imagined.

From https://github.blog/news-insights/company-news/an-update-on-github-availability/

We’re burning out our maintainers and major contributors. I could shout from the rooftops until I’m dead about this, but I can’t guarantee it would really make a dent in the problem.

So what do we do?

First, don’t be part of the problem

Be a good community member. Don’t be that guy (or girl).

• Check for contributing guide
• Actually follow it
• Don’t open a million things if you’re new to a project
• Only contribute meaningful work
• Be nice
• Try not to be offended if they don’t want your contribution

SURVIVAL TIPS

Photo by Kyle Glenn on Unsplash.

If you’re a maintainer suffering from this, here are some tips.

Gate your contributors

Use something like Mitchel Hashimoto’s Vouch to restrict who can create new Issues and PRs in your projects.

I’d make the hoops you make people jump through small at first and quickly react and adjust to how things work out in your community.

Open Source Weekend

Photo by Andriyko Podilnyk on Unsplash.

Steal Mario Zechner’s idea and close off your issue tracker and contributions for weekends or even longer holidays to preserve your sanity.

If the bug or contribution is actually meaningful to the author, they’ll make time to contribute it when you open things back up.

I used to not be a fan of communities that automatically closed issues when they went stale, not because of the idea but because their idea of “stale” was usually far shorter than I thoguht it should be.

But in our current situation, I think it’s perfectly acceptable to automatically close issues and pull requests if they don’t match your contribution guidelines as a great first step to keeping your work load manageable AND training new contributors on how to contribute.

The key is to ensure you do the following:

• Explain why you’re closing it. “It’s the AI tsunami and not you personally…”
• Explain what they did wrong in detail and what they need to do to move forward
• No really. Hold their hand
• Be EXTRA nice about it

We implemented a really light and easy process for this in the Django project and it’s working surprisingly well, here is an example where it closed the PR and outlines exactly what is wrong and how to fix it.

You need to strike a balance your workload with not offending or scaring off your future project contributors.

Which is why investing time making sure your messaging is clear and Mr. Rogers nice is where I would advise you start.

And if all that isn’t enough? Consider moving off Github entirely so there is a bit more friction.

Conclusion

We’re all still figuring how to work in this new world. These are just a few techniques you can use today, but I’m certain we’ll discover and develop others over the next couple of years.

At this rate I’m not even sure what revision control is going to look like in 2030 let alone how OSS will work day to day, but for now this is the best advice I have to offer.

Resources

• Original Talk Slides
• Sli.dev is my new favorite way to build presentation slides

Frank Wiles

Founder of REVSYS, Django Steering Council, PSF Fellow, and former President of the Django Software Foundation.

Expert in building, scaling and maintaining complex web applications. Want to reach out? Contact me here or use the social links below.