Software bitrots.
Yes, it's a metaphor. Hopefully the little pieces of rust and semiconductors that hold our software don't actually rot (at least before we have backups), but change happens to our software like change happens to our physical artifacts, and we have to account for that change.
You probably know that you can get the source code for unsupported versions of Perl 5—say 5.004 or 5.6.0. You may not know that that software as released may not build on modern computers with modern toolchains. (Patches and workarounds exist.)
Although we'd like to pretend that software is immune to physical laws (except for those well understood properties of memory latency and speed of light issues, and sometimes those cosmic rays which flip single bits of memory and cause those bizarre once-in-a-lifetime errors we couldn't have coded ourselves, no) and that, once deployed, software will never need maintenance to keep running now and forever, things happen. A disk in your RAID needs replacement. The fan in your server fails. You must physically move a computer between locations. Someone tripped over a power cord to the cooling system.
Expecting you can deploy software once to a fixed, frozen configuration that will never, ever change is risky and naïve.
(You're welcome to take as many risks as you like. Be aware of them.)
Clever people have devised many strategies to mitigate these risks. They all have flaws. (Even virtualization has its problems: you must continue to demonstrate that your virtualization platform exhibits the same behaviors you expect—and that your provider doesn't scuttle the project.)
The most reasonable strategy I've seen is to acknowledge this risk.
I upgrade to new stable releases of Perl 5 soon after release because that gives me a two year window of devoted support for that release. Within that window, I have two years to test upgrading to new releases, to report bugs, and to perform any migrations necessary for my software.
The new standard of Perl 5 predictability helps greatly.
Similarly, I pay attention to CPAN Testers because my projects build on several layers. If Perl 5 is the core infrastructure, CPAN is the plumbing, and it's up to me and my teams to lay out the house and choose the fixtures.
Enough about architecture and construction. Let's talk finance. In specific, let's talk about how businesses grow. Apart from Silly Con Valley startup nonsense, a business is valuable because it brings in cash. A business is more valuable in the future because it will bring in more cash in the future. You can figure out the value of a business now by projecting how much real cash it will generate over its lifetime.
(I'll talk about that more in other venues; I don't have the announcement quite ready yet.)
A business can make itself more valuable in a couple of ways: selling more products or services (bringing in more money), cutting costs (keeping more of the money it brings in), or performing some weird financial manipulations (this is how grocery stores and Amazon.com work, as they lose money on many sales but more than make up for it with volume—and if you think that's an impossible non sequitur, you're not cut out for the financial industry).
A company has a couple of choices with what to do with the free cash it generates. It can pay that out to owners of the company in dividends. It can buy back its own stock to make each share more valuable (if it's a public company). It can invest in the business to make it more efficient or able to sell more (hire more workers, build a new factory, migrate to a faster network, whatever). Sometimes it must invest in the business just to stay in business (a semiconductor manufacturer builds a new fab to produce its new line of chips or an automaker retools a factory for a new car).
That last point is ferociously important.
A business can only survive if it brings in more money than it has to spend to make that money (or as long as someone's willing to dump money into that business until it reaches that point). If it costs you a hundred dollars right now to prop up a lemonade stand that will only bring in ninety dollars this summer, you're better off setting a $5 on fire and shuttering the lemonade stand. A business that isn't growing is suddenly worth less than it was before—otherwise you're far better off putting your money in something safer that is growing.
Here's the connection to software.
Ideally, our software gets easier to write over time. If we do our jobs well, designing the software to meet real needs and finding and fixing bugs and discovering the natural patterns which emerge from our code, maintaining our software should get cheaper over time.
... unless our infrastructure changes beneath us in unpleasant or undesirable ways. If Perl 5.18 gets a little faster and uses a little less memory and upgrading is effectively free (and Perl 5.16 worked out very well for me in that respect), it's all to the good. If Python 2.7 worked well for me but Python 3.3 requires me to switch from a mature and important library to something missing an important feature, I'm worse off.
If I relied on the Blub library and it suddenly went unmaintained and started to bitrot, I'd be in real trouble.
We who rely on an amazing ecosystem of free and open source software have an embarrassment of riches from which to select, but we also have an obligation. That ecosystem only exists because of investments of time and talent and interest and effort. Some of that comes from other businesses. Some of that comes from individuals. All of that together allows us to build amazing things we'd never be able to achieve on our own individually.
Yet we're more like the poor semiconductor companies and auto manufacturers and even municipalities who maintain public roads and utility systems who have to invest in keeping that infrastructure going, because software marches on and things that don't keep up bitrot.
You, of course, get to manage your own risks. Consider, however, what would happen when something you care about were to go away for good.
That's why my business contributes to the ecosystem. Sometimes the short-term cost is a little higher than merely taking from the commons and never giving back, but over the long term I really believe we'll all come out ahead.
Perhaps you will agree that the definition for "Good code" is simple "code that makes money".
This statement is fascinating though "Ideally, our software gets easier to write over time...maintaining our software should get cheaper over time." I havent been able to articulate this idea so succinctly.
So often i think management just cuts the money going to maintenance rather than training the staff to reduce costs themselves.
This dovetails in to my studies in the Toyota Production System very nicely.
The Toyota connection is deliberate! There are only two ways to increase free cash in business: increase revenue or cut costs. Once you start measuring the effect of software in terms of dollars, you have to follow that line of thinking to its logical results.
If development and maintenance get more expensive over time, something's very wrong.