Archive for April 2006
No, that’s not the name of a new committer 🙂
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.
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.
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.
The Eclipse community suffered a great loss this weekend with the passing of Kim Clohessy. Within Eclipse, Kim was one of the leaders of the Open Healthcare Framework project. But for many of us who have deep roots with OTI, Kim had been a friend, mentor and colleague for many years.
I just received a note from Linda Campbell at QNX, who said it better than I ever could:
I am sad that I never told him personally how grateful I was for everything he did for me…. He was a very good man. In addition to being a visionary, he was kind, generous, honourable, loyal, and trustworthy. I feel very lucky to have had the chance to do business with him and to learn from his wisdom and experience…left his mark on all of us, and an entire industry to boot.
It was only ten months ago that Kim joined John, Jon and I on our annual Northern Canada fishing trip. I will always remember his good humour and good company. He didn’t catch the biggest fish (see photo), but you couldn’t ask for more enjoyable company if you’re going to spend twelve hours in a small boat.
He will be missed.
For those who knew Kim, at the request of his family donations can be made to the American Melanoma Foundation.
Unfortunately, Eclipse.org is also starting to exhibit similar cracks. A cursory look at the architectures of many of the top level projects (WTP, STP, TPTP, BIRT etc.) shows the lack of intra-project cooperation is resulting in frameworks that simply don’t integrate with one another in they ways we all want them to. I’m not sure whether the PMCs are responsible for this failure or if it is also the committer’s responsibility to “fit in” to the larger Eclipse eco-system better.
My sense is that this is an interesting dilemma for Eclipse. On one hand, some want Eclipse to be a highly integrated platform with a seamless experience across platforms, languages and lifecycle. (Callisto is a modest step in that direction.) On the other hand, as an open source community some focus on diversity and innovation and are uninterested in the heavy hand of centralized authority.
Sort of a Cathedral versus Bazaar dilemma.
So what do you think? Where do we need to find the balance within the Eclipse community?
Interestingly, Callisto is an example of where the Bazaar worked in interesting ways. The idea to do Callisto came from the projects themselves. It was not an idea that came from the Eclipse Foundation.
I get to join Ian at the Embedded Systems Conference (ESC) this week. I spent several hours today walking the exhibit floor looking for Eclipse-based tools and products. They’re everywhere! I am really miffed with myself for forgetting to bring my camera.
Just a partial list of companies showing Eclipse-based tools are: QNX, WindRiver, Aonix, AMD, DDC-I, ENEA, IBM, KlocWork, LynuxWorks, Mentor Graphics, MontaVista and TimeSys.
The icing on the cake was discovering that Eclipse was the cover story for the issue of Embedded Systems Design being distributed at the conference. We had no idea, so it was a very welcome surprise.
I know that many people associate Eclipse with enterprise development tools, and more specifically with Java development, but the number of companies in the Eclipse ecosystem engaged with embedded and device software is massive. For most of these companies, the ability to build their tool chain by extending the Eclipse Platform and/or the C/C++ development tools (CDT) is a great enabler for their platforms.
Many thanks for Doug Gaff (WindRiver), Anders Florin (ENEA) and others who helped staff the Eclipse booth today.