May 2005 Archives

Recently, James Gosling said :

"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'm baffled.

I can't believe that James really thinks that open source projects run this way. Sun's enterprise customers probably run on a lot of open source, including things like the Apache web server ("httpd") and Linux. We'd all be screaming in the hills if change was capricious and random...

In Apache Harmony, we'll be running as a normal Apache project, where committers must earn the ability to get write access through demonstrated quality participation, and then commit changes in a publicly auditable fashion. Every change to the source base is made available for inspection by anyone through a mail stream of diffs for each commit. We don't expect every user to watch this commit stream (although they could), but every developer will be.

We are also planning to have enhanced, proactive IP surveillance to ensure that source code added to the Apache Harmony repository doesn't infringe on IP rights of others. I realize that many commercial software vendors do this, but know that quite a few don't... These aspects of OSS development can (and will) be managed in a professional way.

Today, I become an IBM employee. IBM acquired my company, Gluecode Software Inc.

I'm excited.

Dalibor Topic is a great guy. I've eaten beef by the metric ton with him in Brazil, and hiked in flip-flops up a mountain to see waterfalls, all while musing about open source VMs and Java class libraries. We've also debated the merits of the GPL and the Apache License to a standstill :)

His thoughts on Apache Harmony are here

And yes, as he noted, I screwed up. While I thought that everyone on the proposal had reviewed it, I hadn't sent it to Dalibor, Mark, Tom and Jeroen. And probably others. For this, I'm sorry - it was an innocent oversight on my part, but an important one for them.

Depending on how this process is managed, this could either become a big delay in bringing a full free software/open source Java implementation (as people take sides on the licensing debate) or if managed properly could make open source java more viable.

Yes, this is true - we're trying to be careful that this doesn't descend into a license debate. We have issues with each other's licenses. We're working on it separately. Lets put that aside here and work on technology that we can share.

The challenge that the Harmony project faces now is significant. They need to convince enough of the existing open source Java developers that they should abandon the current GNU classpath effort and either relicense their code to be Apache-license compatible, or that they should rewrite their code to assist this new effort on the grounds that the Apache License is better.

We have a significant challenge, and that is building a compatible, complete J2SE implementation. Our challenge is not to convince developers to abandon GNU Classpath. We have no interest in getting people to abandon GNU Classpath - we'd be happier with a stronger GNU Classpath project because of our collaboration.

Remember, there are a lot of people / organizations / entities that don't contribute to GNU Classpath. (Why? I don't know - ask them....)

There is enough room in the Java side of the managed runtime world to afford more than one effort, especially if those efforts are working together to solve common problems and share solutions. After all, that's one of the main things that open source is about for us at the ASF - collaboration....

(P.S. FWIW, I really like Mono.... oh, and IKVM is just simply studly...)

Simon Phipps : Things like this (and the new openness of the v6 - Mustang - work) renew my confidence in the promise of the Java community - read the FAQ to see more. This is just the sort of responsible, community-led evolution that the JCP rules were changed to facilitate.

(Hey, I'm blogging in Sam's style...)

Graham Hamilton is a guy I much admire (don't tell him that...), and one of the many people I worried about when it came to Apache doing J2SE.

Graham posted some thoughts on Apache Harmony, and I am really happy with what he said. One thing in particular that I'm especially happy with:

"I wish Apache success and we'll certainly be tracking this as it develops. We'll probably participate in the project at some level, although most of our efforts will continue to be focused on building Sun's reference implementation of J2SE."

It's clear that we have a long road ahead of us, and it's going to be rough. I'm glad we were able to start of on such a good footing, and I'm hopeful that we'll be able to fruitfully develop the relationship between Apache Harmony and Sun - there's nothing better than full community involvement, and as the inventor of Java, Sun is clearly part of the community.

Project Harmony
===================

Motivation
----------

There is a clear need for an open-source version of Java 2, 
Standard Edition (J2SE) runtime platform, and there are many 
ongoing efforts to produce solutions (Kaffe, Classpath, etc).  
There are also efforts that provide alternative approaches to
execution of Java bytecode (GCJ and IKVM).  All of these efforts 
provide a diversity of solutions, which is healthy, but barriers 
exist which prevent these efforts from reaching a greater potential.

Proposal
--------

We propose that we create a new Apache project, Harmony, that will achieve
the following goals :

1) create a Compatible, independent implementation of J2SE 5 
  under the Apache License v2

2) create a community-developed modular runtime (VM and class library)
  architecture to allow independent implementations to share runtime 
  components, and allow independent innovation in runtime components

In doing so, we intend to create a broad, collaborative community of
contributors, implementors and users of the modular platform specification.

