Open source and the problem of pure maintenance

November 14, 2016

One of the things that people using open source often wish loudly for (via) is software that's stable and only gets bug fixes, including security updates, with no other changes at all. Oh, and they want this for free as part of an open source project.

As you may have guessed, there is a fundamental problem with this. Indeed it is a classical fundamental problem in software development in general, namely that doing only maintenance is boring and very few people want to do it (especially for free, such as with open source software). This is why it's really quite hard to find anyone who does a good job of maintenance, especially over the long term and most especially for free. There are people who will provide you with well maintained systems that stay carefully stable for years, but generally they want money (often a fair amount of it).

But why is maintenance boring? Well, I have a theory about that. One of the problems with maintenance is that it consists of not doing things. If the software is working, people want you to not touch anything. If the software is not working, people want you to touch as little as possible and generally to make the smallest change possible. Almost all of the time, change is risk and instability and the people who are agitating for 'stable software, bugfixes only' don't want any of that. Even internal restructuring will make them unhappy with you, and don't even think of adding new features.

(Some people will say that they'll accept new features or performance improvements. Generally they turn out to be either wrong or demand impossible standards, like 'sure, new features and better performance, but absolutely no chance anything old breaks'.)

In the commercial software world, you can sometimes get what you want here by paying people money (not always, though). In a pure open source world with no money changing hands, you're in a quest for extremely rare people and you aren't likely to find them, especially in projects which are not basically finished (and most of them aren't).

(Commercial software would like your support and maintenance money, but they would also like the money from new customers and people making major upgrades. Getting the latter often means changing and improving the software, whether you like it or not.)

Comments on this page:

By KC Marshall at 2016-11-15 11:17:36:

There is also the possibility that you aren't seeing the stable software because there are so many exciting and new re-implementations shouting for attention. This was an interesting anecdote

The above comment reminds me of TeX:

Knuth has declared that he will do no further development of TeX; he will continue to fix any bugs that are reported to him (though bugs are rare). This decision was made soon after TeX version 3.0 was released; at each bug-fix release the version number acquires one more digit, so that it tends to the limit π (at the time of writing, Knuth’s latest release is version 3.1415926).

Per the above link about Text::Template, it actually may be a good idea to have bi/annual "releases" where the only thing that is done is bump the version number.

By Christopher Barts at 2016-11-15 15:42:17:

It's an argument for subscription-based software, if anything: If the only guaranteed revenue stream for a piece of software is selling new versions, the software will never be done. If people pay simply to use the software, the software can be done when it's done, and the company isn't losing anything.

Maybe you can call subscriptions "support contracts" if it helps you make the sale, but the point of stable software is that it doesn't need or receive support.

And, of course, subscription-based software is most easily done as Web apps, so you can actually revoke permission to use it for nonpayment. What happens to customers who rely on it after you go out of business, or go out of that business, and your websites go dark is not your problem: You're no longer in business, and/or no longer in that business, so they're no longer your customers.

Written on 14 November 2016.
« Why I believe native apps are not doomed by progressive web apps
Go's arbitrary-precision constants and cross compilation »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Nov 14 21:52:44 2016
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.