Life at Eclipse

Simon Phipps wrote an interesting blog post musing about the how the Japanese business model of interlocking companies (keiretsu) and the long tail intersect to describe the functionings of open source communities. Basically, the idea is that open source communities can be described as “code keiretsus around a long tail of applications”.

For those interested, the “long tail” theory first appeared in Wired Magazine and points out that in the new digital world, a great deal of money can be made servicing markets that would have previously been uneconomic due to low volumes. Anyone interested in learning about how this idea applies to Eclipse should go see Carl Zetie’s talk at EclipseCon.

Although the metaphors are interesting, I think the analysis falls apart in one place, where he says:

So how do these ideas relate? By combining them, we have a potential model for certain kinds of open source community such as GNOME, Apache and Eclipse.
….
This “code keiretsu” is unlikely to include direct competitors, but will include a diverse array of interests serving many points in a target deployment system.

It is around the area of competitive co-operation that I think that the idea needs some polishing. Specifically, Eclipse stands out as an example of where direct competitors are not only participating, they are doing so within the bounds of specific projects such as Web Tools (BEA, IBM, JBoss, Oracle) and Data Tools (Sybase, IBM) to name but two examples. What we’re seeing at Eclipse is very much the diverse array of interests that Simon expects, but the experience shows that the model needs to be be extended to include direct competitors as well.

As regular attendees to the Eclipse Members Meetings are aware, Siobhan O’Mahony from Harvard Business School has been doing research on the new business models that Eclipse is bringing to the forefront. Her ideas around Competing on a Common Platform seem closer to the mark than code keiretsu, despite the fact that the latter is so much cooler as a label.

I thought I would mention a few early thoughts on the GPLv3 progress, and the impact it may have on the Eclipse community. (In other words, I am most emphatically not talking about the merits of the Free Software Foundation (FSF)’s proposed GPL revisions in general.) Janet Campbell from the staff of the Eclipse Foundation is actively involved as a member of “Committee A“, so we are participating in the revision process.

As I am sure many people have read, the GPLv3 is now out in draft form, and the Free Software Foundation has stated that EPL compatibility is a goal of theirs. Which is great news.

However, it is important to realize that when the FSF refers to “compatibility”, they mean that GPLv3 code can consume Eclipse Public License (EPL) code. Not the other way around. So it’s a one-way street and Eclipse projects will remain unable to consume GPL code. That said, the ability for GPL projects to re-distribute EPL-licensed code would be an important and positive development.

Definitely the new GPLv3 terms for dealing with patents goes a long way to making the licenses compatible. That was the one area that the FSF themselves had identified as an issue between the GPLv2 and the EPL. However, the Foundation is still doing an evaluation of compatibility, as we owe it to our own community to be completely satisfied that we agree with the FSF’s position. Early results indicate that there are still some areas that need to be worked on.

We are also looking forward to the process for revising the LGPLv3. If that license can be made compatible with the EPL to the point where LGPL code could be used within Eclipse projects, the status quo could be dramatically improved. Unfortunately, only time will tell if this will come to pass, as the revision process for the LGPL has not even started yet.

Now there’s a company that know how to treat its developers. 2400 hundred technical people (1200 from out of town) all in the San Jose Convention Centre. That is a non-trivial investment of time and money into team building. But if you’re going to work in a distributed environment, it is a very worthwhile investment.

I had the pleasure of speaking this morning to the Developer Summit, sharing the stage with Jeffrey McManus of Yahoo and Jeff Barr of Amazon. The topic was how to create platforms and successful ecosystems around them.

Even I was surprised at the number of people who put up their hand when I asked who’d used Eclipse. Well in excess of 80% of the people in the room. Very cool.

Even more exciting was the news that the night before the Eclipse-based Flex Builder 2.0 and Flex won the internal shoot out for coolest product, with Sho Kuwamoto running the demo. The full and open beta for the Flex technology is now available at http://labs.adobe.com.

Oops! Republished to fix the missing link to the Adobe beta site.

Perhaps it’s because of my recent trip to China, but it is becoming increasingly clear that internationalization is a very big deal for everyone in the software world. The ability to fully enable products and applications for double-byte and bi-directional languages is key.

Enter ICU4J. One look at the JDK to ICU comparison chart reveals why this library exists and is used by so many ISV’s out there today (e.g. Adobe, Apple, BEA, Cognos, Debian Linux, Gentoo Linux, IBM to name just a few).

I haven’t seen a lot of fanfare about this, but I consider including ICU4J in the Eclipse Platform for 3.2 and Callisto to be one of the biggest things going on right now in Eclipse. With Eclipse 3.2, developers are going to have a much more powerful tool for internationalizing their applications. With significantly better functionality than what is supported in the JDK. Now Java applications can be competitive those written in other programming languages in countries such as China, Japan and India. This is especially important for Eclipse and Eclipse RCP compete with Microsoft’s Vista release, as they are clearly focusing energy on ensuring strong internationalization capabilities.

But isn’t the JDK enough? Unfortunately not. From one of the documents from the ICU4J team:

“…as a platform, Java provides support for only a small set of locales (only 21 locales are officially supported, another 73 are shipped by not tested). By comparison, Windows XP SP2 supports 159 locales. In the set of 94 Java locales there is support for only one of the 22 official languages of India, one of the fastest growing economies in the world…”

ICU4J supports and ships twice as many (over 230) locales as Java. And there are other important features as well, such as support for better/faster sorting, enhanced date formats, better calendaring options and the like.

So keep an eye on development with ICU4J. It’s just recently been included in the platform builds. Next is switching the 3.2 stream over to use it, and then for the rest of the Callisto projects to make the jump. The changes are minimal, so hopefully the switch will be relatively quick and painless.

It’s February so that means its election time in the Eclipse community.

Each year, the committer community and the add-in provider community vote for their representatives on the Eclipse Board of Directors. The number of elected reps is calculated using a formula based on the number of strategic members. The formula is 1+(floor(# of strategic members) / 5)). For this year, this means we’re electing four committer reps and four add-in provider reps.

This year there is a great slate of candidates with some very interesting thoughts on how they can contribute to Eclipse by participating on the board.

I strongly encourage everyone within the Eclipse community to get involved in the election by posting questions and comments to the candidates on the eclipse.foundation newsgroup (news, http). Even if you can’t vote, I would love to see some lively threads discussed on the issues.