Life at Eclipse

IANAL, not even on TV.

I noticed an article in InformationWeek that asserts that the Eclipse Public License (EPL) and GPLv3 are compatible. Although I think that it would be a good thing if it was easier for the two communities to share and re-use code, the article is (sadly) incorrect. The licenses are not compatible. At least not in the same way that the Apache license is compatible with the GPLv3. (In case you’re wondering, this is also the position of the FSF itself, although it’s obvious as their license page has not yet been updated for GPLv3.)

I theorize that the confusion may have resulted from the popular misconception that the ASL and EPL are very similar licenses. They’re actually not. Although they are both “business-friendly”, the ASL is a BSD-style license whereas the EPL is more a Mozilla (MPL)-style copyleft license.

License compatibility is an extremely complex topic. The FSF defines two quite different things: license compatibility and GPL compatibility. The latter basically says that a license is compatible with the GPL if it allows its source code to be re-licensed under the GPL. It is this level of compatibility that led Sam Ruby to quip that “The GPL V3 license is compatible with the ASF V2 license in precisely the same way that blood type AB is compatible with blood type O.” (I think he was specifically referring to the one-way arrow on this diagram. Apache is the universal donor. GPL is the universal recipient.)

As defined, the EPL is definitely not “GPL compatible” (see Section 3 of the EPL).

However, for many developers “compatibility” may mean something quite different. As much fun as cutting-and-pasting code can be, many developers in many contexts prefer to follow component-level re-use. For example, the not-quite-official-but-relevant-nonetheless Apache Foundation policy on third party licensing endorses the use of EPL-licensed binaries in Apache projects. For many developers, this level of license compatibility is sufficient, because it allows re-use of a component they would otherwise have to re-implement.

I have had a few conversations where people have expressed the opinion that this second type of EPL-GPLv3 compatibility may be possible under certain circumstances. So one of my summer projects over the next couple of months will be to work with our lawyers to see what might be possible.

BTW if you think that licensing complexity is only an issue in open source, you definitely need to read this post on Microsoft’s Byzantine licensing regime. At least our stuff is free 🙂

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.