Oracle should relax Sun's Java Community control grip
'No-brainer' open-source vote winner
If Oracle ends up owning Sun Microsystems, it's got a one-off opportunity to correct the mistakes of the past when it comes to working with open source on Java.
The database giant should relax Sun's tight control over the Java Community Process (JCP), the body responsible for stewarding Java. And as part of this, Oracle should solve the long-running and contentious issue of open-sourcing the test compatibility kits (TCKs) that test implementations of Java.
That's according to long-time advocate of JCP reform and leading open-source Java developer Rod Johnson. He told The Reg recently it would be an "absolute no-brainer" for Oracle to resolve the intellectual property issues in the TCKs that Sun has given for not opening the kits.
"That's a gesture that would be receive extremely well," Johnson said, speaking ahead of the news the European Commission will investigate Oracle's proposed purchase of Sun. "If they don't do that, they are throwing away an opportunity."
What Oracle actually has in store for the JCP on this issue is unclear. It's understood to have met with JCP members and delivered a brief statement of principles. The meeting - and the statement - are both under a non-disclosure agreement that potentially prevents people discussing it.
The JCP was created by Sun in 1998 as the body to make changes to Java and enforce compatibility and prevent fragmentation. It was created when Sun's attempts to have Java ratified as an independent, international standard failed in the mid 1990s.
Today, many of the ideas in Java are coming from the community outside the JCP, yet the JCP retains ultimate authority over what goes into Java and on compatibility - despite Sun open-sourcing Java a few years back.
For all its evangelism - and its initial decision to open source Java - Sun has refused to open the TCKs, infuriating and frustrating the open-source community.
This has led to accusations that Sun is hindering - not helping - open-source Java projects such as Harmony from the Apache Software Foundation (ASF), backed strongly by IBM.
While Apache's has been able to build an implementation of Java Standard Edition under Project Harmony thanks to the opening of Java, Harmony cannot be certified because the TCKs contain proprietary code the open-source code cannot touch. Harmony, therefore, remains stuck in a limbo of having been built but being uncertified.
It's believed this has seen potential users shy away from using Harmony and stick with the official JCP's official implementation of Java SE. This has been an important spec, because it also formed the basis of Java Enterprise Edition, used in older application servers such as IBM's WebSphere and Oracle's WebLogic.
Given Apache is backed by IBM - Sun's main systems and Java rival over the years - the refusal to open the TCKs is seen as a political move on the part of Sun.
It's particularly incumbent on Oracle to move on this, because while it has a healthy record of contributing to open source at an engineering level on Linux, Oracle's numerous contributions are overshadowed by its political machinations that mean people don't trust it.
For example, it upset the MySQL community by buying transaction engine InnoDB for no other reason than to apparently throw people off their balance. Oracle, meanwhile, has tried to kill Red Hat by launching a rival Linux support service to steal its business with its Unbreakable Linux. Oracle's chief executive Larry Ellison has a history of not wanting to be beholden to operating-systems companies. That's why he backed Linux so early against Windows in the late 1990s. Only now, Red Hat is the dominant Linux distribution.
"Oracle doesn't get a huge amount of trust in the open-source community," Johnson observed. "Had IBM owned Sun people wouldn't have assumed IBM was going to thrash the open-source elements, but with Oracle they don't have an open-source track record so there's more concern."
Less Process, more visibility
There is another problem for Oracle, and for Johnson, it's in an area where he believes Sun could have made more progress and Oracle can go further: making the JCP open and transparent. Making the JCP more like an open-source project, which can attract the kinds of community members where innovation in programming and in Java are really coming from today.
The problem with the JCP today is the majority of those leading the specs that go into new versions of Java are led by Sun employees, and it's down to the spec leads how much information they share with other members of the JCP on the technology and progress.
This closed process has not only turned off potential participants from the open-source community. The process has, according to Johnson in the past, damaged Java by creating specifications that are designed by committee rather than being of genuine use to the industry.
Johnson's company SpringSource voted against Java EE 6.0 in March, with Apache, saying the process that bred it had led to the inclusion of new and untested features that risked introducing braking changes to enterprise Java.
Johnson believes Sun's also used this approach to bolster its own Java middleware at the expense of middleware from IBM. Java specs, for example, were implemented sooner in Sun's GlassFish application server that other application servers. GlassFish was also anointed by Sun as the industry's official Java application-server reference implementation.
Not that this really helped Sun's middleware in the remotest on market share or paying customers. But it did rob the process of participants who could have helped build Java specifications developers wanted and could really use.
"If Oracle attempts to exert the level of control Sun has exerted, that will cause people to lose faith in the JCP," Johnson said. ®