I think that this is about as precise of an answer as you are going to get that will appease those that see OSS as an economic threat (comical).
I guess that this makes it a bit more tolerable that many commercial OSS vendors are pricing their software by the processor. I find this annoying because it means I have to count things and keep spreadsheets. I generally hate this type of friction - who doesn't. I still think that there must be a better way to price OSS. Perhaps they just aren't profitable?
You will likely have to read the article to "get" this quote, but here is r0ml:
. . . Those who have suggested that open source and free software is somehow not capitalistic, destroying the value of software and other such assertions, have missed this alternative explanation. It is just as likely that the free and open source software folk have stumbled across the financial engineering insight that a significant portion of the value of software is the embedded "derivatives"--options or warrants--on future maintenance and enhancement. Whether one believes that software has intrinsic value is related mostly to one's view on the correct value to use for volatility in calculating the option value. Larger values of volatility mean the software itself is worth less. Smaller values of volatility reduce the option price, and the software is intrinsically worth more.
Therefore, the major difference in worldview between open source advocates and proprietary software license advocates is explainable as a differing opinion on the correct value of the volatility of maintenance and upgrade pricing. People who believe that the pricing on maintenance is stable and unlikely to change see greater intrinsic value in the software. People who fear that the pricing is subject to large fluctuations see no intrinsic value in the up-front license; stripped of the options, the license value approaches $0.
For the open source movement, perhaps a better way to position the change that OSS is making is this: we're converting warrants on future maintenance and enhancements into options, which means that instead of having a sole supplier (warrants), we have created a third-party market (options) of these derivatives.
How capitalistic is that?
3 comments:
I am neither an economist nor do I play one on TV. But to me it seems that the value to users of software comes in large part from the utility of the software. (I don't know how this maps to the volatility axis, but I think I'm in the large volatility camp.) Thus the model I have heard attributed to historic Chinese physicians (you pay when you are well but not when you are ill) seems to be better model.
To stretch the analogy, software is "well" only when it is helping the user. The obvious (and perhaps best) way to determine when software is helping the user is to check on how many processors it is running. I argue that for that model to be effective it should be as easy for the user to determine if their software is "well" as it is for them to determine if they themselves are well.
Oracle had a reputation years ago for an arcane and impenetrable algorithm for calculating the cost based on number of processors, types of processors, and other things. I recall Oracle points-of-contact bemoaning the exercise. Perhaps this is an opportunity for a product to differentiate itself: provide a tool that does this calculation for the user.
Basically, the product would support querying each instance for how well it is. Since networks are ubiquitous, this information could be gathered across the network from a utility. Failing that, the product could produce a text file with the information and a mechanism for merging these files. It seems like this would be a fairly straightforward addition and it would make it quite easy for the users.
Damn Sarge. That is good commenting skills right there.
I can buy this as long as we agree that developer licenses / lab licenses are left out of it. Talk about bad management decisions I have seen - you basically end up silo-ing people to save cash (Meet Craaaig - he is our JMS guy - JMS runs on his machine and his machine only - see Craaig with JMS questions .. etc.).
The thing I most hate about per-proc pricing is it encourages people to do the wrong thing with deplyment.
Thanks.
Developer licenses of course don't count. That's like charging someone to window shop. Only an clown would make it hard for potential customers to browse the goods.
If per-proc pricing induces people to deploy suboptimally, then the price is too high. Yes, it happens, but it's a function of the individual pricing plan more than per-proc licensing, per se.
Post a Comment