"Bazaar" - how useful is the right to fork?
By ColmSmyth on Nov 28, 2004
Compared with the days of his work on The Cathedral and the Bazaar, it's a shame to see Eric Raymond commenting in the media today; he seldom seems to get the point anymore, or maybe it's just that his ideas seem to be distorted under the glare of publicity.
He states in effect that the cornerstone of open-source is the right to fork. However for a project of any real size, this issue is bunkum. Forks of projects like Linux or OpenOffice.org are doomed to failure because of lack of momentum and contribution, and because they run the very real risk of falling out of touch with the standards that the original project supports. If a fork becomes non-interoperable with the main-line, a few core hackers may be happy with their independence but everyone else loses:
- there are fewer effective core developers working on the project - their efforts are divided with each fork
- the project is a less attractive platform to application software developers because they have to build and test for each fork
- it is also less attractive to deployers because they run the risk of running a fork that falls out of favour and ceases to be supported
- users lose confidence because they are presented with the difficult choice of choosing which fork to run; service and support offerings have to try to target variant versions
For the reasons above, forking must be the last resort, like weapons of mass destruction. The optimal path is to steer the main-line in the right direction, and this is exactly what the JCP or Mozilla.org's super-reviewer approach enables in a far more effective way than Linux's benevolent dictatorship with the right to petition Linus for desired changes.
And if Raymond is right that IBM really plan to release their own JRE and class libraries within a year (and is not merely himself the subject of smoke-blowing), then this is further evidence that the right to fork the source is secondary to the right to implement software according to a standard; standards enable interoperability, which means that software built against the standard preserves the momentum and importance of the platform, which is ultimately what benefits developers, deployers and users.
So what is the fundamental basis of the bazaar? I would argue that it is the common currency which enables trade, or the common standards which enable substitution as a basis for true competition.
Update: there are some comments coming in which I'd like to respond to.
- I talk here about the right to fork, which is what Eric Raymond talked about in his response to Jonathan's comments (and which he retrospectively says is the core of the bazaar); I think that this right is often illusory and that exercising this right on larger projects is often destructive
- The right to fork is useful (or even essential) for smaller (and a few rare medium sized) projects where there is a real possibility of useful innovation in a fork and a later re-merge
- GNOME and KDE are not forks; each has a completely independent code base (aside from X11 and a few libraries); similarly Solaris and Linux are not forks
- I definitely support the need for competition (see this for example)
J2SE does have some TCK's and it is based on the JRE which is completely specified, however I agree it is not trivial to create a 100% compatible clean-room implementation. I think it has also become easier for developers to contribute code (patches) to Java libraries (on Bug Parade) which avoids the need for a fork; I hope more people take advantage of this as a way to improve Java where you need it.