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.
