Life at Eclipse

This is a continuation of last Friday’s post, and is the third installment in my Past, Present and Future of Eclipse series.

No conversation about the present world of Eclipse can omit a comment on the vibrancy of the ecosystem. As I mentioned earlier, I believe that the early (and strategic) decision to explicitly connect an industry consortium to an open source project community is what drives our community’s growth. Certainly our 150+ members are a big part of our community.

Donald Smith wrote a great blog post a while back on Measuring the Health of Ecosystems. In it he quoted a HBR article on Strategy as Ecology, which identified three key elements of ecosystem health.

• Productivity of the Ecosytem — how much economic value is being created by the ecosystem.
• Robustness — how durable and able to adapt is the ecosystem to external events.
• Niche Creation — the ability to expand the ecosystem with meaningful diversity.

Productivity

It would take way more space than a single blog post to talk about the productivity of the Eclipse ecosystem. Let me just say this: my full-time job is to look after Eclipse and keep tabs on what is going on. And it is absolutely impossible to keep track of all the products and services based on the various Eclipse projects. Eclipse is an amazingly productive ecosystem.

Robustness

On robustness, over the years the Eclipse community has dealt with quite a few external events driven by our competitors. Which raises an interesting point: if Eclipse is a free and open community with a diverse commercial ecosystem, who are its competitors? This is a bit of a simplification, but it really boils down to two: Microsoft and Sun.

Microsoft Visual Studio was the product which Eclipse was originally created to compete with. But in many ways, the competition has morphed into co-opetition, as many developers use both Eclipse and Visual Studio. There are a lot of developers who use VS for their .NET development and Eclipse for Java and everything else. So there are actually interesting scenarios where interoperability between Eclipse and Microsoft products makes sense.

The competition with Sun’s developer products is more direct, as in many ways we are competing for the same developer: Java programmers. (Despite the fact that Eclipse does so much more than Java tools, that does remain our key franchise, and commercial ecosystem opportunity.) Visual Studio and Eclipse can complement one another. In most cases, NetBeans and Eclipse are substitutes. As a result, the only major organization dedicated to competing head-to-head with the Eclipse community is Sun.

I thought that Cote’s blog post on Europa did a very good job of summarizing that competition. I’ve certainly never heard a better metaphor than:

NetBeans typically wants to first tell you how to start pounding nails, while Eclipse wants to first tell you about the hammer………For Eclipse, the platform is the killer feature.

But Sun has been gunning for Eclipse for as long as I’ve been around, and although NetBeans has clearly gotten better, the market share and download numbers that we have show only steady growth for Eclipse. Anyone want to bet that NetBeans 6 will be the third (fourth?) release in a row that will be positioned as the Eclipse Killer?

So I personally rate the robustness of the Eclipse ecosystem as very high and still growing.

Niche Creation

The last element of ecosystem health is niche creation, where the technology is rapidly adopted in new technology niches. Don’t get confused: “niche” is not a synonym for either “small” or “insignificant”. Think more along the lines of “new” and “cool”.

Again, Eclipse rates very highly. Eclipse as a platform has excelled in enabling niche creation. Its adaptability has driven growth and success in many new technology niches as quickly as they’ve been created.

Here are just a couple of recent examples:

• According to Linux Watch, there is cross-community interest in rallying around Eclipse as the tools platform for Linux LSB development.
• Within days of Apple shipping the iPhone, Aptana shipped its Eclipse-based (and EPL-licensed) IDE for iPhone development.
• Verigy recently shipped its semiconductor test solution which leverages Eclipse to provide “…an active hardware view, which provides the user with an intuitive, graphical view of the RF measurement block diagram, and the ability to export RF setups to test method templates…”.

Summary

Overall, I am very happy with the state of Eclipse today. We have a challenging mission to create an open development platform, an amazing wealth of development talent amongst our committer population, and a vibrant and healthy ecosystem.

Next up…Futures…wherein I will not necessarily be so consistently cheery 🙂

As promised, here is my attempt to capture the state of the Eclipse community at present. It is an incredibly daunting task to try to do this in a single blog post. But here goes…

The obvious place to start is the recent release of Eclipse Europa. I just checked with Denis, and in our first week we’ve had 400,000 download requests of the various packages. Which is a lot 🙂 Congratulations again to the project teams who worked so hard to make Europa a reality.

