Open Source Maintainership in an LLM world

Frank Wiles — Sun, 27 Sep 2026 12:43:39 +0000

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

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 Weekends

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 thought 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

Lets just try it

Frank Wiles — Tue, 26 Sep 2023 16:12:21 +0000

Years ago, a client said, "Let's just try it for a month and see how it goes." That week, I had a drink with my former boss, and he said, "Oh, that's a trick. He knows it's harder to change the process BACK but easier to sell it this way. You got played."

My former boss was spot on. The change was to go from async Slackbot standup reports to synchronous Zoom meetings. Several years later, not only did we still have Zoom standups, but many on the team had daily and a couple of weekly ones. It contributed to a lot of context-switching and slowed down the project noticeably and immediately.

It is not my intention to rail on meetings. That's for another, much longer blog post!

We'll just leave this in for a couple of sprints

Another team I worked with needed a one-off feature flag for a rush request from an important client. Instead of implementing a real feature flag system or using a third-party service, we were asked to hack in a Django setting for this particular customer's unique ID with the promise it would be removed, or we would implement some real feature flagging "in a couple of sprints."

You know where this is going. The one-off flag was still there years later and was there when the project was scrapped due to not hitting its goals. However, it didn't meaningfully impact the project in any way.

But trying things is good...

Yes, trying new things in an effort to improve is necessary and the basis for all real progress. The hard part is having the fortitude to push back on changes that don't work.

The harder part is being able to tell the difference in the first place.

Research shows that it takes about 21 days to form a new habit. Once solidified into a habit, it takes effort to overcome the inherent inertia of the new process. Conversely, trying something for a day or two can easily yield misleading information. You could have done more yesterday because of better sleep and not your new fancy issue tracker labeling system.

How to tell the difference

Here are some methods and tips you can use to make better decisions on when to push back hard on trying something:

Establish the metric(s) you'll judge it against upfront. Otherwise, how will you tell if it's working?
No metrics that make sense or you're too lazy to capture them? Ok, then it's a gut decision and more guts are better than one. At the agreed-upon time, have the whole team vote for the change to stay or go and require a 2/3rds majority to keep it. If it's not obviously good or even just not liked by the vast majority of your team, why do you want to keep it? Smells like ego or a personal preference to me.
Is it reasonable to assume the upside is far greater than the downside? While lots of 1% improvements add up over time, a 25% risk for a 1% gain is usually not worth it. Avoid these entirely.
Consider the change holistically. It may be worth trying if it's a 1% slowdown for one team member once a week but a possible 5% boost for several other team members. Note this works conversely for managers. A 10% speed up for that report you must do weekly should not slow the rest of your team down 1% each.
Horse trade. We'll try your idea for a month if you'll try scraping/changing this other process that gets in our way. The net effect of these two changes could be a win.

Obviously, don't push back on all changes just because they are changes and you don't like change but DO push back on changes that aren't either demonstrably positive or embraced by the majority team.

Or maybe just try it for a month?

Need help optimizing your development team’s ability to get shit done? Frank and his team at REVSYS can help guide you to 2X the velocity you’re seeing now.

DEV Community: Frank Wiles