Matthew Lang

Tonight I moved all my personal projects over to GitLab following Sourcehut’s changes to their terms of service regarding LLMs. I’m still not entirely convinced that my projects are in breach of these terms, but I’m making the move anyway.

I have some changes to do to my Rails application that I use to publish posts and upload images to my blog, so I am having to write manual posts at the moment, but it shouldn’t take me long to get this application updated to work with GitLab.

I still have another account to move from Sourcehut to GitLab, but I can take my time with that one.

I need to find a new forge now that Sourcehut is prohibiting the use of LLMs. There’s an interesting discussion about this on Lobsters.

I’m still trying to assess whether I am in breach of this with the two paid accounts I have at Sourcehut. The change to the terms is minimal, but I am not entirely convinced that I am breaking the terms and conditions of their service. With these two accounts, I have used LLM tools to generate code that, for the most part, I have amended before committing it.

I also have a repo for a web application I used to publish the content for this blog, which calls on an external LLM to generate alt text for images.

But better to be safe than sorry, so I think I will end up moving these accounts elsewhere. GitHub is out, so I am looking at GitLab again and perhaps Codefloe, which has the benefit of being hosted in Europe, but is only supported by donations. Self-hosting isn’t an option for me. I don’t have the time to maintain my own forge.

A shame that I am making this move, because I like the Sourcehut product. It’s minimalist and does everything I need it to.

I’ve been looking at several PostgreSQL clients as I migrate my local development databases away from Docker containers and back to a native PostgreSQL installation.

As I evaluated several desktop apps to manage these databases, I was disappointed to find that many require a monthly subscription.

The subscription model makes sense for server-dependent software. The server is part of how the product works and is often a key component. The product might use the server to sync information between devices or to process information in the background. The subscription model covers the ongoing costs of running and maintaining the servers on which the product depends.

Why a subscription model for a desktop app though? In most cases, the desktop app runs on your own hardware. In the case of a PostgreSQL client, it can open databases that exist on my laptop or even on another remote server, but the product itself doesn’t need a server to do this.

The justification is revenue predictability. One-time purchases tend to spike at launch and taper off, making it hard to forecast earnings or plan for the future. A subscription smooths that out.

I get why developers go down this route. Predictable revenue is easier to build a business around than the feast-and-famine cycle of one-off sales. But predictability is a benefit to the developer, not a justification rooted in the product itself. A $20/month subscription for a desktop app will cost $240 a year, every year, for software whose core functionality was largely complete on day one.

There’s a better model from back in the day before subscriptions. A one-time purchase with an optional paid upgrade for major versions, the approach taken by apps like Postico and TablePlus, gives the developer ongoing revenue tied to actual new work and gives the consumer a cost that reflects what they’re actually getting. If the subscription model is justified by ongoing server costs or continuous development, fine. But if it’s just a pricing decision dressed up as a product decision, it’s not a product that I think I will give my money too.