Life at Eclipse

…and check out the new Google Web Toolkit.

Not only does it have some really cool AJAX-enabling technology, it ships both JDT and SWT. The embedded GWT browser is built with SWT for use during development.

From an email from Bret Taylor, the PM on the project:

GWT has two components: a Java-to-JavaScript compiler, a command line tool that translates Java to JavaScript; and a “hosted web browser,” a special web browser used to debug GWT applications … The hosted web browser uses SWT since it has a UI. It is a very simple UI (a window, toolbar, and embedded browser control, basically).

So last week was two conferences:

1. JAX/Eclipse Forum Europe in Wiesbaden, Germany. (A beautiful city, by the way.)
2. LinuxDays.ch in Geneva, Switzerland.

While at JAX, the editor of JavaMagazin, Alexander Neumann presented Eclipse with their Reader’s Choice Award for Best Open Source Project. Congratulations to the entire Eclipse team!

This week I’m off to JavaOne, where Bjorn and I are giving a talk on the Callisto Simultaneous Release. If you’re there, please say hi, and don’t forget to join the party at the Thirsty Bear.

I, like many others, have enjoyed reading Ed Burnette‘s recent series on Sun joining Eclipse.

Personally, I think it would be great to have Sun join Eclipse. It is obviously one of the questions I’ve been asked a lot since starting at Eclipse, and my answer has been the same since the beginning: Sun would be welcomed with open arms. Eclipse is an open community, and everyone can join. And Ed is definitely correct in pointing out all the wonderful stuff that NetBeans could offer if the communities were working together.

There was one paragraph in Ed’s latest post that I did think was off the mark, however.

History is replete with examples of “mortal enemies” becoming fast friends. And in a world with Microsoft, Ruby, PHP, Linux, Web2.0, and other forces knocking on the door, these two need all the friends they can get.

First, Eclipse is absolutely not in competition with Ruby, PHP, Linux, et al. They are just additional languages and platforms for Eclipse to work with. RadRails is a great example of a cool tool built with Eclipse that embraces Ruby, rather than tries to compete with it. The Eclipse Linux initiative is another great opportunity for co-operation, rather than competition. And, of course, there are great things happening with PHP and Eclipse. In fact, I would go so far to say that Eclipse’s willingness to embrace all of these different platforms is one of the key strengths of our community. Sun has a vested interest in promoting Java against Ruby, PHP, etc., but Eclipse clearly does not.

Secondly, even in quotes, I don’t like to chararcterize competitors as “mortal enemies”. Sun and NetBeans are following a path which they believe is a sound business strategy. I personally think that co-operation would be better than competition, but hey, it takes two to tango. But I’ve met quite a few of the NetBeans folks, and they seem like perfectly nice guys doing their job. A little friendly competition never hurt anyone.

P.S. We’re not changing the name.

No, that’s not the name of a new committer 🙂

Project Antoine is a really interesting idea. UBC is running Project Antoine to collect information on how people are actually using Webtools. The information will be used to improve usability.

If you’re an Eclipse WTP user, please help out by installing the plugin (based on Mylar) that tracks user interactions.

So John Graham is asking a question that I have seen repeated in various forms many times before. In a nutshell, should Eclipse projects focus on (a) building a well-architected platform or (b) building great tools for end-users to pick up and use “as is”?

Believe it or not, I don’t see this as a controversial or difficult question. It’s been asked and answered. In fact, it is spelled out directly right in the first paragraph of the Eclipse Bylaws:

The Eclipse technology is a vendor-neutral, open development platform supplying frameworks and exemplary, extensible tools (the “Eclipse Platform”). Eclipse Platform tools are exemplary in that they verify the utility of the Eclipse frameworks, illustrate the appropriate use of those frameworks, and support the development and maintenance of the Eclipse Platform itself; Eclipse Platform tools are extensible in that their functionality is accessible via documented programmatic interfaces. The purpose of Eclipse Foundation Inc., (the “Eclipse Foundation”), is to advance the creation, evolution, promotion, and support of the Eclipse Platform and to cultivate both an open source community and an ecosystem of complementary products, capabilities, and services.

Pretty clear, isn’t it? The primary focus for Eclipse projects is on building great frameworks. The tools are important, but they’re there mostly to demonstrate the utility of the underlying Platform. Furthermore, the tools themselves need to be extensible via well-defined APIs.

Does that mean that also producing great tools is unimportant? Not at all. Here’s another quote from the quality section of the Eclipse Development Process:

Note the Eclipse Quality is about both extensible frameworks and exemplary tools – great tools are important for attracting the users, who then attract the ecosystem, that then provide members, who then contribute resources, who then create additional valuable frameworks and tools. Neither frameworks without users nor tools without frameworks are interesting points along the software development spectrum.

So user adoption is the second key element to determining success for an Eclipse project.

It’s hard for a new project to balance this equation in order to achieve uberness. There are a lot of competing demands for time and resources, and certainly the user community is not the least bit shy in asking for lots of new tooling features.

As John himself points out, part of the problem for new projects is the great success of the original Eclipse project. People immediately expect new projects to provide the same level of polish and function that you can see in JDT, PDE and RCP. But the fact is that those projects have had going on seven years of development invested in them from one of the best teams on the planet. A team that had worked together for quite a few years before even undertaking Eclipse. I actually think that the newer projects (see BIRT for example) are evolving quite nicely, but it takes years to build lasting success, not months.

Properly setting expectations for how long it takes for new projects to mature is a never-ending struggle. But I think that both Eclipse’s mission and its history makes it clear that the right ordering for the focus of new projects is platform first.