In any large deployment sooner or later someone is bound to ask, "why change something that works?".
Sometimes things are a lot simpler than they are assumed to be. In the immortal words of the Joker when asked his proposed solution to a seemingly complex problem, he said: "It's simple. Kill the Batman".
The answer to "why change something that works" is "because you fucking have to!"
At least if you're talking about large scale deployment of software.
The fundamental issue here is that software changes, evolves and doesn't stay static.
The statement "works" is very much relative. You claim it works today within acceptable tolerance, that's all well and dandy. How about tomorrow? Surely the definition of "works" depends on the details and what someone requires of a system changes over time as needs change.
"But my requirements are quite specific and I don't intend to change them!" I hear you saying. The fun part comes from the fact that you're not fully in control of the definition of a working system.
Sometimes things are a lot simpler than they are assumed to be. In the immortal words of the Joker when asked his proposed solution to a seemingly complex problem, he said: "It's simple. Kill the Batman".
The answer to "why change something that works" is "because you fucking have to!"
At least if you're talking about large scale deployment of software.
The fundamental issue here is that software changes, evolves and doesn't stay static.
The statement "works" is very much relative. You claim it works today within acceptable tolerance, that's all well and dandy. How about tomorrow? Surely the definition of "works" depends on the details and what someone requires of a system changes over time as needs change.
"But my requirements are quite specific and I don't intend to change them!" I hear you saying. The fun part comes from the fact that you're not fully in control of the definition of a working system.
Sooner or later, for whatever reason, you will be forced to upgrade.
One overriding reason to do so might be security. There are a lot of security advisories out there that say "this vulnerability affects releases from the past 10 years, upgrade to the latest version x.y.z released 2 hours ago to fix the issue". It doesn't usually say "this vulnerability affects releases from the past 10 years, but we've helpfully provided a point release to every release from the past 10 years that fixes this problem and you can upgrade to". Security advisories don't say this and developers don't do this because it would be a waste of resources to do this.
If you've been labouring under the assumption that things that work shouldn't be upgraded and then suddently hit an overriding reason to upgrade anyway, it usually results in one heck of a firefighting season when the accumulated technical debt is demanded to be repaid with the accumulated interests immediately.
Open Source software exists as a community effort. The open source developers are a bunch of jolly good happy campers who offer you the chance to use their software and come along for the ride, but if you then decide to camp down and happen upon nightfall next to a disreputable part of a forest and get attacked by a bunch of thugs, then it's not the developers fault that you've parted ways.
Remember, a particular piece of software might work for your purposes at a given point in time, but if you want to ensure that it continues to work in the future, you have to remember that the communities and the software environment built up by those communities do not remain unchanged. They move.
The smart choice is to remain within the community and not get caught in the forest at night. By doing that, you're foresaking all the benefits being part of a community can give you.
Good luck trying to get help fixing a problem with a really old piece of software for example. It is likely that the problem is already fixed in a new version, but even if not noone will willingly work on the old version without a substantial motivation to do so. Remaining in one place excludes you from benefitting from new features, bugfixes, performance enhancements, general advice and the ability to pay someone to fix something.
Looking at things this way makes it obvious that the choice isn't between upgrading or not upgrading, but in setting the terms of how to upgrade and when. It can be done as a routine operation, in a planned and dependable way, receiving the benefits of doing so or it can be done in an unplanned and haphazard way when an overriding reason manifests.
The routine part is important aswell, not just to minimize the fuss from an upgrade, but from a software development perspective aswell. Software development is rarely revolutionary, but it is evolutionary. It is an iterative process. There is no magic cure or "oh, I'll just upgrade every 2-3 years to a version that has the features and then I'm safe!" mindset.
For example suppose that you've been running an old kernel, say 2.6.16.x and you're interested in knowing which newer version improved on tcp congestion avoidance algorithms and throughput. In truth, practically all of them. 2.6.19 made CUBIC v1 the default, then CUBIC went through a series of optimizations and revisions to arrive at v2.3 in 2.6.29 as of this writing.
There are of course costs involved in keeping things up to date. Proper procedures have to be established and testing needs to be performed because things can break in an update. However, it is a lot more convenient to have things break during a planned deployment of new software, with the possibility of stepping back than in an unplanned situation with no chance of going back.
Community perspective
On the community side of things and specifically in the Perl development community there is sometimes talk about the DarkPan, the unseen corporate codebase. The argument goes, that deprecating something or dropping support for an old version cannot or shouldn't be done because it might break a large amount of code in the DarkPan.
It is the corporate side of "stability through no change" myth that feeds the DarkPan argument. It follows, that if you accept the argument I've outlined above, then referring to the DarkPan is invalid aswell. Why should a development community hold back on deprecating things and breaking compatibility with very old versions of software, for the sake of future clarity and the sake of up to date users, just because some corporate type out there was irrational or irresponsible enough to get stuck in the past somewhere back along the way. I feel that calling "upgrade freeze" irresponsible is warranted, since keeping backwards compatibility for very old versions of software implicitly means that a community supports software with known security vulnerabilities through not explicitly advising people not to use them!
Perl has, luckily, only a small number of security vulnerabilities compared to other software, but 5.6 still suffers from multiple serious issues from the security perspective. Exerting an effort to keep CPAN modules or features compatible with 5.6 or referring to the DarkPan as a reason not to deprecate/remove some misfeatures from new Perl 5 versions makes no sense.
It is the case of worrying about people having a rough time to upgrade who have shown no indication of wanting to upgrade in the first place, nor having the wisdom of making the upgrade process as smooth as possible for themselves. If inevitable pressures force some of those DarkPan users to upgrade their codebase eventually, they need only to look in the mirror for the cause of any inconvenience they experience.
One overriding reason to do so might be security. There are a lot of security advisories out there that say "this vulnerability affects releases from the past 10 years, upgrade to the latest version x.y.z released 2 hours ago to fix the issue". It doesn't usually say "this vulnerability affects releases from the past 10 years, but we've helpfully provided a point release to every release from the past 10 years that fixes this problem and you can upgrade to". Security advisories don't say this and developers don't do this because it would be a waste of resources to do this.
If you've been labouring under the assumption that things that work shouldn't be upgraded and then suddently hit an overriding reason to upgrade anyway, it usually results in one heck of a firefighting season when the accumulated technical debt is demanded to be repaid with the accumulated interests immediately.
Open Source software exists as a community effort. The open source developers are a bunch of jolly good happy campers who offer you the chance to use their software and come along for the ride, but if you then decide to camp down and happen upon nightfall next to a disreputable part of a forest and get attacked by a bunch of thugs, then it's not the developers fault that you've parted ways.
Remember, a particular piece of software might work for your purposes at a given point in time, but if you want to ensure that it continues to work in the future, you have to remember that the communities and the software environment built up by those communities do not remain unchanged. They move.
The smart choice is to remain within the community and not get caught in the forest at night. By doing that, you're foresaking all the benefits being part of a community can give you.
Good luck trying to get help fixing a problem with a really old piece of software for example. It is likely that the problem is already fixed in a new version, but even if not noone will willingly work on the old version without a substantial motivation to do so. Remaining in one place excludes you from benefitting from new features, bugfixes, performance enhancements, general advice and the ability to pay someone to fix something.
Looking at things this way makes it obvious that the choice isn't between upgrading or not upgrading, but in setting the terms of how to upgrade and when. It can be done as a routine operation, in a planned and dependable way, receiving the benefits of doing so or it can be done in an unplanned and haphazard way when an overriding reason manifests.
The routine part is important aswell, not just to minimize the fuss from an upgrade, but from a software development perspective aswell. Software development is rarely revolutionary, but it is evolutionary. It is an iterative process. There is no magic cure or "oh, I'll just upgrade every 2-3 years to a version that has the features and then I'm safe!" mindset.
For example suppose that you've been running an old kernel, say 2.6.16.x and you're interested in knowing which newer version improved on tcp congestion avoidance algorithms and throughput. In truth, practically all of them. 2.6.19 made CUBIC v1 the default, then CUBIC went through a series of optimizations and revisions to arrive at v2.3 in 2.6.29 as of this writing.
There are of course costs involved in keeping things up to date. Proper procedures have to be established and testing needs to be performed because things can break in an update. However, it is a lot more convenient to have things break during a planned deployment of new software, with the possibility of stepping back than in an unplanned situation with no chance of going back.
Community perspective
On the community side of things and specifically in the Perl development community there is sometimes talk about the DarkPan, the unseen corporate codebase. The argument goes, that deprecating something or dropping support for an old version cannot or shouldn't be done because it might break a large amount of code in the DarkPan.
It is the corporate side of "stability through no change" myth that feeds the DarkPan argument. It follows, that if you accept the argument I've outlined above, then referring to the DarkPan is invalid aswell. Why should a development community hold back on deprecating things and breaking compatibility with very old versions of software, for the sake of future clarity and the sake of up to date users, just because some corporate type out there was irrational or irresponsible enough to get stuck in the past somewhere back along the way. I feel that calling "upgrade freeze" irresponsible is warranted, since keeping backwards compatibility for very old versions of software implicitly means that a community supports software with known security vulnerabilities through not explicitly advising people not to use them!
Perl has, luckily, only a small number of security vulnerabilities compared to other software, but 5.6 still suffers from multiple serious issues from the security perspective. Exerting an effort to keep CPAN modules or features compatible with 5.6 or referring to the DarkPan as a reason not to deprecate/remove some misfeatures from new Perl 5 versions makes no sense.
It is the case of worrying about people having a rough time to upgrade who have shown no indication of wanting to upgrade in the first place, nor having the wisdom of making the upgrade process as smooth as possible for themselves. If inevitable pressures force some of those DarkPan users to upgrade their codebase eventually, they need only to look in the mirror for the cause of any inconvenience they experience.
Leave a comment