Life at Eclipse

Well dropping by the Eclipse booth this afternoon really made my day.

On the first day of the exhibit hall being open, the interest in the Eclipse Passport and the Eclipse t-shirts has been awesome. When I dropped by there was a line of at least twenty people there waiting to pick theirs up. And wandering around I’ve been bumping into lots of people wearing the Eclipse buttons from the various sponsors.

All in all a great success already! It is huge fun to see the community in action.

Hats off to the Eclipse marketing committee and the sponsoring member companies for making this such a great show of Eclipse community support.

Hot on the heels of my last post comes some very exciting news about the use of Eclipse in the Rich Internet Application (RIA) space.

In my last post I talked about how James Governor‘s post on RCP showed that he really understands some of the potential of the Eclipse Rich Client Platform (RCP) technology.

This week’s big news is the announcement that “Macromedia plans to deliver a next-generation rich Internet application (RIA) development tool based on Eclipse.”

Tim O’Reilly has some great things to say about this announce.

Macromedia’s announcement that their next generation enterprise Flash development tool, code-named Zorn, will be built on top of Eclipse, is a watershed moment both for Macromedia and for the open source movement. Macromedia’s choice of Eclipse speaks volumes about the impact of open source on commercial software development — and about Macromedia’s commitment to making Flash into an essential platform for next-generation internet applications.

When you add to this the fact that Eclipse also used as the tooling platform for OpenLaszlo, and it is clear that Eclipse has a very important role to play as the RIA space evolves.

If anyone has any ideas on how Eclipse could also support tooling in the Ajax area, please let us know. Maybe there’s something already going on, and I just don’t know about it?

It is always great when the Eclipse community works hard on communicating a new and novel idea and then runs into someone who really understands it. James Governor‘s blog post today on RCP is a great example of that.

James is focused on the potential for RCP to dramatically change the playing field for rich client applications. We are starting to see lots of examples of applications popping up all over. And developers are comparing Eclipse RCP against some alternatives that we hadn’t even thought of, such as XUL. (Note that this is not in any way meant as a slight on XUL. I just find it fascinating that a development team even considered them competitive technologies.)

So where is this going?

Amongst other interesting possibilities, Eclipse RCP has the potential to be the best friend the Linux desktop has ever had. For Linux to really take off on the desktop, it must dramatically increase its share with both ISVs and enterprise developers.

ISVs need RCP because it allows them to build native applications which run on Linux and Windows. No ISV that cares about either expense or quality is going to maintain completely different code streams for products on both Linux and Windows. RCP offers them a great technology for building truly native applications which run on multiple platforms.

Enterprise developers face a similar issue. It will take a long time for large enterprises to roll out Linux desktops in their organizations. Co-existence with the incumbent (usually Windows) for their applications must be a key part of any strategy to migrate to desktop Linux. Not only does RCP provide IT managers the ability to build and deploy multi-platform native apps, but it allows them to manage those deployed applications.

The resurgence of Apple as a client platform that really matters makes this even more interesting, as ISVs in particular would like to ideally target all three of these platforms. Which makes the RCP story better still.

But the best part of the Eclipse RCP is that it is here now and it is very real. No waiting on Longhorn or Mustang required. The new Eclipse 3.1 is bringing better tooling support and loads of new features in just a few weeks.

So we are preparing for our Phoenix project Creation Review next week. There has certainly been a lot of interest in this project and in improving the eclipse.org website. If you don’t mind a little strong language, you can check out these comments from one frustrated user. His comments are strongly worded, but certainly poke at some well known deficiencies. I laughed so hard I had tears in my eyes the first, second and third time I read it. But then again, I do have a fairly twisted sense of humour.

Apparently, we have no where to go but up. 😀

Like I’ve said before, our website is showing its age. What started out three years ago as basically a one project community has grown to be something quite a bit larger and more complicated.

Getting rid of frames and moving to an F/OSS content management system are two key requirements we have. Right now it looks like Xoops is leading the pack for us. Has anyone out there had either positive or negative experiences with Xoops?

So this week in Mike’s excellent travel adventures, I am in Portland, Oregon for the gathering of the Eclipse Councils. We’ve just wrapped up three days of meetings of the Requirements, Architecture and Planning Councils.

I am not sure how widely recognized Eclipse is for the ground-breaking work it is doing in creating a commercially-friendly, predictable open source community. Some of the things we are working towards are truly unique.

First, Eclipse is interested in co-ordinating the activities and release schedules of a great number of projects within its community. What we agreed to this week is to attempt to ship pretty much all of our mainline projects on a single combined release schedule. We are already doing this in many ways. This year Eclipse 3.1 is shipping in late June and CDT, EMF, GEF, BIRT, TPTP and WTP will be shipping very soon after. Where “very soon” = 30 days or less. For future major releases we are going to try to pull that in to within 15 days or less. The highly ambitious goal is same day. AFAIK, this is unparalleled within the open source world. In fact, given the quantity and complexity of the software involved, this would be a huge accomplishment for a single -vendor commercial software project.

A large part of the conversation this week was centred around what quality means for Eclipse projects. The Requirements Council came up with this broad outline:

• Production quality: the usability, performance, scalability of the software must be production-ready quality
• Long term API stability
• Predictability: it matters a great deal to our consumers that Eclipse releases are shipped on a predictable schedule
• IP due diligence: Eclipse is setting the high water mark in open source IP due diligence
• Demonstrable community involvement and participation

I would certainly be interested in hearing any feedback on this list.

The Councils also spent a lot of time focusing in on APIs and what our expectations are for API quality for new projects.

The common perception is that Eclipse builds tools. In fact, what our projects do is far more ambitious. Eclipse projects are expected to build frameworks and extensible tools with well-defined APIs which allow for others to build world-class tools. Then we build an exemplary tool to demonstrate what can be built on the API. This is much harder than just building tools.

But it is this focus on APIs, plus the Eclipse plug-in architecture, that have made Eclipse so attractive for commercial tool builders. They know that Eclipse projects are going to provide them well designed APIs which will be maintained and supported for the long term. This can be a tall order for a new project, but everyone has bought into the commitment and are marching towards this goal.