Embed Notice

@raven667@hachyderm.io @lispi314@udongein.xyz @chris__martin@functional.cafe @dalias@hachyderm.io There's a difference between what's theoretically possible and what is the normalized practice. Sure, theoretically, for source-level compatibility, your POSIX-compliant C89 code from the year 2000 will still run in 2024 in theory. For binary compatibility, it has even been demoed it's NOT that bad at all on GNU/Linux, you can still run the original GIMP 1 binary, if everything's packaged carefully with the correct tricks.

It misses the point, which is the cultural preference that I was talking about, I don't even care about binary or source compatibility as they're simply technical means on an end. If you really want a "maintenance mode" project, you don't even need that - you can just write a self-contained C89 project with strict standard comformance and use a small sets of carefully selected stable dependencies (ncurses or Tcl/Tk will work until the end of time). As long as you treat it as a "finish" project, and don't keep adding features to it, the maintenance required is likely minimum, you probably only need to update it once a year with a small patch to keep it running.

But this is not what's going on. The reality of FOSS is that a project's devteam and goals will probably change several times over its lifetime, and the people, driven by technical challenges and the norm of expanding a project to fit your own need, will keep throwing dozens of extra features into the codebase, rewriting the business logic many times over, for for an increasing number of niche uses. Within some year it will be a completely different project, and another few years later there will be 3 competing forks, and 1 year later all will be obsolete as someone wrote something else.

Unless it's a low-level or niche tool, it will be extremely rare for the devs to declare that "The project is officially complete and is in maintenance mode, only security and fixes will be added after this point, all feature requests and patches will be rejected!" If someone does it, it will immediately seen as dead and be forked by the community. In this grand scheme of things, few care about compatibility.

The free software community culture expects a project to constantly in development, because people know they have the power to change it for the (subjective) "better". The mode of thinking is much different in the proprietary Win32 software world - those users have a different set of expectations - which is frozen upon release. Thus I said perhaps "minimum maintenance" projects is something the community should explore.