To begin, we propose the following as a basic architectural blueprint 
as a starting point for our discussion :

     http://people.apache.org/~geirm/harmony.jpg

We will create directly, via inclusion of independent third-party code, or 
through contribution :

a) a freely implementable specification of a modular VM 
  and class library that allows for multiple, independent 
  implementations 

b) a test suite for interoperability testing of the modules

c) an implementation under the Apache License of the modular VM

d) a class library under the Apache License compatible with 
  the J2SE 5 specification that implements the defined interfaces

We will start with this mechanism because we desire to :

- have a simple plan upon which coding can immediately begin

- ensure that we have a focal point to begin the conversation 
  among interested members of the community

- have a clearly defined set of technical needs to allow
  potential contributors, either code contributors or 
  individual participants, a basis for consideration

- ensure that this is a community effort - together we will 
  architect and implement via fresh new code or donation

- produce a set of specifications/designs allowing multiple 
  interoperable implementations that allow for sharing, 
  extension and innovation

We propose that the following people are considered the starting
participants. This set represents members from across the community, 
this diversity a factor we wish to start with and preserve as we grow.  

These individuals have expressed an interest in participating in the 
architecture and design work.  The information in parenthesis indicates 
other community participation or relevant experiences of that individual :

  Guy Churchward (individual w/ commercial VM experience)
  Joakim Dahlstedt (individual w/ commercial VM experience)
  Jeroen Frijters (IKVM)
  Geir Magnusson Jr. (Apache)
  Ricardo Morin (individual w/ commercial VM experience)
  Georges Saab (individual w/ commercial VM experience)
  Bruno Souza (SOUJava)
  Davanum Srinivas (Apache)
  Dalibor Topic (Kaffe)
  Tom Tromey (GCJ)
  Weldon Washburn (individual w/ commercial VM experience)
  Mark Wielaard (Classpath)

and the following individuals have expressed interest in participating 
as committers for the Apache-licensed implementation :

  Jeroen Frijters (IKVM)
  Ben Laurie (Apache)
  Geir Magnusson Jr. (Apache)
  Ricardo Morin (individual w/ commercial VM experience)
  Bruno Souza (SOUJava)
  Davanum Srinivas (Apache)
  Dalibor Topic (Kaffe)
  Tom Tromey (GCJ)
  Weldon Washburn (individual w/ commercial VM experience)

These individuals will participate as Incubator Mentors :

  Noel Bergman
  Ben Laurie
  Geir Magnusson Jr.
  Stefano Mazzocchi
  Sam Ruby
  Leo Simons
  Davanum Srinivas

The following Apache Members will be the sponsoring members :

  Noel Bergman
  Jason Hunter
  Ben Laurie
  Ted Leung
  Geir Magnusson Jr.
  Stefano Mazzocchi
  Sam Ruby
  Leo Simons
  Davanum Srinivas

The following community members support this effort :

  Danese Cooper
  Brian Goetz
  Doug Lea
  
Operating Considerations
------------------------

0) We have established a list for discussions.  Unless your 
comment is directed to the general Incubator community or the 
Incubator PMC, please post everything to :

    harmony-dev@incubator.apache.org

You can subscribe by sending an email to 

    harmony-dev-subscribe@incubator.apache.org

Until this proposal has been accepted by the Apache Incubator PMC, 
these lists are provisional.

1) Due to the various known and unknown risk factors of this project,
we propose that in addition to the required Individual Contributor License 
Agreement (ICLA) we shall require that any committer to Harmony will 
have a Corporate Contributor License Agreement (CCLA), when appropriate, 
on file with the ASF Secretary, and will keep that document current with 
respect to current employer to preserve committer status.  We do this 
in order to help protect the community, both contributors and users, 
from unauthorized incorporation of code or other intellectual property.

2) Historically, there has been wide exposure to VM and class-library-specific 
source code that is the property of Sun Microsystems as well as others, as 
it is common for commercial J2SE implementations to be based on licensed 
Sun code.  We wish to make every effort to ensure that the licenses and 
rights of external projects and efforts is properly respected.  To that end, 
we will explore additional ways to work with the Apache Incubator to ensure 
that all IP is carefully monitored and tracked as it enters the project.

1. Easy install. I wanted to do a archive and install, but I forgot to find that button, and it just did the upgrade. Painless.
2. Seems *much* faster. Just feels faster.
3. Colors seem to have subtly changed...
4. Mail wouldn't work (had to get rid of the GPG bundle). Safari didn't work (had to remove SIMBL - thanks patrick!). NetNewsWire didn't work (had to upgrade to 2.0 beta...)