Life at Eclipse

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.

On Saturday morning I had a chance to both attend and speak at the first BarCamp Ottawa.

For anyone who’s ever wondered if these BarCamp “unconferences” really work, the answer is a most emphatic yes. The talks I went to were great. And at what other event could you attend both a talk on Aspect-Oriented Programming and The Future of the Telephone?

The event was well worth the time investment and — scheduling gods permitting — I am already looking forward to attending the next one.

And thanks, Alec for the kind words on my talk.

One of the most interesting new products being built on top of the Eclipse RCP is the new version of IBM’s Lotus Notes client. Dubbed the “Hannover” release, it is a complete significant re-write of the Notes UI on top of RCP. (Or more accurately on top of Workplace Client which is on top of RCP.)

The screenshots (you can see some here and here) really drive home the fact that you can build very compelling rich client experiences with RCP. This stuff looks nothing like Eclipse. Which is very much the point.

Last week Mary Beth started a new blog focused on the UI design for the client. In a short week, she has gotten dozens of responses from the community, plus at least one lively debate.

It’s definitely worth watching as it evolves.

Change note: As pointed out by Richard Schwartz, I was incorrect to characterize Hannover as a complete re-write.