There are several exciting things about Europa. Lots of others have blogged about the technical cool bits, and I won’t attempt to repeat them here.

To me, Europa is the current deliverable along the vision of Eclipse becoming the open development platform. It is about Eclipse continuing on the community-led evolution that it has been on for the past several years.

To recap some history:

• 2001: Eclipse 1.0 ships as a Java IDE. At the time, the community was primarily made up of IBM and its partners. But IMHO, the early decision to run Eclipse as a marriage of an open source project community and an industry consortium has been the source of our community’s enduring strength and growth.
• 2002, 2003: Eclipse 2.0 and 2.1 ship and Eclipse begins to really come into its own as a tools integration platform. The consortium around Eclipse starts to grow quickly and begins to show life as a real industry force.
• 2004: Eclipse 3.0 ships, and the Eclipse Foundation is formed. This new version is a watershed because it migrates the plug-in model to the Equinox OSGi implementation and includes the Rich Client Platform (RCP). Eclipse starts to move from a tools integration platform to an application integration platform for the desktop. One of the most interesting factoids about RCP is that it largely came into being because of community interest. Enough people were ripping the IDE bits out of Eclipse 2.1 to build desktop applications on top that it became obvious that doing it once and doing it well was the obvious choice.

Skipping ahead to today, Eclipse Europa’s importance is, in many ways, linked to the emergence of Eclipse as an application integration platform which spans servers and devices. It’s not just the client any longer.

This is not a small thing. It is huge. Eclipse is one of the very few organizations which is attempting to develop a standards-based development platform of tools, runtimes and frameworks which span devices, clients and servers. All of which is based on a single component architecture and programming model.

And once again, it is the community that is driving the evolution. Just as a few years ago when people noticed that could create their own desktop applications and drove the creation of RCP, developers are now noticing the opportunities that running Equinox in, on or under a server.

So today Eclipse is not just about tools or even Java. What our community is building is something which is much more ambitious and interesting. And with new projects such as EPS, SOA RT and RAP starting up, the future looks like even more good fun.

…part 2 will focus on the state of the ecosystem.

Earlier this week I was on the “How Do We Get More Apps on Linux?” panel at the Linux Foundation’s Collaboration Summit. I certainly have to agree with Danese Coopers‘s comments about being on panels. The more questions from the audience, the better IMHO.

As she alludes to, I personally think that #1 sin for any panel member is to be boring. I am always willing to go out of my way to try to keep the conversation lively. It’s always nice to see my efforts noticed 🙂

More seriously, the point I was on at the time was that most ISVs want to add Linux as one of their supported platforms, and need tools and application frameworks to do so. Ideally, those frameworks should allow the same code to be portable across Linux variants, Windows and Mac. There needs to be a way to reduce the development cost and risk of adding Linux as a supported platform. Of course, we at Eclipse think that RCP is a pretty good technology for doing that.

One audience member also mentioned Mono as a technology they had used with great success. Unfortunately, there didn’t seem to be a lot of interest by the distro vendors in the room — other than Novell — in picking Mono up.

Without some sort of “standard” for application frameworks in the Linux world that also supports Windows and Mac, I predict it will remain difficult to attract mainstream app and ISV developers to Linux. I haven’t spent any time looking at it, but perhaps Qt Jambi is another potential solution.

One interesting cultural point of interest: I was pretty careful to always talk about “…tools and application frameworks…” but what resonated back from the audience questions was always just “tools”. I have a personal theory that few people in the existing Linux ecosystem really grok what application frameworks are about and why they’re important for platform adoption. This is classical “Crossing the Chasm” technology marketing, and I got the impression that Linux is struggling a bit with figuring out what it needs to accelerate past the early adopters and become truly mainstream. (At least in the more consumer/desktop space.) Definitely the plethora of distributions with minor variations doesn’t help with adoption. An issue which the LSB will hopefully help address.

Personally, my favorite part of the panel was actually when someone asked why there aren’t Eclipse-based tools to help create LSB’s. I think that’s a great idea and hopefully we can get the communities together to make that a reality.

As announced by Mik and others, the Eclipse Mylar project is changing its name to Mylyn.

