``[...] variations, however slight and from whatever cause proceeding, if they be in any degree profitable to the individuals of a species, in their infinitely complex relations to other organic beings and to their physical conditions of life, will tend to the preservation of such individuals [...]''Charles Darwin, [2, chapter 3]
Unlike natural species, software variations are not random, but are created by developers to adapt the software to users' needs. In fact, in the case of Free Software, it is the user that drives the variation process, by patching the software herself, by hiring someone else to do it or just by posting the change request to a mailing-list and hoping someone will volunteer to do it, for free or for a fee. It should be obvious that the freedom to make changes and to redistribute the new variations increases the variability of the species, making it more suitable for other, even unforeseen, niches.
Although such modifications do not need to be contributed back, they often are. When they introduce a feature useful for a wide variety of niches, a feature that represents a general competitive advantage over the original release, the changes are often accepted by the package maintainers, and quickly proliferate. When they are not generally advantageous, they are most likely to be rejected, and perish due to lack of maintenance resources or survive only in the limited niche for which they were designed, in which they are maintained separately from the main project.
Even when a change is introduced by the maintainers, users all over the world will be validating the changes around the clock, if the package is developed following the Bazaar model [5], i.e., with anonymous CVS [6] access and open mailing lists for public discussion. If a user disagrees with a change, he may complain and try to convince the maintainers to withdraw the change he didn't see fit. If the maintainers don't take it back, the user may keep on running the unmodified copy. Even though developers drive the introduction of mutations, they often do so based on user feedback, and it is user adoption that grants a variant more running copies at the end, so users play a central role in the process of selection of variants with the most appropriate features. As in nature, mutations of software perceived by users as advantageous for the niche they determine are more likely to survive and to be promoted by the users so as to leave descendants.
Proprietary-software companies, in comparison, choose a niche for their software in advance, and they won't allow a user to adapt the software to other niches. Even when they can afford to have many developers and are able to sell a large number of copies, their software still falls victim of reduced variability. That's not just because users can't make changes: software maintainers, proprietary or not, tend to consider variation bad, because, for each variant, they incur additional costs in maintenance and user support.
Free Software is not exempt from these costs. Sometimes, conflicts among members of a community of developers and users lead to a fork. Under a biological frame of mind, forks might be perceived as good, because they increase the variability of a species, while still allowing the sharing of code. For example, security fixes quickly propagate to all of the various BSDs; a port of GNU Emacs to a new operating system can often serve as a basis for a port of XEmacs, and vice-versa.
However, it takes a significant effort to maintain forks. They waste not only developers' time, as each feature is re-implemented over and over, but also community resources for testing and running the program, reducing the strength and coverage of each variant. Unless branches of a fork focus on different niches, as in the previously mentioned cases, it may happen that one draws sufficient attention so as to dominate the niche, displacing the others. Sometimes, before such a displaced variant dies, it is unified with the mainstream, as happened with EGCS/GCC.
A point worth mentioning is that software is intentionally, not randomly, adapted to new niches. One might even claim it would be better modeled after Lamarck's theory of evolution [7]. Lamarck believed that a living being inherited from its ancestors characters acquired during their lives. But Lamarck's theory does not apply to the analogy I propose. When a program is modified, it is not the original copy that acquires the change and then propagates it to its descendants. On the contrary: a program modification creates a new individual with a mutation, and the mutation may then be inherited by descendants of this new individual, as in nature.