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:
- Who can release open-source software (OSS)?
- What do we require from someone releasing OSS?
- What can the OSS developer expect from others?
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!
Ben R. Rich and Leo Janos: Skunk Works (1994)
Ben R. Rich worked in Lockheed’s secret projects division, the Skunk Works, for nearly forty years in total, leading it for about fifteen years. During his career, Rich participated in the development of the top-secret U-2 and SR-71 spy planes, as well as the F-117A stealth fighter, all of which are prominently featured in this book. 📚
The book is also, in its own way, a tribute to Rich’s predecessor, Kelly Johnson, under whom Rich worked for years before being chosen as his successor. Johnson was an aviation genius who could intuitively evaluate the characteristics of aircraft with astonishing accuracy. He was also clearly the Steve Jobs of his time, micromanaging when necessary and giving his subordinates a piece of his mind if work was done lazily.
The book is full of delightful anecdotes and interludes from various parties, such as CIA and Air Force pilots who operated Skunk Works equipment. In the movie Top Gun, Maverick gives a MiG pilot the middle finger from close range, but in the book, an SR-71 pilot tells of cutting across France without permission, leaving a Mirage fighter that had pulled alongside for identification seemingly standing still with a wave of the middle finger and the activation of the afterburners. The book also tells, for example, of an unfortunate bat population living in an airplane hangar that met its doom by crashing into a stealth plane invisible both to radar and to the bats' echolocation.
The book strongly brings to mind Josh Dean’s work The Taking of K-129, which tells how the CIA developed technology during the Cold War to raise a sunken Soviet submarine, as both involve the development of top-secret new high technology in the same era. I can recommend both if you’re looking for real-life techno-thrillers.
The Pitt
After finishing the excellent HBO Max show Hacks recently I was in dire need of something new to watch. I haven’t watched too many hospital series, but somehow I ended up selecting The Pitt – and pretty much binged it. 🍿
The Pitt is a show about the understaffed Pittsburgh Trauma Medical Center and how the staff navigates the unexpected patients and events. It is a teaching hospital, so the staff includes medical students of various experience, and the older students help supervise the younger ones. There are a lot of characters, each with their own faults; doctors, students, nurses, and patients alike.
Each season focuses on a single 12-hour shift so that each episode corresponds to one hour. The “previously on the Pitt” sections at the start of each episode are genuinely helpful, because there are so many patients so that if one of them has been waiting for their lab results for a couple of hours, it means you might have not seen them in a couple of episodes. So in a sense it’s like 24, but there is no ominous ticking clock at any stage.
The show has not been dumbed down too much for the viewers, so that when a patient with, say, a GSW (gun shot wound) comes in, the doctors and nurses go full jargon for quick and effective communication. For example, the staff regularly performs an “EFAST”, which is never explained. I looked it up though, and it stands for Extended Focused Assessment with Sonography for Trauma, i.e. an ultrasound exam where they look for blood or other anomalies in the chest and abdomen. Here’s also a helpful little table of other common medical terms and their meanings:
| Heart rate | Blood pressure | Blood sugar | |
|---|---|---|---|
| Too high | Tachycardia | Hypertension | Hyperglycemia |
| Too low | Bradycardia | Hypotension | Hypoglycemia |
If in addition to these you know a few basic medicines, you’ll go a long way with the show:
- Ketamine: for sedation and pain relief
- Rocuronium, “roc”: temporarily paralyzes the muscles
- Lidocaine: local anesthetic for numbing something
Especially the “Ketamine & Roc” combo is something they administer almost every time they need to rapidly intubate someone.
So there you go, a first aid kit of surviving The Pitt! I hope you have a good time with Dr. Michael “Robby” Robinavitch and his team.
Star Wars Episode V: The Empire Strikes Back in 100 words
Last year, as I was rewatching the Star Wars movies I decided to write 100 word summaries of them. I managed to complete the following, in this order:
- Star Wars Episode IV: A New Hope in 100 words
- Rogue One: A Star Wars Story in 100 words
- Star Wars Episode I: The Phantom Menace in 100 words
- Star Wars Episode II: Attack of the Clones in 100 words
Let’s jump right into The Empire Strikes Back. I found this one a bit intimidating for there are so many good, memorable scenes, but I’m quite happy with the result, and it didn’t even take too much time after all.
Imperial probe finds rebels on Hoth. Luke is temporarily captured by a wampa. He passes out on the snow field as Kenobi’s ghost tells him to meet Yoda in Dagobah. Han finds Luke, keeps him warm in tauntaun’s intestines. AT-ATs attack, rebels lasso them down and escape. Luke flies to Dagobah. A funny creature turns out to be Yoda. Han & al. are captured by Vader in Bespin, Han is frozen in carbonite. Luke foresees suffering, challenges Vader, loses his hand. Vader reveals he’s Luke’s father. Lando grows a spine, helps others escape. Falcon rescues Luke hanging beneath Cloud City.
Junited 2026
Junited is a no-pressure blog post sharing event that takes place every June. It was invented in 2024 by Robert Birming, and .
While I usually consider my posts ready once published for the first time and only fix typos or such, this particular post I intend to update with new links throughout the month. To keep it light, I won’t be providing much context or commentary, but these will be posts that I have read and enjoyed. Without further ado, let’s get the list started!
Wait, you lost a nuclear warhead?!
When I wrote about the Titanic someone asked me what’s my next cheerful topic going to be – nuclear disasters? That came back to me recently when I found out about the IndieWeb Carnival topic hosted by Alex Hsu.
When it comes to nuclear accidents, everyone knows about Chernobyl and Fukushima, but there have been interesting cases of nuclear warheads getting lost as well. Broken Arrow is not only a 1996 movie starring John Travolta and featuring missing nuclear weapons, but an actual US military codename for nuclear accidents. It’s rather disturbing that such a concept even needs its own codeword, given that nuclear weapons are one of the last things you want to have accidents with. It turns out, however, that people are human and humans make mistakes even when the stakes are high, so here we are.
Some of the most famous of these Broken Arrow cases are:
The 1966 Palomares accident. During the Cold War it was customary for the US bombers to fly around with nuclear weapons, because while in the air those weapons were considered to be safe from a surprise attack by the Soviet Union, and the bombers could also easily be sent for a counterattack in that case. This was called Operation Chrome Dome.
In January 1966 one of these bombers collided mid-air with a tanker while attempting to refuel. The bomber was carrying four thermonuclear bombs. One of the nuclear bombs fell into the sea and the rest to the land near the village of Palomares. The nuclear bombs didn’t go off but the conventional explosives inside two of them did, breaking the weapons apart and distributing radioactive material widely around the area. The US and Spain jointly removed a whopping 1750 tons of radioactive soil and shipped it to the US for disposal. Wikipedia still reports that as of 2025 some contaminated land still remains. All the bombs and their parts were, according to public information, properly recovered though – the one that fell into the sea after almost three months of searching.
Almost exactly two years later, in January 1968, the very similar Thule accident took place. A bomber crashed on ice in Greenland and the conventional explosives inside the weapons spread the radioactive material again, leading to yet another massive cleanup and recovery operation. This time a major part of one of the bombs may even have been left behind, but without the rest of the weapon it poses no realistic danger today. After the Thule accident the US stopped the Chrome Dome flights, because the risks outgrew the perceived benefits.
But it’s not only foreign countries that the US has accidentally almost nuked! In Goldsboro, North Carolina in 1961 the crew lost control of a bomber armed with two nukes when there was a massive fuel leak. The crew had to abandon the aircraft, which then broke apart in the air and released the nukes it was carrying. One bomb buried itself deep in muddy farmland and could never be fully recovered. The other progressed almost all the way through its arming sequence but thankfully had six different fail-safe systems to prevent it from exploding by mistake, because five of them failed and only a single little system prevented the big disaster!
If all of that wasn’t disturbing enough yet, let’s check one more incident: the 1980 Damascus accident. This one didn’t even involve a plane, but something much more mundane: a dropped wrench. Unfortunately this particular wrench was quite heavy, and it was dropped into an intercontinental ballistic missile (ICBM) silo, damaging the fuel tank of the super powerful Titan II ICBM within it. The fuel tank then started leaking, and after about nine hours the silo exploded, catapulting the missile out into a nearby field. Thankfully the safety measures worked perfectly and not even any radioactive contamination took place this time.
So what can we learn about these incidents? Probably not much, except that you should play responsibly around nuclear weapons. So far, good luck has been involved in many of these Broken Arrow incidents, but relying on that is not a viable long-term strategy.
Dan Davies: Lying for Money. How Legendary Frauds Reveal the Workings of Our World (2018)
Former stock analyst Dan Davies has categorized and compiled in Lying for Money various frauds that people throughout history have used to try to extract money from others. Some of the scams date back to ancient times, when, for example, seafarers would take out insurance on their ship and then claim it had sunk, simply painting a new name over the old one.
The scams are presented in an order where the first ones are the easiest to understand, progressing toward more complex ones. For example, it is easy to understand that it is unequivocally wrong to take out a loan and intentionally fail to pay it back. More difficult concepts include various control frauds that are not committed against an individual or a company, but against the market. If, for instance, a bank manager gets filthy rich by setting unrealistically high targets for their subordinates to sell loans to consumers, and rank-and-file employees therefore skip checking the customers' creditworthiness, eventually driving them into bankruptcy, have laws been broken, and who should be convicted for it? Especially when the bank reports to the authorities that absolutely everything is checked and done correctly, and if mistakes have been made, they are isolated human errors. At the same time, however, promotions and bonuses go to the most ruthless employees, and there is no active attempt to prevent wrongdoing whatsoever.
The book presents the scams with numerous practical examples, so you even find out, for instance, what the original Charles Ponzi pyramid scheme actually was. The author also sprinkles in just enough dry humor to keep the text reasonably engaging, but still, at least for me, reading the book took a disproportionately long time. Quite interesting anyway, though.
Discovering IndieWeb content
How do you find good, authentic, personal blogs these days? Certainly not with Google! I’ve compiled a list of resources for that.
Random blogs
Feeds of posts
Lists of blogs
Search engines
With these resources you’ll have no shortage of authentic, personal web sites! If I had to pick one favorite from the list it would probably be Bubbles, for it’s great for finding fresh, new posts that pique your interest. Minifeed comes close second, I like their approach of sharing not just the blog metadata but the titles of the latest posts as well.
Tiny Tool Town
In my I linked to Matt Web’s article where he called for better discoverability of vibe-coded apps. A few days ago I learned that my favorite podcaster Scott Hanselman had created a site called Tiny Tool Town exactly for that purpose! A quote from the About page of Tiny Tool Town:
Remember GeoCities? That glorious, chaotic, beautiful mess of personal websites? Everyone had one. Most of them were terrible. All of them were wonderful.
We’re living in that moment again. AI tools have made it possible for anyone to build software. People are creating tiny, weird, wonderful tools — not because there’s a market for them, but because they want them to exist.
Tiny Tool Town is a place to celebrate those creations.
I find this admirable and delightful. You’re nowadays constantly being told how AI wastes water and makes people dumb and entertainment mediocre, but this site just proudly celebrates everyone’s creations; you can be judgmental elsewhere.
I even contributed my recent app, GPX Comparer, to the directory. Go check it out and submit your pet projects too! 📍🚴
Vibing a wardriving visualizer
A while ago someone was showing off their LEGO creation in my social media feed: a brick-built QR-code containing the credentials to their WiFi network. People rushed to tell them that they shouldn’t share this info publicly, but they appeared unconcerned, for who would actually even know where their network was physically located, right? Can’t do any harm to it if you can’t find it. But could you? Surely there are databases of networks available online?
It turns out there are indeed services like WiGLE that catalogue WiFi access points, Bluetooth devices, and cellphone towers around the world. It relies on people using their Android app and submitting the found networks to the site’s database. Out of curiosity I installed the app and did a bike ride of some 25 km around the city, and much to my surprise logged a whopping 5000 WiFi networks and some 10000 Bluetooth devices! It was a revealing moment when I stopped on a bridge over a highway and looked at the app, and it showed Bluetooth devices with names like Audi, BMW, and Toyota. Almost all new cars can be seen as Bluetooth devices!
Now, I had collected some sample of networks, but how would I view it? The WiGLE app itself does not provide a map view, so I did what anyone would do these days and vibe-coded my own app. I started by typing a stream of thoughts to ChatGPT: I want it to be a web page, not an app you need to install, and I want it to work fully in the user’s browser, not uploading the data to any servers. The app should provide a map with my route and the network observations, along with some playback controls, etc. Chad then turned all this into a proper requirements document that I handed out to the ChatGPT Codex coding agent after creating an empty GitHub repository for the project. Codex crunched the assignment for five minutes and burped out a pull request. I then set GitHub up to automatically publish the project in GitHub Pages and merged the PR, and lo and behold, it actually worked immediately! After exporting my observations out of the WiGLE app I could follow my route and see all the observations on the map.
Random Things Sunday #15: Vibe coding
This week’s main topic is vibe coding, but there’s an aasinsilta,, “donkey’s bridge” as we say in Finnish, to it first:
- Vincent Ritter put together neat API documentation for Micro.blog at microblog.dev. I’ve been working on my own client so this came in at a very good time. I’ll report on my new client some time in the future.
- The new client I’ve been working on has been vibe-coded, which brings me to this new site for the Outcome Engineering Manifesto. It lays down some very sensible ground rules for deliberate coding with agents, emphasizing techniques such as measuring, prioritizing, and risk management.
- Matt Web which may be hyper-specific to the creators' needs. I think that’s a great point, for I certainly wouldn’t have started creating my own blog client without agents, but now I can customize my writing experience just the way I want. It would indeed also be just nice to get a picture of what people are building, by following a single source.
- Finally, the comic relief: OpenAI reports how their models became overly fascinated with goblins. 👺
Dirk Gently's Holistic Detective Agency
I recently stumbled upon the IndieWeb Book Club, where for April: Dirk Gently’s Holistic Detective Agency (1987) by Douglas Adams. 📚 I recall reading it probably some 25 years ago and figured it’s high time to read it again. I thought I remembered something about the book, but in reality I didn’t remember anything else besides a sofa stuck in a staircase.
In Dirk Gently’s Holistic Detective Agency Richard MacDuff, a programmer working for the millionaire computer genius George Way, becomes a person of interest when Way is murdered, so he seeks help from a peculiar private detective who goes by the name Dirk Gently. Gently follows the holistic approach that says that everything is connected. Sherlock Holmes remarked that when you eliminate the impossible, whatever remains must be the truth, but Dirk refuses to be limited by what people generally consider “impossible”. That will turn out to be a handy trait indeed when the case starts to involve ghosts and time travel…
The book starts a bit slow with an Electric Monk on horseback and a dinner at a university, and it isn’t even until the end of the fourth chapter that the titular Dirk Gently is mentioned for the first time. The ending also leaves you rather flabbergasted about what actually happened when time, space, and spacetime don’t quite behave themselves. Suffice it to say it would also help a bit if you knew The Rime of the Ancient Mariner poem by Samuel Coleridge, which apparently everyone in the UK knows. Between the start and the ending the book is still enjoyable enough, with Adams showing his fascination for computers and technology as well as his detest for the British telephone systems. Maybe I should read the second Dirk Gently book again as well, The Long Dark Tea-Time of the Soul.
Tinylytics
I’ve been tracking the number of visitors in my blog with Tinylytics. I originally went for a while without any analytics, but curiosity got the better of me. I didn’t want any heavy enterprise-grade stuff like Google Analytics, but rather some small and independent service, preferably hosted in Europe, so enter Tinylytics. It is pretty prominent in the indie web community, the basic version is inexpensive at $4/month, and it respects the privacy of the guests, so there’s a lot to like in it. You get a dashboard that shows you some high level stats like the country and the referrer domain of your guests. My site seems to get the most visits from Kagi, probably via their Small Web community. If you’re running a personal site without analytics, give Tinylytics a go!
Strava companion tools
Strava is the de facto standard of recreational cyclists for tracking their rides, and I use it too. I used to use Sports Tracker and had been doing so since their Symbian version in the 00s. Its features are absolutely crushing those of Strava’s free version but alas, they don’t have an API, which I wanted, so reluctantly I had to dump them and move to the very constrained free version of Strava a few years back. (Professional cyclists probably use Intervals.icu, but I that’s not something I’ve tried yet.)
I have, however, recently discovered a couple of great sites that make my Strava experience a little less frustrating. The first one was Statshunters. It imports your activities from Strava and builds tables and graphs from them, such as a cumulative-distance-per-year graph. It also calculates your Eddington number, which for me is currently 23 (when calculated in kilometers). If your activities in Strava are public, it should even create you a heatmap of your rides and show you the map tiles that you have conquered.
The other tool I found was Strautomator, which allows you to automate actions with your activities. I’ve set automations to tag my commutes automatically when I leave from and arrive at specific places around specific times, so that Statshunters can show stats for commutes separately. I’ve also set it up to rename certain recurring rides so that I can instantly recognize them and they’re not just called the default “Morning ride” or “Lunch ride”. Strautomator allows three automations in the free tier so you can safely test it, and a lifetime subscription costs just some $30, which I paid without batting an eye, given that it equals only some three months of Strava subscription (which I’m not paying).
Random Things Sunday #14
A few random things I’ve found interesting recently:
- Michael Taggart hates generative AI, yet he recently used it to a great success when writing code. He didn’t enjoy it, but reluctantly admits it did help him a lot. A very level-headed writeup of a divisive topic.
- SkyOSINT is a platform for monitoring satellites, kind of like Flightradar24 monitors planes and MarineTraffic monitors ships.
- Niels Leenher made Doom run on CSS. ‘nuff said.
Random Things Sunday #13
Kari Hautamäki: Tänne minäkin kuolen (2026)
Tänne minäkin kuolen (“I’ll Die Here Too”) is the sequel to paramedic Hautamäki’s previous works Et sinä (vielä) kuole ("(Not) A Time to Die") (2021) and Nyt sinä kuolet (“Now You’re Going to Die”) (2023), this time published by WSOY. 📚 In the foreword, the author mentions receiving feedback that his last book was too dark, but that he intends to write through humor again in this work. Compared to that expectation, I didn’t find the book particularly “funny”, but it was certainly entertaining. The humor is usually drawn from culture clashes and the reactions of paramedics, and it’s often pitch-black.
Bluesky bot to report speeding buses
The people in my neighborhood Facebook group are often worried about cars speeding on the main road that goes through the area. While I can’t do much about that, I realized that I can at least monitor how fast the buses are going and make that visible, thanks to a realtime high-frequency positioning API provided by HSL that runs the public transport system here. This was around June 2020. I implemented a simple Java application to monitor those buses on the street, but the MQTT library I used proved unreliable, so I put the project to slow backburner. My idea was to eventually make it into a Twitter bot, but I never got that far back then.
Fast forward a couple of years to September 2022, two months before ChatGPT was launched. TypeScript was all the rage back then but I had not had the opportunity to use it at work yet, so it clicked to me that I could retry my old bus speed tracker with TypeScript.
How to build an airport in TheoTown
A while back all the windows in our apartment were replaced, which necessitated that we clear the space in front of the windows. This included the table on which my desktop PC is located and that my kid uses to play Cities: Skylines II, so we needed a temporary replacement city-builder for mobile. I had heard of this game called TheoTown and went with that, and it turns out it feels immediately familiar for those who have played city-builders, especially of the older type like SimCity 2000, which is nice.
In the game I, for some reason, found it very unintuitive on how to build an airport. You cannot just plop it down and be done with it, no, you need to place all the runways and individual buildings separately. So, in case you’ve ever wondered how to build an airport in TheoTown, here’s a set of detailed instructions on how exactly to do that.