Backward compatibility, even for settings, has real costs

July 27, 2024

When I wrote about how I felt GNU Emacs configuration bankruptcy was inevitable in the longer term, one of the reasons was that Emacs configuration settings have changed over time (and will change more in the future), so that your old way of configuring something (like the C indentation style) would have to be updated periodically. One reaction to this is to say that open source software should keep backward compatibility for such settings. Unfortunately and as usual, such backward compatibility would have real costs; it would effectively act as a tax on development.

If you promise backward compatibility for settings, you must devote (programming) effort to mapping old settings to the new behavior and perhaps the new settings. Where there's no exact equivalent of the old setting's behavior, you may have to add code or additional (new) settings to synthesize that behavior, or materialize it if someone ever asks for it. Or you can only imitate the old setting value imperfectly, but then (some) people will complain. All of this takes work, especially if the setting is controlling some old behavior and old code that you're trying to move away from.

Open source software has finite time to spend on development (and increasing usage doesn't necessarily scale up the time available the way it can for commercial software). So the more backward compatibility you maintain, the more of your development time goes to that, and the less you're moving forward. And all of this is for something that you certainly hope fewer and fewer people are using over time, with new users and some number of old people moving to your current system of settings.

It's not surprising when large software like GNU Emacs doesn't preserve backward compatibility in settings, especially over the long term. In fact, I'd go further than that; it's a good thing when open source software doesn't attempt to do this if it's at all difficult. I'd much rather see limited resources going on improving the project and moving it forward rather than letting me not modify my .emacs for another year or three.

(Much of this applies to backward compatibility in general, at least in straightforward software that people use directly. Operating systems, libraries, and similar infrastructure things are somewhat different for reasons beyond the scope of this entry.)


Comments on this page:

So the more backward compatibility you maintain, the more of your development time goes to that, and the less you're moving forward.

This is a deceptively attractive argument that I’ve seen a lot. Taking a less local perspective, this can easily be argued the opposite way: the less time you spend maintaining backward compatibility in a single place upstream, the multiples more time everyone downstream has to spend maintaining up-to-date-ness in their code instead.

Of course resources available for all this are not equally distributed, nor are they (generally) fungible or redistributable (much less easily so), which makes the calculus complicated.

By Joker_vD at 2024-07-31 11:14:42:

the less time you spend maintaining backward compatibility in a single place upstream, the multiples more time everyone downstream has to spend maintaining up-to-date-ness in their code instead.

Well, yes, but those "everyone downstream" are not you, so their time wasted is not your time wasted, which means you don't have to account for it. And if they try to make you to account for it, you can always retort with "check you privillege" and old adages about being grateful for the work done on open source, and how they could fork it if they don't like it.

By cks at 2024-07-31 11:51:02:

As Aristotle Pagaltzis notes, upstream time and downstream time aren't directly comparable because you can't do the same thing with them; only the upstream can develop the project and move it forward. In this sense it doesn't matter how much downstream time is spent on keeping up with upstream changes. The upstream may want to consider the time impact, if only because it affects how many people use the project at all, but that's it. If backward compatibility reduces upstream development too much, it has to go or the project effectively dies.

('Too much' is a subjective judgement made by the project's developers, because they are doing the development work.)

Written on 27 July 2024.
« The uncertain possible futures of Unix graphical desktops
Our slowly growing Unix monoculture »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Sat Jul 27 22:47:55 2024
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.