3 ms·
I like this approach more because it incentivizes fulfillment of the risk interface without precluding flexibility in how that might be accomplished. I agree wi
by yowlingcat 6y ago
I like this approach more because it incentivizes fulfillment of the risk interface without precluding flexibility in how that might be accomplished. I agree with your conclusion that a significant factor in improvements in safety have been seen in other industries with this approach -- align the incentive of not externalizing the risk and I think you'll see a lot of the misbehavior disappear because it's no longer profitable.
- varispeed 6y agoThis is not a bad idea, but I am thinking whether this will only shift who is making money off the software from one big corporation to another. Maybe a combination of both - royalties to ensure developers are paid and insurance to ensure big corporations become conscious of their responsibilities.
- rjknight 6y agoThe ultimate point of the insurance market is to provide an incentive for quality. Use of components which the insurer regards as low-risk will be cheaper to insure. What would the insurer regard as low-risk? Typically, they would use two things: 1) Past experience - have they seen this piece of software regularly exploited? 2) Formal assessment in an underwriters' lab - do relevant experts consider the software to be well-constructed? Here open-source software has a real advantage, because the underwriters can review the source code directly, or pay others to do so. They have access to any automated tests and code coverage assessments, and so might assign a lower risk score to a project with more tests. They might even assign lower risk to projects written in languages that are known to produce safer code, so with all other things being equal a Rust codebase would be cheaper to insure than a C++ one. This is entirely compatible with a system of bounties or rewards for anyone who moves the project in the direction of safety and high-quality maintenance. By concentrating the risk associated with poor software quality on the insurer, we get around the problem where many different companies use the software but are unwilling to pay for its maintenance. The insurer has a greater incentive to care than they do, and so would be more willing to pay developers. I admit that this is a back-of-a-napkin sketch, but the incentives do seem to line up correctly.