Free beer is good, making your own beer is not always better

It seems that every man and his dog have been writing about the virtues of an Open Source Java and how it will solve world hunger, the conflict in the Middle East and the confusion over how Britney Spears has just been announced FHM’s most sexy woman.
It was this blog entry by Eitan Suez that was the straw that broke the camels back.
Now, before I am tarred with the pro-Microsoft brush, I’d like to say that I’d like to see Sun change their licensing policy to allow the Linux distributions to distribute the JRE and the JDK as part of a package. I really don’t see the harm, and I can see that it can only help, mostly to shut up a bunch of whiners who want to jump on bandwagons without the faintest clue. I’m very happy with the way Sun has treated Java, and I don’t see how open sourcing the codebase will help. At all.
To the real point, the pro-open source Java crew seem to be collecting around the simple view that when Java is open sourced, then all the bugs, and issues in the JVM will be magically fixed by all the motivated and freely available Java programmers just rushing to spend time fixing them. And I quote;
“Any features that developers claim are missing would quickly be contributed as patches to the J2SE codebase.”
To this I reply: “Absolute bollocks”.
It is simplistic and naive in the extreme to take this view. And I can only conclude that it comes from people who have never, ever been involved in an open source project of any sort. In all the projects I have been involved in, either as a maintainer, or as a patch provider to an existing project, the successful projects are run by a core group of people who manage the process, accept patches to the codebase and make the necessary releases. The source is available, CVS write is not available to everybody, but there is no hue-and-cry for Apache or Linus to open up write access to each project so that J Random Developer can just dump in their fixes.
How is that different to what Sun does ? For a start, all the source code for the Java releases is available to anybody who wishes to download. They can then find the problem, create a patch and submit it to Sun for inclusion in the next release. How many people have ever done that ?
I’ll admit that I speak from ignorance in that I don’t know how many people have done this and had their patches rejected, only the Sun engineers can really respond to that, but I’ve been working on an open source project for 4 years and the number of patches that comes in is low, very low, compared to the codebase and the number of developers on the mailing list. (To those who have supplied the patches, bug reports for BouncyCastle, I thank you for each and every one, I’m not raining on your generosity, I’m just making a point that in general, developers want to use the software provided free by others, rather than be deeply involved)
Maybe to clarify this point somebody should start a register of all these Java software developers who are just craving to provide fixes to Java over all these years to show Sun (and me) how much support they have. Of course, the developers will actually have to do the work, and that’s the sticking point, I just don’t see it happening. Go ahead, prove me wrong. My guess is that most of the cry for open sourcing Java is over some weak religious ground by feeble minded followers and it’s all being dressed up with this additional resource rhetoric which is completely false.
Focus your efforts on getting Sun to change the licence model if that’s what is really wanted, but I suspect that you’ve well and truly burnt your bridges by now, which is terribly sad because that would have been a cause worth working towards.


2 thoughts on “Free beer is good, making your own beer is not always better

  1. open source java ad infinitum

    Jon Eaves makes a very good point
    about open source Java. It’s very interesting the way that open source
    is sometimes seen as a salve for all software ills, always. NO tool or
    solution or proposal is ALWAYS appropriate. Personally, I just think

  2. Actually, I’d patch the following if I had access. First, I’d make support multiple cookies the way it used to before Java1.3. Then I’d find the code that loaded libraries on Win32, and have it use LoadLibraryEx(LOAD_WITH_ALTERED_SEARCH_PATH), so that if you give a full path to a DLL, DLLs it implicitly loads can live in the same directory and not on PATH, as is currently required.
    I know, however, that by doing so I’d probably break other programs, and that is the big problem with making any change to a broadly used component: one person’s improvement, is another person’s regression.

Comments are closed.