JulyReply
- Who can release open-source software (OSS)?
- What do we require from someone releasing OSS?
- What can the OSS developer expect from others?
Re: Re: Most slopcode projects are abandoned and deleted within months of release
Michael Harley recently commented on Thom Holwerda’s post commenting on Evangelos (Evan) “GeopJr” Paterakis’s post:
Evangelos “GeopJr” Paterakis: ⤷ Thom Holwerda: ⤷⤷ Michael Harley:
Michael wrote:
Building is fun and interesting but maintaining? Not so much. My takeaway from this is that we should beware of single developer projects, especially ones a developer coded with LLM coding agents.
I’m certain there are successful single developer projects that are around for the long term, but a single developer who used AI to develop their project seems very likely to abandon it when they get bored and are ready to move on.
So, maybe give a new project a year of releases before you start using it for anything important.
For starters, yes, do give new projects a year before you start using them for anything serious. This goes for basically any new and unproven project, single developer or not, AI-generated or not. For just playing around, use whatever you want.
In general, however, I think this is very much a multifaceted issue:
For point one, I think the obvious answer is that anyone can release open-source software. To say otherwise would be gatekeeping.
It gets more interesting at point two: what can we require from someone releasing OSS? Michael seems to suggest that we should expect them to maintain their software, but I would have to disagree. As someone who publishes OSS, you’re not in debt to anyone unless you’ve actually made some binding contract with them. GitHub is full of abandoned projects that only ever received their initial commit, and this was already the case long before the introduction of coding agents.
Point three is probably the most interesting one: what can the OSS developer expect from others? Evan’s original post stemmed from the fact that Flathub banned AI-generated submissions. Flathub is like an app store for Linux, and they have strict standards on the apps included there, as they should. My take here is that no matter how you produce the code, you still need to own it. If you haven’t reviewed the code yourself, you cannot expect anyone else to put in that effort for you either. We’ve been through this conversation with my team at work as well and, after some initial struggles, reached a consensus that this is how it ought to be. If you’re working in a team, AI doesn’t necessarily speed you up that much because you still need to own your code and be able to explain to others why something is done the way it is. “I don’t know, the AI made it” is not a valid excuse at all.
Thom quoted this part from Evan’s original post, saying it’s “absolutely soul-crushing”:
Of the 120 unique repos, 32 were maintained and 88 were abandoned. No seriously, a big portion of them was completely deleted, nowhere to be found, others stopped 6 months ago, right after submitting to Flathub.
Now, I don’t know, is that? Those are just plain numbers that are rather meaningless without a baseline for comparison.
I reached out to Evan, but as he had manually checked all 120 repos and there were some 500 submissions in total during the same time period, it’s understandable that he didn’t check the repos not marked as “AI slop”. We could, for example, find the number of archived Flathub packaging repositories easily (it’s 10 for apps both published and archived in 2025), but that tells us nothing about their actual upstream repositories. In other words, there doesn’t seem to be an easy baseline available.
So, this little piece of research still isn’t very scientific, as Evan indicated in the disclaimer of his original post, and we should bear this in mind:
It’s important to note that this is not 100% accurate. It’s impossible to know for sure if something is still maintained based on the amount of commits per time period, unless it has been declared as such. Software sometimes is “done” and needs no further changes, other times the maintainers are taking a break.
Anyway, I’m now tempted to quote Evan for the last time:
What do we get out of these results? Honestly, not much.
Vibe-coding is all nice and fun and IMO should be encouraged – as long as you don’t expect others to review your code for you. It’d also be nice if you clearly disclosed that your repository was vibe-coded. For a friendly approach to vibe-coded apps, consider something like the Tiny Tool Town that I wrote about earlier.
Re: JulyReply 2026, a blog connecting month
Last month, June 2026, I participated in Robert Birming’s Junited 2026 blog post sharing event. Now it’s July which Robert has branded the JulyReply blog connecting month. The idea is quite simple: if you find a blog post that provokes some thoughts for you, you write a reply to it in your own blog, titled “Re: [the original title]”, just like in the old email conversations.
I think this is yet another good, low-effort event of spreading the Indie Web love. Not all blogs have a reply feature in them, and even if they did, for heated topics it might turn into a bit of a flame war in which one doesn’t want to participate. When you reply in your own blog, you’re in control of the reply. I have also on a couple of occasions replied to a blog author by email, but then it’s just between the two of you, whereas a new blog post might benefit more people.
You’ll find all of my JulyReplies under the JulyReply category. The number of those replies probably won’t be too high, but I’ll at least try!