Friday May 26, 2006 Forks Aren't A Problem
I keep hearing people claiming that the biggest problem that would be caused by making Sun's Java SE implementation open source is forking. But I have to disagree. The implication is that all forks are incompatible forks, but the two are not synonyms.
A fork happens when a group of developers take a body of source code and continue its development independently of the governance of the community from which they took the code. There can be bad reasons (personality conflicts for example) and good reasons (targeting a platform in which the original community has no interest), but the creation of a fork says nothing about the nature of the code in either community. Both bodies of code can be completely compatible with a file format, API or other specification.
Take as an example NeoOffice. It's a fork of OpenOffice.org aimed at providing Mac OS X users a version of the office suite that works just the way one would expect (as opposed to requiring geek skills). The team that develops it is independent of the main OpenOffice.org community and has its own governance. Yet NeoOffice is file-format and menu-layout compatible with all the programs in OpenOffice.org. It's a fork, yes, but it's compatible, and it has grown the market for the OpenDocument file formats.
In fact it would be unthinkable for it to be otherwise. The whole value proposition for NeoOffice is that it works just like OpenOffice.org, only on a Mac. This is not to say that an incompatible fork isn't possible, just that it's not inevitable for forks to be incompatible. In fact, in a market where there is a strong precedent for programmatic compatibility, I'd suggest it's unlikely that a fork will be incompatible. It might be used for unfair advantage but that's another issue altogether.
Posted by webmink
( May 26 2006, 12:00:00 AM PDT )
Permalink
Comments [1]
