Interesting paper. Does a pretty good job of explaining market behavior for 'free' or 'open-source' software. There are a few points that I noted as I thought I'd share.
- You state "Throwing the patch in the pool may gain nothing, or it may encourage reciprocal giving from others that will address some of J. Random's problems in the future.". The real payoff that JR may hope for, which you allude to above but should also mention here, is the incorporation of the patch into future versions of the software so that he won't have to re-apply it himself. This payoff does not depend upon any one else's reciprocity or generosity.
- There are a few problems with source-sharing which you don't really mention:
- If someone develops an algorithm or piece of code which would potentially be useful to ten other people 'somewhere', any effort to publish it in such a way that those ten people can find it will likely cause extra man hours to be spent by those not interested (if it takes 7500 people one extra second to read through a list of patches, that's over two man hours' of time spent by those who got no benefit from the software). Unfortunately, it's often hard for a programmer to help his code find the people to whom it will be of use.
- Oftentimes products are a lot junkier than vendors want to admit. In some cases, this amounts to deception on the part of the vendor; in other cases, especially with code that has a finite useful lifetime, the quality of the code really doesn't matter to the client if it does what is needed but the vendor's image would nonetheless be harmed if the quality of the code were known.
As an example of the latter, I have sometimes had to do one-time conversion of data from one format to another. There was a certain amount of data to be converted, and once that was done no more data would ever be created in the former format. If the conversion is checked for correctness, and the code performs the conversion in an acceptable length of time, the quality of the code is irrelevant. In such cases, I'll often spend half an hour cobbling something in QBASIC rather than write a 'real' program to do the job. Ugly, but it works. On a related note, any software which is to be shared must be documented. While documentation is important for any software whose useful lifetime might last beyond the programmer's ability to maintain it, it's often not terribly relevant with one-time-use programs such as I mentioned above. If it takes me half an hour to throw together a program to do some data munging but would take an hour to document it, that documentation is using up time that could have been spent to write two other similar programs.
- One reason hardware vendors are often loath to publish hardware details is that then such details often end up being "locked in stone". A vendor who hides hardware details behind a closed-source device driver may feel free to make hardware changes that break existing drivers if new drivers can deal with the change. By contrast, any vendor who does so after publishing the hardware details risks the wrath of many irate customers.
- It's interesting to note the mention of DOOM. The phenomenon was actually more pronounced with Quake, and ID scored a major marketing coup with its balance of open vs. closed code.
In particular, the rendering code and such were kept closed, but nearly all of the information required for someone to patch the game as they wished was open. ID's major coup, though, was allowing only certain 'standard' levels to be run on the free version of the game while allowing custom levels to be run on the purchased version. In earlier 'teaserware' games, a player would get 6-10 levels as a 'teaser'; paying $20-$50 would get the player an additional 20-50 levels. In Quake, the 'teaser' is similar (7 levels), but the payoff for buying the game is much greater: not only does the player get 20 more Quake levels, but he also gets the ability to play thousands of levels developed by other people. Compare the value of, e.g., Jill of the Jungle (30 extra levels for $20, or $0.66/level) with that of Quake (1,000+ extra levels for $50, or less than $0.05/level). It's pretty clear which is a better value.
- In the early days of video games, hardware was sold well above cost. Today, much video game hardware is sold at or below cost, with the manufacturer making its money off royalties paid by software developers. While this type of system has pros and cons for everyone involved (manufacturer loses money selling hardware, but its lower sale price contributes to widespread adoption of the system; this benefits everyone, but software developers and customers have to suffer royalty payments) It's not clear how an open-source environment could work in this context, though some ways exist by which manufacturers could be assured of royalties even by open-source developers.
|