[SC] The underprovision problem would in fact scale linearly with number of users if we assumed programming talent to be uniformly distributed in the project user population as it expands over time. This is not, however, the case.
The incentives discussed in [HtN] (and some more conventionally economic ones as well) imply that qualified people tend to seek projects that match their interests, as well as the projects seeking them. Accordingly, theory suggests (and experience tends to confirm) that the most valuable (most qualified and motivated) people tend to discover the projects for which they fit well relatively early in the projects' life cycles, with a corresponding fall-off later on.
Hard data are lacking, but on the basis of experience I strongly suspect the assimilation of talent over a growing project's lifetime tends to follow a classical logistic curve.
[SH] Shawn Hargreaves has written a good analysis of the applicability of open-source methods to games; Playing the Open Source Game.
[DPV] Note for accountants: the argument that service costs will eventually swamp a fixed up-front price still works if we move from constant dollars to discounted present value, because future sale revenue discounts in parallel with future service costs.
A similar but more sophisticated counter to the argument is to observe that, per-copy, service cost will go to zero when the buyer stops using the software; therefore you can still win, if the user stops before he/she has generated too much service cost. This is basically just another form of the argument that factory pricing rewards the production of shelfware. Perhaps a more instructive way to put it would be that the risk that your service costs will swamp the purchase revenue rises with the expected period of usefulness of the software. Thus, the factory model penalizes quality.
[WG] Wayne Gramlich >Wayne@Gramlich.Net< has proposed that the persistance of the factory model is partly due to antiquated accounting rules, formulated when machines and buildings were more important and people less so. Software company books show the computers, office furniture, and buildings as assets and the programmers as expenses. Or course, in reality, the programmers are the true assets and the computers, office equipment, and buildings hardly matter at all. This perverse valuation is sustained by IRS and stockmarket pressure for stable and uniform accounting rules that reduce the complexity of assigning a dollar figure to the company's value. The resulting drag has prevented the rules from keeping up with reality.
On this view, pinning a high price to the bits in the product (independent of future service value) is partly a sort of defense mechanism, a way of agreeing for all parties involved to pretend that the ontological ground hasn't fallen out from under the standard accounting rules.
(Gramlich also points out that these rules underpin the bizarre and often self-destructive acquisition sprees that many software companies tear off on after IPO. ``Usually the software company issues some additional stock to build up a war chest. But they can't spend any of this money to beef up their programming staff, because the accounting rules would show that as increased expenses. Instead, the newly public software company has to grow by acquiring other software companies, because the accounting rules let you treat the acquisition as an investment.'')
For a paradigmatic example of forking following defection, consult the history of OpenSSH. This project was belatedly forked from the an early version of SSH (Secure Shell) after the latter went to a closed license.