A client that my company consults for is a provider of an open-source library that’s been distributed for most of the last decade under a fairly permissive license. Last year, in order to encourage payment from companies that were embedding the library in their commercial products, we recommended migrating the product to a viral open-source license.

While the client was generally in favor of this approach, management was genuinely concerned about a project fork—that is, that someone would take the permissively licensed product and make changes to it that would keep it up-to-date with the original version, and perhaps even add capabilities. I was not concerned about this. With half a million lines in the codebase, I doubted anyone with the expertise had the commitment to provide this service for free—and compete with the established version.

When the version of the library was released with the new viral license, there were complaints and two posts on the mailing lists about forking the project. One of them asked for potential contributors to respond. We don’t know if anyone did, but on the mailing list, there were no statements of support. Almost a year later, we are not aware of any project forks.

Forking is frequently touted as one of the principal benefits of using open source. The reality, however, is that this benefit is primarily an abstraction. Projects of any substantial size are extremely difficult to fork, and successful forks not backed by serious dollar investments are very, very rare. The reason for the difficulty lies at the heart of another open-source myth, namely of the midnight engineer generously donating his or her time to a project that interests him or her. Those people certainly exist, but they are rarely the principal developers of a large project. I discussed this phenomenon in my column, “The Changing Face of Open Source.”

Core developers of large projects are almost always paid developers. This is true for Eclipse, JBoss, Red Hat, most Google projects and, notably, OpenSolaris, among many others. These developers are either employees of companies that have a commercial interest in the finished product, or that derive revenue from ongoing support of the product. These developers, then, don’t have any reason to join a fork. In fact, they have strong reasons not to.

In the event an open-source project is closed down, such as Oracle’s decision regarding OpenSolaris, the competition of an existing product is no longer a constraint, but the lack of payment for contributions is a limitation. Today, this dynamic is playing out with Illumos, the community that has gathered to keep OpenSolaris going. The project, which is receiving contributions in kind (as in services such as hosting), will taste success only if it can secure the wherewithal to hire Solaris engineers who choose to leave Oracle or are drawn in from other companies.

While it’s certainly possible that engineers could volunteer their time, it’s unlikely volunteers will contribute on a scale sufficient to do more than maintenance. Illumos’ principal goal of replicating the new features Oracle adds to Solaris is unlikely to be a big draw for engineers assessing where to donate their time. Most contributors to open-source projects enjoy, even delight in, blazing new paths rather than copying features—especially when they’re developed by a company viewed as an antagonist. As a result, Illumos faces many substantial obstacles.

Most open-source forks of any importance (such as the FreeBSD and OpenBSD forks of BSD Unix, as well as the many variants of Linux) occur in operating systems, and generally because of a specific need that a group is willing to invest in.

Ubuntu is a prime example, and one that was well funded. Community-based forks of Linux mostly originated when the OS was smaller and less stable than it is today. Other forks, such as the Joomla-Mambo-MiaCMS tri-vergence, were done due to personality or philosophical differences. I leave you to decide which have been successful and which not.

Forks of open-source projects nearly always split a community. Because most projects don’t have a large community to begin with, if there is no one paying for development of the fork, most forks die off quickly as the forking group begins to realize the size of its undertaking and the limited resources at its disposal. There have been perhaps 25 successful forks of high-profile projects that were sustained by a volunteer community. And those few projects (most of which occurred years ago) have kept alive the belief that forking is a standard open-source activity and a viable development option.

However, unless there is a serious commitment of dollars behind the new project, in today’s world, most forks are stillborn or die quickly.

Andrew Binstock is the principal analyst at Pacific Data Works. Read his blog at binstock.blogspot.com.