May I suggest we start looking at this issue in terms of performance categories, starting with safety-critical software as an example?

Imagine, for a moment, a fly-by-wire jet (one where all controls transmit signals electronically, not mechanically) that uses Windows 95 as the basis of its flight-control software. If Windows BSODs in flight, everything stops working, and the plane becomes a very expensive hole in the ground.

No insurance underwriter would cover that plane. The odds of failure are too high, and the cost of failure is too great. You can build equivalent examples for heart-lung machines, radiotherapy machines (can you say Therac-25?), countless industrial control systems, and an ever-increasing amount of automotive electronics.

Nobody uses Windows (or any COTS operating system) for those devices, because all the commercial-off-the-shelf vendors state quite clearly that their software is not adequate for safety-critical use.

So there's our starting point.

Now let's talk about uptime: the traditional notation for uptime is the N-nines rating. A 3-nines system is one that guarantees 99.999% uptime (roughly 5 minutes unscheduled downtime per year). A 5-nines system is one that guarantees 99.99999% uptime (~5 minutes down per 100 years).

Insurance companies could set their rates based on an N-nines rating for various desirable qualities: uptime, data integrity after failure, resistance to external compromise, amount of data exposed in the event of compromise, likelihood that one compromised system will be used to compromise others, etc. Those numbers don't need any buy-in from vendors, insurance companies could base their initial figures on educated guesses, then refine their ratings based on what they have to pay out on the claims they receive.

In that environment, it wouldn't take vendors long to announce N-nines ratings for certain products in certain configurations. It would be a selling point: better software == lower insurance rates. Once they do, that promise will be built into the EULA, and customers will be able to sue vendors for failures above the announced rate.

Once that happens, customers will be able to compare the various insurance rates to the cost of maintaining a given rating. If a 5-nines system drops to 0-nines unless you buy new hardware every year and install an average of three patches per month, customers will probably find it cheaper to pay the 0-nines insurance rate. Then they'll quote the exact figures involved to the sales rep when it's time to renew that software license.

IMO, that would be a fairly balanced system. Insurance rates would be based on actual performance, as measured by the carriers who pay out on claims. Apache and ssh will be rated on their actual performance in the field, right next to the corresponding commercial products. Vendors will be liable for any promises they actually make, but won't be subject to state-imposed rules about what constitutes 'good' software. Customers will gravitate to whatever configuration gives them what they want for the lowest cost. Customers will also find themselves liable for any unpatched servers or ignored security warnings, and will start learning to figure the TCO of running acceptably secure and reliable systems.

The fallout for Perl hackers will be a need to adopt some 'no guarantees unless otherwise stated, and yes this may ruin your insurance rating' language, and a fee schedule that reflects the value of software that offers a higher rating.