2024-01-04
'Unmaintained' (open source) code represents a huge amount of value
I recently read Aaron Ballman's Musings on the C charter (via). As part of musing on backward compatibility in new versions of the C standard, Ballman wrote:
[...] I would love to see this principle updated to set a time limit, along the lines of: existing code that has been maintained to not use features marked deprecated, obsolescent, or removed in the past ten years is important; unmaintained code and existing implementations are not. If you cannot update your code to stop relying on deprecated functionality, your code is not actually economically important — people spend time and money maintaining things that are economically important.
To put it one way, I disagree strongly with the view that 'unmaintained' code is not valuable or important. In the open source world, I routinely use a significant number of programs and a large amount of code that no longer sees meaningful changes and development. This code may be maintained in the sense that there is someone who will fix security issues and important bugs, and maybe make a few changes here and there, but it is not 'maintained' in the sense that I think Ballman means, where it undergoes enough development that changing away from newly deprecated functionality (in C or any other language) would be lost in the noise.
(This code has 'value' in the sense that there's a community of people who are (still) using the software, often happily and by choice. Often these are relatively small communities, although not always. If there's no community still using the code, then it's mostly unimportant.)
Some of this open source code is genuinely more or less finished; its authors don't have any particular features they want to add to it. Other amounts of this open source code has fallen out of favour, with no one left behind that is interested in active development to move it forward, but potentially with plenty of people who derive value from its current working state. You can probably name projects for each camp.
(An extremely relevant example of the second case is X. People are quite aggressively not doing any further development of X, and they're happy to tell you about it. At the same time, a great deal of things still run on X.)
Making a future version of C (as an example) unable to build those code bases is effectively branching the language, in much the same way (although probably to a lesser extent) than the Python 2 versus Python 3 split. If C compilers fully support the old version of C, everything is probably reasonably fine; even though the language has branched, old projects can continue to use the old language forever. If C compilers start deciding that they want to drop the old version of C because it's been a while, we are not so fine.
PS: This has also come up in the case of Go. Old Go code itself still compiles and works fine, but the Go build environment has changed significantly enough that old code only builds through what is basically a hack in the main Go toolchain. Based on personal experience, I can tell you that there are a number of Go programs out there in the world that have not had even the minimal update to build using Go modules, but which are likely still used.