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.
\nI’m pretty AI pilled at this point. Most of my colleagues are as well. Overall it’s very useful and removes the bulk\nof the annoyance and pain from software development and ops for me. I no longer lose an entire afternoon for some\nsilly syntax bug or I can prototype three solution ideas faster than I could start even one of them before.
\nI can just build. And honestly at a higher quality level vs effort than ever before.
\nBut with this great power, comes some responsability. And as a community we’re failing in the responsability area.
\nPeople’s hearts are in the right place. They’re mostly trying to help, but they’re drowning the maintainers in the process.
\nIt 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.
\nSure we had bad issues and crap PRs before, but now it’s a slop tsunami for popular projects.
\nNeed some evidence? Github recently talked about this and show us some numbers. They’re even worse than I imagined.
\nFrom https://github.blog/news-insights/company-news/an-update-on-github-availability/
\nWe’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.
\nSo what do we do?
\nBe a good community member. Don’t be that guy (or girl).
\nSURVIVAL TIPS
\nPhoto by Kyle Glenn on Unsplash.
\nIf you’re a maintainer suffering from this, here are some tips.
\nUse something like Mitchel Hashimoto’s Vouch to restrict who can create new Issues and PRs in your projects.
\nI’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.
\nOpen Source Weekend
\nPhoto by Andriyko Podilnyk on Unsplash.
\nSteal Mario Zechner’s idea and close off your issue tracker and contributions for weekends or even longer holidays to preserve your sanity.
\nIf the bug or contribution is actually meaningful to the author, they’ll make time to contribute it when you open things back up.
\nI 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.
\nBut 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.
\nThe key is to ensure you do the following:
\nWe 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.
\nYou need to strike a balance your workload with not offending or scaring off your future project contributors.
\nWhich is why investing time making sure your messaging is clear and Mr. Rogers nice is where I would advise you start.
\nAnd if all that isn’t enough? Consider moving off Github entirely so there is a bit more friction.
\nWe’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.
\nAt 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.
\nFounder of REVSYS, Django Steering Council, PSF Fellow, and former President of the Django Software Foundation.
\nExpert in building, scaling and maintaining complex web applications. Want to reach out? Contact me here or use the social links below.
\nGet the occasional email from me when I write something new.
\nStruggling with architecture decisions or team dynamics? Ask me any tech, business process, or entrepreneurial question, and I'll do my best to help!
","headings":[{"level":1,"text":"Open Source Maintainership in an LLM world","id":"open-source-maintainership-in-an-llm-world"},{"level":2,"text":"We’re accidentally killing Open Source","id":"we-re-accidentally-killing-open-source"},{"level":2,"text":"First, don’t be part of the problem","id":"first-don-t-be-part-of-the-problem"},{"level":2,"text":"Gate your contributors","id":"gate-your-contributors"},{"level":2,"text":"Conclusion","id":"conclusion"},{"level":2,"text":"Resources","id":"resources"},{"level":3,"text":"Frank Wiles","id":"frank-wiles"},{"level":3,"text":"Join my newsletter!","id":"join-my-newsletter"}]}}