Life at Eclipse

This week, Borland made some very audacious moves when they announced an acquisition of Segue and a divestiture of their IDE tools business. As others have commented, this does not mean the end of JBuilder or Delphi, but these are certainly bold and strategic moves.

I can still recall using TurboPascal almost twenty years ago and thinking it was one of the coolest things I’d ever seen. Borland’s contribution to our industry have been large, and I believe that they deserve a great deal of recognition for what they’ve accomplished for developers everywhere with Delphi, JBuilder and other products.

From what I’ve seen of the commentary so far on Borland’s announcement, it appears that many are missing a key point: from everything we’ve seen and read, the future of Borland will be based on Eclipse technology. Last March, Borland announced that it was going to be moving all of their lifecycle tools onto the Eclipse platform and they’ve been working on that since. Many of their tools such as the clients for Together, CaliberRM and StarTeam have been built on Eclipse for quite some time. Borland has, and continues, to generate significant revenue from products based on the Eclipse technology.

It is important to realize that Eclipse has created a strong, growing and diverse ecosystem. Companies like Borland exemplify how they can work with the open source community, build on a standard framework, and provide commercial innovations for the benefit of the industry and customers.

Borland’s contribution to Eclipse remains strong. Just recently Borland and IBM proposed that they co-lead a top-level project at Eclipse to consolidate the many modeling-related projects at Eclipse. The GMF project led by Richard Gronback of Borland has a great community building around it and starting to release some pretty exciting code.

To date, Borland has not been involved in the Application Lifecycle Framework project. However, Segue has been involved for some time. I am hopeful that going forward, Borland will continue and build upon Segue’s investment there and become a full participant in the project.

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.