Simon Phipps's Blog

J2EE Archives

Thoughts on Open Sourcing Sun's Java Implementations

Will Sun use GPLv3? (November 20, 2006)

Some people have been throwing rocks at the GPLv3 process from outside, and others have been accusing Sun of joining the rock throwers by opting for GPL v2 for the Java platform. Here's why I disagree with both.

---

Why Bother Open Sourcing Java? (August 18, 2006)

While the actual code-base will only be touched by the 400, the 4 million will benefit from the extended deployment range, the greater pool of expertise and the greater diversity of interests that will result. Open sourcing Sun's Java implementations is hard, has risks and affects only the 400 now, but it will quickly grow benefits that the 4 million will reap.

---

An Ongoing Process (August 15, 2006)

I briefed press an analysts in London to provide an update on the process of taking Sun's Java implementations open source. It's worth noting that this is part of an ongoing process that reflects Sun's roots.

---

Respecting The Developers (July 25, 2006)

So why doesn't Sun just pick an OSI-approved license, apply it to the Java source code and be done with it? Why claim it's so hard to open source the Java platform?

---

Forks Aren't a Problem (May 26, 2006)

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.

---

No Unfair Advantage (May 24, 2006)

There are two dimensions to compatibility. The one everyone with developer genes can grok is about having the same APIs doing the same thing everywhere the word "Java" is used to describe a virtual machine environment. The other is more subtle. It's about ensuring no major vendor - Sun included - gets an unfair advantage in the market because they have been able to exert control in a way that yields a competitive benefit.

Market Share or Sponsor Share?

According to Kirk Pepperdine, Gartner does not include open source application servers in their surveys. Two interesting comments from Kirk's article:

The next question is, how does open source get reported? By definition, open source draws no licensing revenues and by definition carries a 0% market share. Is it just me or am I right in saying that it just feels wrong to be basing an important decision on a report that cannot accurately describe the usage of all the offerings in the space that is being considered?

Kirk has no ideas how else to handle the problem, of course, but he does think it may be a sign of the maturity of J2EE that the problem exists:

What it does say is that our choice of application server almost seems random, which is what you'd expect to see in a commoditized market where you should not find any differentiating factors between competing products. If I recall correctly, this was one of the original objectives behind the J2EE.

[Also posted to Webmink]

An Open Spirit

In the first posting in her new weblog, Anne Thomas Manes talks about the idea of porting Jakarta to Mono, the project to implement C# and the core of the CLI from .NET on Linux. She says:

But from the moment Miguel initiated the Mono project, I’ve been worried about its future potential. I’ve feared that it would go the way of DCOM on Unix. (DCOM is an Open Group standard – and Microsoft retains ownership of its intellectual property.) A number of vendors implemented DCOM on Unix, but almost no one ever used it, because DCOM is pretty worthless without a bunch of application-level class libraries, such as ODBC, OLE DB, ADO, and ASP to run on top of it. Microsoft never released these specifications to the public, so these technologies have never been available for Unix. Hence DCOM on Unix faded away into irrelevancy.

What we learn from each of these forays into openness is that it doesn't matter how sound the vehicle being used to express the apparent 'openness' is (ECMA for C#, Open Group for DCOM, partenr community for NT), what ultimately matters is the open spirit of the originator. If their intent and method is essentially open, the process bugs get fixed along the way and more and more becomes open.

In the case of the Java environment, things have gradually opened up to the point where Apache are able to implement the whole of J2EE (in their Geronimo project). The process bugs (there have been plenty over the years and as Anne hints there are still a few to fix) resulted in the most part from the design of the process by humans. Sometimes it took waaay too long to fix them, but the underlying spirit has remained an open spirit that's resulted in increasing openness. The result has been a rich and diverse marketplace with many strong players, and for J2EE there is wide choice at every stage for the developer.

So when Anne proposes

So the way I see it, in order for Mono to succeed, we need to develop a set of open frameworks, engines, utilities, tools, APIs, and class libraries that run on top of it.

[Also posted to Webmink]

Roundtable report

FTPOnline has a report on the J2EE Roundtable held on Monday.

Round-table

The last few years I have been privileged to moderate a round-table discussion between the leaders of the J2EE community, hosted by JavaPro magazine. Each year I'm struck by the way there is a diverse competitive landscape for Java. This year the diversity was as strong as ever, with great participants like Ted Shelton from Borland (leading their corporate strategy), Graham Hamilton from Sun (the current brains behind J2SE) and David Litwack from Novell (creator of PowerBuilder and now driving web services at Novell).

I'll leave reporting on the content to JavaPro, but for me each year the fact that a competitive round-table is even possible is a cause for celebration and a mark of the success of Java. Within the community we naturally focus on our concerns and issues but seeing a room filled with high-energy companies like Borland, Novell, BEA, Motorola and Sun always reminds me that the openness of the Java community is a remarkable thing.

This work is licensed under a Creative Commons License.