This series of articles (The Truisms) is aimed at imparting some of the things we find to hold true no matter the project one undertakes in the space carved out by our interests in Open Source and Free Software engineering. The first article in the series was If you don't know why you're doing it, you shouldn't be doing it

Previously we talked about how if you no longer want to use a project you wrote, you should give it to someone else who does use it and wants to maintain it. This brings us to the last thing I want to cover in this little series we have been enjoying for the past few months -- namely that since everything is changing (some things slowly, some quickly) if your projects stand still they will simply cease achieving their goals.

As with all rules, there may exist exceptions -- some software out there has remained unchanged for decades. Some people consider it "done", "perfect", "finished", while others simply think of it as "good enough". However, I consider such projects "stagnant", "dead", "uninteresting". Even if your project is, right now, perfect; it will not remain so.

Everything is changing around you. The operating systems your project is meant to run on will be changing, both at the fundamentals such as the kernel or filesystem, or simply in terms of the UIs people grow to expect. Baserock (a project I am privileged enough to be paid to enjoy working on) builds an entire linux-based operating system and no single component of the stuff we build has failed to be updated in at least some way in the last six weeks. Software which doesn't react to this ever-changing landscape will fail to work eventually.

In addition, people's needs change and evolve. Expectations of usability, security, overall functionality, documentation, (and a million other things) change over time, both in terms of individual users, and in terms of the overall userbase you attract to your project. If you have no plan to deal with issues these changes expose, no interest in fixing, maintaining, extending your project, then it will eventually be overtaken by a new upstart of a project which has the energy of interested developers behind it. Don't let this happen to your project while you still care about it.

A few years ago I wrote a program to extract entropic values from the noise in sound card inputs. I wrote this to get some entropy into /dev/random for a device I had which otherwise had a tendency to block because it had no randomness to draw upon for creating secure keys for ssh etc. This program did its job and worked fine for several years, but recently the APIs it was using turned out to be sub-optimal and were removed. Since I had no plan to maintain this software it simply stopped working and someone else had to do the work to fix it again. I realised that I wasn't using the program and that's why I had no maintenance plan, so I passed maintainership along to the person who fixed it. They may at least be more proactive about dealing with deprecated APIs. Interestingly I did still use the program, but on such an old system (that wasn't upgradeable in any useful sense) that I'd never noticed the issue. It wasn't that I was neglecting the program, simply that I had no plan for maintaining it on modern systems.

So, in conclusion, go to your projects list, which by now should be honed to only projects you have a reason to work on, that you know what you're doing to achieve your goals, that are in revision control and are pushed to a server, that are well tested and are backed up to protect against loss. All your projects should have ways to measure their performance and of course you should be actively using them yourself. So with all these limits in mind, your projects list should be shiny, it should be a glorious testament to your healthy and wholehearted commitment to quality, and as such you should very easily be able to write down what you will do to ensure that your projects keep working as time goes by. Your homework is, quite simply, to keep on top of that list, keep it at the high quality it has now reached, and continue writing new stuff which satisfies you, demonstrates your capabilities, and keeps on working.

Go forth, and engineer the future (so I don't have to).