Ubuntu Insurance?

This idea popped up in a completely different conversation and I haven’t explored the full dynamics of the idea and how it would play out legally but:

What if Ubuntu users paid into an insurance fund. The fund’s aim would be to record the primary software and hardware used by the customer and to employ programmers and QA people to ensure that this software and hardware works in the next release and with critical updates?

Payout would essentially be getting people in to fix problems if they cropped up.

This would be in contrast to the idea of paying individually for bugs to be fixed. Such as having bounties or pay only bug trackers.

The goal of course would be to collectively take responsibility for maintaining the code we have that makes our computers do amazing things. Make sure that this is sustainable and reduce the requirement for guides and “toxic workarounds” for sets of problems that crop up in releases.

Would you pay into such a scheme? Do you know users who would? Is there enough money in our ecosystem to really pay people to do a good job on fixing problems or are we just not big enough yet?

What are your thoughts?

13 thoughts on “Ubuntu Insurance?

  1. Hmm. Insurance as a concept is about the economics of aggregating and pricing collective risk. You pay in a little bit every month to hedge against a much bigger potential but low occurrence liability in the future and the insurance company coughs up money (reluctantly) when one of these rare large liability events happen.

    I’m not sure its the right model for what you want to achieve. First its not clear that there are relatively rare events that you are hedging against. Second it’s not clear what the payout model is when an event happens.

    How would such a scheme deal with “payouts” and make sure people who paid into the fund got adequate satisfaction in the next release?

    If the covered hardware and software works in the next release that people paid premiums for… no problem..the insurance broker in your scheme makes a profit for that release period and everyone goes about their day feeling good about paying for the piece of mind that the insurance premium brings them. But what happens if and when there’s a lingering issue for hardware or software that is not solved to the satisfaction of those who were paying premiums into the fund? Do they get a partial refund of their premiums?

    -jef

  2. The payout I guess is when things do go wrong _before_ the release, the broker can make arrangements (payouts) to people to get the problems fixed. It maybe a problem to have the fixer and the insurer be the same person, I haven’t played with the model enough.

    Of course if problems persist beyond the release, then the insurance would presumable have to decide if it covered making sure support was there to get issues resolved or just plain old monetary payouts to cover loss of time.

  3. Martin,
    One other thought. you might also need to price premiums for different hardware configurations differently as they represent different risk levels. Like how my flood insurance on my house is way way lower than the people with houses on the river front.

    Obviously people needing proprietary drivers represent a larger risk and might need additional insurance riders or pay a larger non-refundable “deductible” to become part of the pool.

    I think if there were latching premium paybacks for non-functional hardware written into the contracts you probably have a workable system. The insurance broker could even start out and only take contracts for specific hardware configurations and expand outward as the economics of this become better understood. You;d really have to price it cheap and plan on getting a lot of people with the same hardware to buy into it.

    I’ll talk to my household’s chief financial officer about it and see what she thinks. Given that she has me as in-house technical support already I doubt she’d feel compelled to buy into this sort of thing at any price point. But I’ll get her opinion on it more generally.

  4. This is beginning to sound like support contracts. You have your officially supported platforms that come at a base rate and then you have special contracts for things outside that scope that cost a bit more.

    And it would probably still leave folks like me out in the cold who might be willing to pay a little extra just to keep some existing function from being needlessly broken to encourage the use of some new feature instead. I doubt I could pay enough to get support for multi-open sound cards re-added to Ubuntu or to have someone un-cripple notification icons in Ubuntu if I found them more usable than the indicator/application menus.

    Instead, users will find out what the support system(s) is and buy that without paying for the ‘insurance’. You’re back to the same problem you have with selling support services for Free software. People who really like what you do might pay for it. The rest will still freeload.

  5. My problems tend to be with things other people don’t care about. I’m unlikely to do something like that unless *my specific bugs* get a degree of priority.

    I tend to view problems less like “Oh, it would be nice if my stuff worked” and more “Wow, this one bug is costing me $15 in productivity every week, I need it fixed yesterday.”

  6. Eddward: I could see how it could look like support, but it’s more like support before release without any call in or contact support.

    People will freeload I guess, but then they _will_ be at risk of having things fail. That’s why it’s insurance and not support.

  7. For most users, it would be an ongoing cost instead of the once-off cost you have with Windows. i.e. a disadvantage
    Companies already have paid support, so there’s no change for them.
    End result: no target demographic

    Working on an individual problems/costs basis would work better – each user might pay a small amount for any problems that they need fixed, and users could see how many others were interested in fixing the same problem so that it would be possible to pool funds. Changes would of course be merged with the main branch under the GPL
    That way, the important changes are made and users have more control over the process. Additionally, it only cost users to fix problems that they actually had issues with, as opposed to what the developer thinks was an issue.

  8. R: That very last point is exactly why that doesn’t always work. Sometimes the programmer really does know what is best to fix and sometimes you just need enough money to fix a set of issues.

    As for windows, Ubuntu can not be seen as just a cheaper or free from cost operating system. It’s not free, it was never free really. Either subsidised by Mark and a million volunteer, compassionate programmers or already paid for by the self interests of many companies. The only difference is that at least with some flow of money the users would have some _tiny_ amount of say instead of none.

  9. Would you pay into such a scheme? Do you know users who would? Is there enough money in our ecosystem to really pay people to do a good job on fixing problems or are we just not big enough yet?

    I know i won`t want to pay for fixing of hardware problems … i just think that this is in the interest and responsibility of the hardware company and a little in canonical`s and not in my own … i`m free to buy whatever hardware i want to work with Ubuntu and i`m sure a lot work almost perfect … at least my machine hasn`t made me any problems .
    But i`m sure there are users who would pay for this and that would help canonical a little in becoming profitable.
    What i would love to “pay” (contribute with money) for is software development like adding new, exciting, never seen before features that we the users want and/or need .
    I believe there is more than enough money in the ecosystem not only in Ubuntu`s but canonical just needs to find a way to take them in Ubuntu’s ecosystem this is achievable through openness to users and small business owners that don`t have huge resources but are really open .
    Or maybe canonical wants to become profitable and closed but i just think that needs far more effort and a lot more money that i don`t know if users will provide.

  10. Thanks for opening this up, Martin. I am also glad this is being discussed on economic and psychological terms as well this time.

    Just a few things here:

    1. If users insure themselves for release X, then given distribution’s architecture, it is likely things will work in X+N if the user does not change his hardware (as I am assuming driver stability in the kernel – sure, there are other things that can go wrong). Hence the user pays a one-time fee and is done with it.

    Even better, if the user is able to observe an insured user’s working configuration, he can freeload immediately.

    Otherwise, he or she simply sits with the current configuration for as long as it is supported and waits for a working release. In the worst case, he only has to pay once again and repeat this cycle.

    2. I am not sure this is economically viable for the producing company, as I assume some bugs might require a piece of the concerned hardware in particular configurations to test it out. Aside from this, there simply may not be enough developers available, because you have to pay them for the job in the first place, and the insurance inflow might not be enough to cover it.

    3. This model does not take innovation into account. I am not familiar with the internal assembly of new versions of Ubuntu at Cannonical, but I would assume it is more than just pulling upstream versions at particular time and putting it all together. So, when you spend all your money on fixing things just putting it all together, you won’t have money for adding new features in. If the product (Ubuntu) then does not provide a satisfactory experience, users lose the incentive to pay for support, since they won’t be using it.

    4. The biggest problem in general is that the income stream is simply unreliable (partly because of 1., but mostly because people don’t pay when they don’t have to), as is the case with donations. And as R wrote – no target demographic.

    In a more general case – as much as I like FOSS, we’re into software for making money. In cases where you have to pay for software beforehand, the developer has some income guarantee and security, and thus can work on supporting the product/developing a new one. In this case, the income fluctuates and as has been indicated above, would not be big enough. This would result in situations where the developer might be needed only for a month or two, and then become essentially redundant.

    I wonder – if Ubuntu introduced an upfront fee prior to downloading, how much would the income increase, and how much would the people be willing to actually pay for it. Because that would serve as a much better indicator of value than reliance on their goodwill. I am not familiar with GPL in all its details, but it is it possible to restrict access to Ubuntu and not make it available for free, and freely redistributable? Because the individual parts are (mostly) FOSS, and are already available on the internet free of charge on different websites. Of course, this would break the Ubuntu promise of always being free of charge, but if it’s possible, I think this is worth investigating.

    Just my 0.02.

  11. I’m in the business of making money so that I can make software. Money is just a tool and what we choose to do with it counts more to me than how you accumulate. Stability of position requires a certain amount of pre-investment into personal situational elements and I understand that necessitates the earning of money beyond immediate requirements in order to make such investments possible. But I fear some people go too far and let the earning of money become the goal.

    Charging for Ubuntu would be a situational irony, even if Canonical gained $10m per year in sales (and about $1 billion in liabilities) they’d be cutting off about $100 million in production from the community and at the same time decapitating the actual point: To make good software, morally, responsibility and sustainably. Proprietary software isn’t sustainable in technical terms and the problem we’re trying to solve is making FOSS sustainable in economic terms.

    Of course anything we can do to make things economic shouldn’t require us to deny the principles of foss, we’d be loosing a lot more than gaining there.

Comments are closed.