Software for one

Throughout my decades as a software maker, I've felt intense pressure to deliver whatever useful software I make to as many other people as possible. In commercial software this pressure is natural: if you want to make money, then you need lots of people adopting your software so that they'll want to pay for it. But that pressure is also present for personal projects: to be nice to other people, sure. But also as kind of a hustle I guess? What about getting rich and famous!

Even in the 1990s, the hustle was there: make a few bucks selling shareware, get famous by making popular freeware. In the 2000s it was about making a popular website, and then it was app store download counts, or stars on SourceForge and github. Anything I build might be The Thing, The Ticket, Making It Big, Getting Noticed. It could happen to anyone! (Nevermind that 99.99% of all software isn't going to be used by anyone else. The mere potential for popularity feels motivating.)

So whenever I make a little tool or app, I can't help thinking ahead to how I might share it. Maybe as an app, or a service, or a FOSS project. I think about whether its usability and learnability is up to snuff. I consider how I would package it so that other people could use it for themselves: maybe via a URL, or an installable binary, or as an app in one of the various app stores.

I'm now experienced enough to know that sharing software widely and well requires polishing, packaging, distributing, clearing adoption barriers, fixing "out of box experience", improving learnability, and finding market fit. That's all very hard work. And you know what? It's not the fun part. Those things all happen after I have the little tool working for myself, and the value I've personally gotten from it is firmly delivered. But since I'm an "eat your vegetables" type of person (thanks dad) I usually feel the need to grind out the packaging and distribution work if the project is worth doing at all. And the prospect of doing that is so demotivating that I often just don't do the project in the first place.

Has a career of commercial software development cooked my brain?

In recent years I've started to forgive myself for creating tools that I don't try to polish into products. I invest time writing software (sometimes a lot of time) to solve needs that I personally have... and then that's it. I am aware that other people have the same needs, and could benefit from my solution. But I don't have the spoons to do 5X more effort to package the software for other people, and then maintain it and fix bugs in it and address other people's differing needs into the future. I feel really guilty for not doing this part of the work, but there's only so much time.

So I don't offer a lot of what I make to the world. This is my least favorite part of making software for myself --- knowing that other people have the same needs I do, but I'm not helping them. I want to want to put in the effort to polish and package my projects so that they work for other people. But I don't, so it's just for me.

Here are a few examples:

Physical Therapy Timer

I started having shoulder pain a few years ago. Physical therapy was the best option for me, and it helped a lot. But PT is also a lot of time and effort, every single day, to keep track of the exercises and do them properly. The hospital gave me an app to use to do the exercises at home, but it was sort of buggy. Also, I had particular opinions about how the timer should work, because it's very frustrating to have to fiddle with the app while also picking up weights and standing in strange poses. Also, I wanted to be able to change the exercises without having to call a doctor. Also, I wanted it to have sound effects!

So I wrote a simple Typescript web app ("simple", hah) to serve into my phone's web browser. For the first version (okay, there was never a second version) I hard-coded my PT regimen in Typescript. Ugly! But good enough!

I've since made many improvements to the app, based on what I've learned from daily usage. It now supports multiple regimens, several kinds of rep counting, useful navigation, and it logs results to my personal fitness spreadsheet. Clearly something others would find useful!

Unfortunately, I usually reach for "web page" as an expedient prototyping and development platform, because that's what I'm fastest at building. That's how I built this timer app: it's just a complicated web page. But that approach is usually incompatible with packaging an "app" for others. People expect an app in the app store, not a web page that gets evicted from phone memory whenever you blink your eyes. Web pages also cannot do mobile notifications in a way that would be useful here; for example, there's no support for showing a delayed notification from a background tab on mobile, even with user permission. Developing a native app would fix these problems, and it would certainly be nicer for others, and I do know how to do it... but since it's not easy, and not something I personally need, I haven't gotten around to it.

I do have an Android developer account and an Apple developer account, and I even pay their protection money and fill out their increasingly unreasonable inquisition forms to assure them I'm not a murderer, or worse: a competitor. But since the hoops they make me jump through are onerous, the timer already works for me, and I'd rather eat staples than wait for another Apple app review, this app is just for me.

TwaRSS

Before the 2020s I found Twitter to be worthwhile because my friends posted there. And yet it became increasingly unbearable due to the rising user hostility of the official Twitter app. I also disliked Twitter's timeline view, because it created a perverse incentive for a few people to post a lot so that viewers who only read the recent stuff are more likely to see their content. Those few posters' mountains of frivolity would drown out my one-post-a-month friends. This felt unfair and exhausting to me, and I wanted to fix it.

I solved these two problems by obtaining developer tokens for the Twitter API, and building an authenticated RSS repeater service that forwards my friends' posts out of the walled garden. The RSS repeater compiles each person's posts as a separate feed associated with their username. Then I use an ordinary RSS reader app to read Twitter person-by-person instead of in time order. I found this reading style to be wildly superior. In hindsight it's hard to express how miserable social media was making me, and how much this change improved my life.

I also enjoy how the RSS reader gives me a little histogram of how much each person is posting, and how many posts I haven't read, so I can adjust my time investment and reading speed. This lets me feel sure that I haven't missed my one-post-per-month friends.

Later it was easy to add RSS drivers for Mastodon and Bluesky and integrate them into my existing reading workflow. Now I can read people from across multiple social media services in one place, which insulates me from disruption when the thundering herds stampede from one fad walled garden to the next. It's great, and I still use it heavily every day.

The bad news is, although my design was expedient and effective, it isn't particularly secure or scalable. These APIs aren't designed for a nice OAuth flow, and many RSS readers don't participate in OAuth correctly anyway. So TwaRSS stores my private API credentials for each service, fetches the posts I want for itself as a daemon, and exposes the data to a barely-authenticated RSS feed. There's a token attempt (har) at security via a bearer token which TwaRSS checks, so the service isn't vulnerable to outright scraping. But it's also hardly secure, since the bearer token doesn't rotate, and anyway it's being handed to an untrusted RSS Reader app. I think there are specific readers on some platforms that I could rig up to handle an OAuth-authenticated feed, but the particular Reader I wanted to use can't do it. Hence, bearer tokens.

Even if I did invest time into solving the productization and security problems, this service would be shut down by the walled garden corporations anyway. Twitter prohibits using their API to create alternative reading experiences outside their officially built surveillance advertising app. So it's just for me.

Photoferret

When I finally replaced my swelling 2016 MacBook Pro with one of the new Apple Silicon M1 MacBooks in 2021, I was pretty delighted with it except that it wouldn't run my favorite photo management software, Picasa. Like any good software engineer who suddenly loses access to a mature tool that probably took thousands of hours to create, I thought to myself, how hard could it be to rewrite Picasa? Over the next several years I taught myself Electron and built a (by now) fairly mature desktop photo manager replacement app: Photoferret.

I've worked on Photoferret for thousands of hours, and it can now do a ton of useful stuff. I use it every day, as do about five of my friends. Unlike the PT timer, I actually did put a lot of work into packaging and distribution... but not productization. Which is to say: I think it's a fairly complete photo manager if you happen to need what I need: local storage, duplicate finding, video watching, folder trees, good performance on Apple silicon for 50,000 photos and videos, and many other things. But it doesn't do a few things that most users I've talked to want: there's no cloud service integration, no mobile app (see above), and quite purposely no AI Anything.

Sharing potential is also limited by my technology choices. It's tech stack is "the web" again, in the form of Electron. Actually, Photoferret started its life as a command line node.js app which would serve its GUI as a web page on a localhost port. As I worked on it more, I became suspicious that I was re-inventing Electron (yes) and that switching to Electron would be easy (no). Now it's a very well tested Typescript codebase, and Electron has served me okay.

To be clear: Electron sucks. Still, I consider myself an Electron Apologist because for all its warts, it did a wonderful job of flattening the enormous learning curve of Apple's walled garden, and as a bonus gave me Linux and Windows support for cheap. Are Electron apps great? No. Are they way better than not existing at all? Yes. You might say, "Why not Tauri" and to that I say, debugging every platform's webview is much more work than targeting one known, statically linked Chromium renderer. Electron beats Tauri on this score, because browser incompatibilities are numerous when you try to do something complex with the web at high quality. (I'd kindly ask that you not comment at me with claims to the contrary. This is a rainbow I have tasted very thoroughly in my day job.)

Because I chose web tech, Photoferret's architecture contains nothing to make it easy for me to extend the functionality to Android or iOS, which is what most people want over native desktop apps these days. That would be a giant rewrite, so realistically I doubt I'll ever build a mobile app. It's already been way more work than I wanted to invest in "a little tool for my photo collections".

Unfortunately it also has some Linux-specific bugs I haven't fixed caused by Ubuntu's dubious "App Armor" system, and a bug in libvips. I haven't fixed these mostly because it works well on my Mac and I don't have a good Linux test machine. It's a real shame because I think unlike Mac or Windows, Linux users have fewer choices for a competent photo manager like Photoferret. And as a group I suspect Linux desktop users are more interested than average in avoiding cloud-managed private data. I definitely can fix these issues, I just haven't gotten around to it.

So yes, I would love it if you would check out the tour video and give Photoferret a try... but you'll likely have needs it won't meet. Most people probably do. It's probably just for me.

And many others

These are only three examples of software I feel I ought to share, but haven't. Other examples are even more embarrassing, like: I made a custom data logger app for my body weight using some Google Sheets APIs and Typescript. Our household has a markdown-based cooking recipe database that we maintain just for ourselves. I routinely write solvers for video games I'm playing, including the Sigmar's Garden puzzle from Zachtronics where I suspected the board generator had a bug in it so I trained a vision DNN to encode the game screen and verify that every board was solvable. (Writing a solver is how I show my love for puzzle games!) Oh and I wrote my own password manager... the less said about that, the better. These were useful tools, and I'm sure other people have these needs too. But I never found the time to polish and share them at a quality level I can stand behind.

Good tools for me, but not for thee

Recently I've felt increasingly like the apps, devices, and services being offered broadly to the general public are getting worse and worse. Now that silicon valley has its hooks in everyone, it has turned to grimly exploiting us through price hikes, dark patterns, and other enshittification. As technical professionals, we have the know-how to skip the dark patterns, make choices which preserve our money and privacy (though usually in exchange for complexity and inconvenience), or just build our own. Most people can't do this, but we can. When we solve problems for ourselves, wouldn't it be nice if we could easily share our solutions with everyone else?

But for reasons good and evil, I think sharing our work is still too hard. App development seems intentionally incompatible between Windows, Mac, iOS, and Android. The gaming industry has tools which go further toward leveling the cross-platform playing field, but they take their own pound of flesh. Web pages are a nice exception to this lock-in problem, but deliver-once-run-everywhere to browsers hits its limits on more advanced capabilities.

I think this is improving, but it's slow going. In Europe regulators are making moves, but where I live in the United States things are going slower. The walled gardens and corporate choke-holders remain powerful. Publishing and supporting an app is not just hard work, but might be prevented if you cross corporate interests. Even open-sourcing our code to help other programmers has now become fraught. Photoferret is open source, but it's not on github because I don't want to see its license violated by feeding it into a large language model to benefit corporations who are actively destroying the climate and harming society.

I'd happily share more of my work if it were easier and safer. But for now, it'll have to just be for me.