following my previous post exploring Ubuntu insurance:
Sirrus Submitted on 2010/09/10 at 2:27pm:
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.
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.