This is the end result of quite a bit of discussion and hard work on the part of Mik, the Myl** team, the webmaster team and the legal folks at Eclipse. As described in the FAQ, we are currently going through the process of re-writing our trademark guidelines to include Eclipse project names as trademarks of the Eclipse Foundation. (Aside: the reason the projects cannot hold them directly is that they are not separate legal entities. So the Foundation will hold the project trademarks for the benefit of the projects.)

As we looked at the Mylar name, we decided that renaming the project would be the best long-term decision for the project, its community and its adopters. I have no doubt that there will be some short-term annoyances and I apologize to all impacted. But once the decision was made, getting it done in time for Europa definitely made the most sense.

But in the end, the Mik and his team are moving forward and this project remains one of the coolest things happening at Eclipse. It’s wonderful to have such a talented team as part of the Eclipse community.

As I mentioned a few weeks ago, it’s been three years since I joined the Eclipse Foundation. This is the first installment in a series of blog posts on the past, present and future of the Eclipse Foundation that I plan to write.

Out of curiosity I decided to go back at take a look at the presentation [1] that I gave to the Eclipse Board of Directors at the time. As part of their recruitment process, they wanted each candidate to give a brief talk to outline their interest, agenda and qualifications.

I was actually rather surprised how well the talk has withstood the test of time. Most of the goals and priorities I talked about three years ago seem to be relevant even three years later.

I thought it would be interesting to review a couple of highlights and point out a few things that I got right, and a couple of boners as well. Please let me know what you think. And remember: the points in this presentation were made over three years ago, before I even started working at Eclipse. When you’re looking at the slides, remember to do the Time Warp.

• Towards the end of the presentation I had two slides on what I thought the role of the Executive Director would be, and what values the incumbent would have to bring to the job. I honestly believe they’ve held the test of time, and I will leave it to the readers to tell me how they think I’ve done in meeting those over the past three years. I should mention that what I described as “Business Development” at the time I would now refer to as “Ecosystem Development”. E.g. It is a very large part of the Executive Director’s job to try to drive value and commercial opportunity to the member companies of Eclipse.





• “Eclipse Today” (e.g. Eclipse in 2004): I still think that these points were pretty much spot-on. The most relevant ones were the points about being perceived as IBM controlled and limited marketing presence outside of IBM activities. Later under Short-term Priorities, I mentioned a goal to ““Re-brand” as an independent entity”. To a large degree, that was a very large part of what we accomplished in 2004, leading to the rapid expansion in strategic membership in 2005. Establishing Eclipse as an independent entity took some time and effort. The tipping point was EclipseCon 2005 when BEA, Borland, CA, Sybase and Wind River all joined as strategic developer members.



• There were a few times where I made the point that the the health and vitality of the Eclipse open source project(s) is absolutely key. Although Eclipse is in many ways a trade association or consortium, the source of all value is what happens in the projects. The perfect scenario is where we see a virtuous cycle of growth and investment between the projects and the ecosystem. I believe we’ve made a lot of progress in establishing that. We’ve certainly seen a large growth in the number of organizations contributing code, projects and committers at Eclipse.
• Of course growing the ecosystem was and is an important goal. Our membership has grown to well over 150 companies. Five have joined so far this month!

  Growth in membership is an indicator of the health of the overall ecosystem. But probably even more important is the huge number of products now built on top of Eclipse, with more coming all the time.



• I was mostly wrong when thinking about what I termed as “exploratory” projects for Eclipse.

  I’ve always thought that a sign that RCP was doing well would be someone interested in driving a project to build productivity tools on top of it. Lotus Notes is the first instance of that happening that I’m aware of, and a very impressive one at that. But at the time I was thinking of an open source project and despite a few close calls that has not come to pass.

  Thinking that Mono would be interested in using Eclipse was, in retrospect, naive.



• Up until now at least, I was definitely wrong proposing of system integrators as a potential source of growth. Although they use Eclipse heavily, to date we’ve been unsuccessful in engaging with them to get involved in Eclipse as either members or contributors.

[1] In the interest of full disclosure, I should mention that I made a few edits to the original presentation. I added “March 2004” to the first slide. I deleted several references to personnel decisions in the interest of privacy. And I deleted one slide which referenced confidential information. Everything else is as it was.