David Herron's Blog

Open sourcing leads to incompatible forks?

This article: IBM takes potshots at OpenSolaris has some interesting things to say about open source projects being more than the license that allows freedom. It's about the community that's built around the open source project. However I don't want to go into the specifics about IBM's characterisation of the Open Solaris community.

At the end is a rather interesting quote:

And making IBM's Power processors an open-source project poses risks, Handy said. Specifically, the freedoms of an open-source approach could mean others take the processors in a different direction, so software wouldn't necessarily run on all models.

"You don't want the architecture to not be compatible with itself moving forward," Handy said.

This line of reasoning sounds very familiar to me.

This line of reasoning sure sounds a lot like what we used to say in defending the decision to not open source Sun's JDK implementation. This line of reasoning sure sounds a lot like the major fear that's seen in open sourcing Sun's JDK, namely that it would lead to incompatible forks in the market.

But we have a lot of people reassuring us -- the market highly values the compatibility of Java, and that the market highly values compatibility even in the face of highly valuing the freedom granted by the OSI-compatible licenses.

Hmmm.... Food for thought, eh?

I sure don't have any conclusions on this, it's just an interesting point to ponder. Does IBM really think open sourcing leads to incompatible forks?

Comments

• What happened to putting the entire entry in the description? :)

  Posted by: kirillcool on August 16, 2006 at 03:16 PM

• Too bad it doesn't make clear why there is only room for one open OS. I have no idea what he means by that or how he came to his conclusion. Is he talking about AIX or does he mean that Linux should be the only open OS in existence?

  leouser
  

  Posted by: leouser on August 16, 2006 at 04:07 PM

• Geesh, the more I think about the odder the article gets. Given that IBM is into open source why would they want to support projects that could have a negative effect on their customer base. It seems paradoxical. It also seems odd that the article would show up not that long, very soon in fact, after a further announcement of OpenJava. I suspect that their just trying to deflate the positive event that has occured and are using Open Solaris as the means to do it.

  leouser

  Posted by: leouser on August 16, 2006 at 04:35 PM

• To allow forks is an essential balancing force, it actually forces free software to get better.In order for any fork to be significantly viable, it must have an active community around it. It would be very difficult to get large organisations to move off the official Sun tree.So for the propeller heads, who want multiple inheritance operator overloading and functional programming, they will now be free to push "Scientific Edition." For the server side crowd, they can push their buzword saturated procedurally oriented skillset exportable "Business Edition." They all get a huge boost, by being able to leverage the Sun code. The core JLS can finally stop its horrific bloat, from trying to please everyone. (garbage collection, in the wrong direction) However, even these 'forks' will still be significantly pressured to run on the trunk runtime.Only when the trunk becomes stagnant, or obstinate, does any significant fork of the main runtime have any real opportunity. This in turn forces Sun's active consideration of alternative viewpoints, for a change.If nothing else, it leaves Sun in the enviable possition to 'cherry pick' the most successful parts of other forks, post facto, and advance the platform with 'sure fire' winners. ...only so long as the chosen OSI license does not permit proprietary forks... -John

  Posted by: cajo on August 16, 2006 at 05:30 PM

• Ah, I see I misstated my thought a little bit. What we're being told around open sourcing Java is not to worry about incompatible forks that arise. Yes, OSI-approved licenses offer the possibility for an incompatible fork. I suppose that if the community that grows around the open source Java is attractive enough, open enough, etc, then the effect of an incompatible fork is lessened because everybody is paying attention to the main trunk.

  Posted by: robogeek on August 16, 2006 at 08:14 PM

• IBM open sourced Eclipse (Websphere Application Developer / Visual Age for Java), I haven't seen any incompatible forks there yet...

  Posted by: phlogistic on August 17, 2006 at 06:47 AM

• David, our experience from GNU Classpath is that the fraction costs of maintaining unfriendly forks make them highly unattractive for downstream users, never mind the social cost in lost users, and bad reputation.

  Posted by: robilad on August 17, 2006 at 11:38 AM

• Cajo is right on the money. No one should care about a fork unless it's proprietary. Let them have their fun.

  Posted by: aberrant on August 17, 2006 at 12:29 PM

• Maybe the high market value will prevent some people from forking it, but there is a quite adept group out there with the means and intention to harm Java as a platform and they'll have no such problems.
  Remember it's a lot easier to fork software than to fork a CPU. All you need is a text editor, a compiler, and a computer. You don't need a factory with multimillion dollar machinery, cleanrooms, etc., let alone a physical distribution channel. An internet connection to sourceforge or another upload site is enough.
  And also remember that IBM themselves have been trying for the better part of a decade first to marginalise Java and then to try and take control of it away from Sun. This ill-advised venture by Sun may well give them what they want, a marginalised Java they have de-facto control over.

  Yes, we're being told we shouldn't worry about people forking it. But that's wrong, those forks are a severe danger to what makes Java such an attractive platform: the fact that I can compile Java code on one machine and it will work on another machine with a different hardware architecture and operating system without any work at all. Forks destroy that, leaving Java as just another language that you have to maintain a hundred distributions of your sources and binaries for if you support multiple platforms. Forks remove the main strength of the platform, leaving it for many purposes a suboptimal choice, which is exactly what those trying to marginalise the platform strive for.

  Posted by: jwenting on August 17, 2006 at 11:01 PM

This work is licensed under a Creative Commons License.