The projects I did not finish
Unfinished projects are scattered across my machines. Some hold a few files and a note about what the thing was meant to do; others have a build system, a task list, and months of work behind them.
Sometimes I open one of them, I read the code, look at the notes, and try to remember what I wanted. The goal usually comes back. I can follow the decisions and see what I was about to do next.
The feeling that started the work does not come back with it.
But that's not unexpected. The code is mine and I can read it. The problems have not grown harder, and I know more now than I did then. Returning should be easier than starting, yet somehow it is not.
For about six months I worked on bringing newer Firefox features to PowerPC Macs on Leopard. The base was TenFourFox, Cameron Kaiser's port that kept Firefox alive on hardware Mozilla had dropped aeons ago.
I started because of the iBook G4: I wanted a browser that could reach a little further into the web than anything else on that machine.
Some of it worked. I got some of the features I wanted into the browser, and for a while that was enough.
The code was the problem, and its size was only part of the reason. Mozilla's tree carries years of decisions made for reasons I did not know at the time (and still don't know), and TenFourFox carried those decisions plus the work of keeping PowerPC alive. Each one made sense to somebody, yet learning why took most of my time.
I like order in a project; I want the tasks recorded and a structure I can hold in my head. A tree that size does not give you that. You learn where things are by fixing them, and the knowledge stays in your head.
I could fix things. I could add a feature, spend an evening in the browser, and come out with something that worked. Then I looked at the rest of what I would have to keep working, and I stopped.
It was not just a decision to quit, I noticed one evening that I had not opened the tree in a month, and that I did not want to. I respect that project more now than I did before I worked on it. Cameron Kaiser kept it alive for years after Mozilla had stopped supporting it, and that is a longer job than the one I did. And I have not gone back.
Rime is the other case. I have worked on it for more than ten years, with long pauses and stretches where nothing else interested me.
I started because I wanted to see a computer wake up. The bootloader gives control to the kernel, the kernel builds the first page tables, the first interrupt arrives, and then a program runs on its own. I wanted to know how each step worked, and then how memory could be shared and how two tasks could talk.
The questions were easy to ask (aren't they always?). Finding the answers took years.
The kernel grew. Scheduling, address spaces, message passing, filesystems, drivers, networking, and a graphical interface came one at a time, each with problems I had not known about when I started.
But every part of Rime exists because I put it there. I know why a service owns a resource and where to look when it misbehaves. That does not stop me from getting it wrong. I have spent nights on a failure that happens once in twenty runs, or fifty runs, followed the logs through the kernel and the servers, and found that my first idea was wrong. Sometimes the bug is a decision I made years ago and forgot.
I keep going because the system is mine, and I can change any part of it that stops making sense. I can drop a subsystem the week I stop believing in it, and I can build the next thing because I want to know how it works.
Rime runs on a Nokia Booklet 3G, so its hardware decides much of what Rime needs. I can support more machines when I want to, but support for its own sake would make the system bigger without making it better. And, why support more machines, I only have three, each with its own purpose.
At some point Rime became useful. I cannot name the specific version: I remember opening Codeine, Rime's editor, on the Booklet, writing a file, and saving it, and then realizing I had not booted another machine to check anything.
Now the Booklet runs the desktop, the network, USB, and the programs I use. It has obvious holes and obvious issues. I have written the drivers for the hardware I own, and skipped features I have no use for. I could write an xHCI driver, but for what reason? It's not like the Booklet has heard of USB 3.0. What is there does what I need.
I write these pages on Rime, Nordr builds the site, a webserver on the same machine serves it, and the Booklet answers requests from the LAN. When a page loads, the bytes go through the socket and the filesystem before they leave. I wrote each one of those parts, and when one of them breaks (and it will), I can follow it.
I used to think an unfinished project was a debt. Now I am less sure: a project that sits does not ask for anything. The code stays where I left it, though the world around it keeps moving, and that movement is what makes a return expensive. Memory is finite anyway.
When I go back, I bring different interests. I can respect what the work was without wanting to continue it.
The Firefox port was something I wanted to make; I learned from it and then I stopped. I do not regret the six months, and I do not want to give it six more.
Other projects I remember less well. Some never got far enough to be useful; a few would take an evening to finish, and I have not spent that evening. I keep them anyway. They are a record of what I was thinking about, and I like having it.
Maybe one becomes relevant again. I might open a directory in five years and find that the old question has a new answer. If that never happens, the directories can stay.
Rime sits on the Booklet with its own list of unfinished work. I find something to fix most weeks, and the list grows. I once wrote that Rime only needed to be interesting. I have not had to revise that, and the Booklet is serving the page you are reading.
