Vibes and The Software Barrier

As you may know, I am a great admirer of open source software. And this dates back to the early ’90s, when the limits of shareware were reached, and it was clear that that model could not hold. But in recent years, doing OSS has become increasingly difficult, for a very simple reason. Generally speaking, OSS — the real kind — is created by individuals who work on it in their spare time. Now, the interesting question is: WHICH spare time? And HOW MUCH spare time?

The question is not humorous, and it is not a tribute to the pointy-haired boss from Dilbert. The problem is that OSS projects have become increasingly large—at least the relevant ones—and have given rise to a whole series of libraries and tools which, yes, can be used, but the idea of maintaining them or contributing to them is to be ruled out.

But the moment I raise the issue, I am clearly identifying a barrier—a barrier that prevents people from making OSS software, something that keeps them from getting started. And by this I mean something specific, an example I am working on as a hobby.

You will have heard of the fediverse. And if you go and look at how it works, you will discover that it is based on DNS. And DNS, after all, is founded on the concept of “root DNS.” But all the “root DNS” are in the USA, or almost, and in any case they are military, or strongly proprietary. So I said: why not use libP2P and a PGP layer, in order to prevent impersonation? Of course, your instance could be called “Puppe a pera” and you would become, say, “francesco@puppe a pera,” with the addition of highly dangerous spaces, but the point is that, truly, at the level of the federation protocol it is entirely feasible using libP2P.

So I set about implementing it, entirely with on-disk storage, taking snac as a reference, and off I went. What remains is the frontend. I decided to make it headless, offering the availability of Mastodon’s C2S APIs.

And here the Barrier manifested itself clearly before me.

In order to use any Mastodon-compatible client with this software, I have to use the famous Mastodon APIs, since nobody uses ActivityPub’s C2S any more. The result is that you have to implement them. No problem, right?

No. Quite the contrary. Because to make a client that is, all things considered, fairly modest in its features actually work, there are nearly 160 endpoints. To be implemented. All of them.

Working in one’s spare time, this represents an insurmountable entry barrier. So I decided to do something. I finished implementing the backend part, and then I hooked Codex up to my IDE, and I told it, “implement the Mastodon APIs for me. All of them.”

I obviously had to give it a precise context (without that, AI almost always hallucinates) and a method to proceed (same story), in my case EAL5+. And it set to work. Last night. As I write, it has implemented something like 99 endpoints, with just as many routes.

This is huge. Once instructed to run lint, vet, and to write tests in a certain way, the quality is not actually that poor. Of course, I will have to review it, but at a rough estimate it has done ninety man-days of work for me in a single night. Granted, AI is a bit sloppy when it comes to documenting formal requirements and tests, using postconditions, preconditions, and invariants—later we will get there, I will polish everything. But the real point is that even if I were to find bugs, they would still amount to less than ninety man-days. Which, translated into my spare time to devote to an OSS project, would mean two years before having something at least testable.

I know, I am talking about “entry barriers,” and there have already been discussions about the “democratization” of programming. But on the other hand, while we can discuss it in political terms when it comes to large corporations, no one so far has asked what this means for small developers who have an idea in mind and want to see it through, before giving up in the face of the enormous complexity of the work to be done. To do the same thing Codex has done for me—something of almost no value, since these APIs are really not very sophisticated from a technological standpoint, let’s say of very little intellectual value—another project working in Go, and they are a team, took almost two years.

And they are still not finished.

Now, the problem is this: I find myself wondering whether this “barrier of unnecessary complication” is intentional. That is, if I want to build an application that follows a very simple concept (it is nothing more than a kind of email server, with different protocols and a nice UI), and I am faced with 160 endpoints to implement, I will spend 90% of my project doing trivial little things—very tedious, time-consuming to implement, devoid of any real satisfaction, and decidedly of no intellectual value. A typically German kind of work. But you get paid, right?

The problem is that no, volunteer OSS programmers are not paid to be bored in an office. We are not paid at all. What drives us is the passion of implementing an idea and seeing it work.

Let’s be clear: will it become a Mastodon 2.0? I don’t think so. My old experience with the Amiga taught me that when, on a technical level, you have no design flaws, the IT world simply abandons what you are doing and chooses platforms with more defects.

It is as if the core of early adopters were drawn not to the technical soundness of solutions, but to their potential for improvement: which requires a lot of room for improvement—that is, many flaws and shortcomings.

Now you will say that the code is not really mine, but my answer is simple: it is, for the part that matters. The underlying idea was to get rid of HTTP as a transport protocol, of the database as storage, and to build something that does not need anything else to function—not even DNS.

That is the part that matters. Attaching a client to it is essential if you want anyone to use the software, but it is the tedious part. It is like when chefs clean the kitchen, or have it cleaned, at the end of the job. It is certainly fundamental, it is truly important, and doing it well is essential—unless you happen to like cholera.

But it remains the most tedious and professionally empty part of a cook’s work. And if this begins to become 90% of programming time, and a barrier to entry for those who want to contribute, then OSS has a problem.

No, this has nothing to do with “democratization.” The issue here is that an OSS project that ultimately aims to dominate—to become the Zuckerberg of OSS in its field—simply needs to gather a great deal of manpower, let’s say a team, and proceed with an implementation that is deliberately verbose, complex, and unnecessarily complicated.

In doing so, they eliminate competition from individual OSS developers who might have different ideas about how things should be done. You will NEVER be able to compete, in your spare time, with a team that is paid—perhaps with European funding—to work on the project full time, and especially with a team that writes useless code but writes a lot of it, with the usual aim of discouraging individual programmers from competing with them.

But now, the barrier has fallen. If you think that software X needs improvements, or that it could be done much better, all you have to do is build a prototype of the part that interests you, of the improvement you have devised. The tedious part can be left to AI.

This is not democratization—it is simply “guillotining the aristocrats.”

Let me repeat: I do not know (and honestly I do not believe) that my software will replace Mastodon. But the fact remains that having an idea and not being able to see it realized because you lack the time is frustrating and inhuman.

This new development—AI writing code for you, working directly inside your IDE—allows you, in my view, to say: I knew there was a better way to do this. Don’t believe it? Here it is.

And sometimes, it is the small satisfactions that make life better.