Open Source, Insert Foot

As a Java devotee, I grimace whenever language inventor James Gosling expounds to the press on the subject of open source.

In a story noting the 10th birthday of Java, Gosling said, "We did do it as close to open source as you could and still be a corporation."

Last month, Gosling responded to an Apache proposal to create an open source version of Java with puzzlement:

It's often difficult to get a good picture from the open source community of what they actually object to in what we're doing. In what way could we be more open? ...
Since day zero, 10 years ago, all of our sources have been open and available. We've got several thousand man-years of engineering in [Java], and we hear very strongly that if this thing turned into an open source project -- where just any old person could check in stuff -- they'd all freak. They'd all go screaming into the hills.

I have trouble believing that Gosling could be this mistaken about open source.

Open source projects do not allow random people to check in code. There's a submission process where proposed modifications are evaluated by people who have the ability to commit or reject a change. All revisions are tracked with code versioning software and can be backed out if necessary.

Gosling knows this -- he runs two open source projects, BlogEd and JNN, that require his permission to check in code.

The open source process works as well or better than proprietary approaches. I observed the early development of Geronimo, the Apache Software Foundation's J2EE application server, and its project committers are meticulous, professional, and extremely dedicated to software development.

Apache's so accomplished that its process has become celebrated as the Apache way. When I need a Java class library, I check Apache Jakarta before Sun. The code's often better, more reflective of real-world needs, and actively developed -- unlike parts of the Java 2 class library that Sun appears to have quietly abandoned.

Java is not remotely open. Under the Sun Community Source License, you can't publish a modified version, Sun decides whether your contributions are compatible, and contributors don't have to share their code.

If releasing open source code is detrimental to a corporation, that's news to IBM, Red Hat, JBoss, SleepyCat Software, and hundreds of other companies, many serving the enterprise customers that Gosling believes are fleeing in terror.

Gosling, who appears to have qualified some of his criticisms on his blog, ought to find some unloved part of the Java 2 class library like JavaSound and shepherd its adoption as an Apache project. He'd realize that open source can be an asset to Sun, which needs all the help it can get.

Java · Programming · 2005/06/14 · 1 COMMENT · Link

Comments

When I hear Gosling say things like this, I think he is being intentionally provocative.

Even Apache/Jakarta, an organization that has created some great stuff, doesn't always have the management end of projects together.

OpenSource projects are good at getting started and writing code, but seem less so at finishing. This is natural, I think, because coding is more fun than a lot of the other things necessary to really ship a product.

Jakarta projects have a great deal of duplication of effort. The whole commons area is scary when you dive in. There are so many small libraries and dependencies and versions get difficult to manage.

The core Java libraries have their own problems, of course.

Your point about JavaSound is a good one.

#1 · Eric Hancock · 2005/06/14