Life at Eclipse

There’s been a bit of conversation going on between Savio Rodrigues and Angry Bill Burke about the value of trademarks this week. This is rather timely, given the recent update to the Eclipse Foundation Trademark Guidelines and the parallel conversation about “CDT for Windows” going on between Ian Skerrett and Doug Schaefer here at Eclipse.

I have to admit that when I first read Angry Bill’s take on trademarks I thought that he just didn’t get it. On my second read, I realized that he gets it all too well.

You see, trademarks are a control point. One that JBoss use{s|d} to great effect. But as Savio pointed out, what Bill sees as a problem is actually exactly the outcome that communities such as Apache and Eclipse want to achieve. Open source startups and their VC backers want to create barriers to entry, and trademarks are a way to do that. Communities want to lower barriers of entry to projects in order to foster diversity and adoption. Different motivations result in different approaches. Bill wants to make money for his company. We want to make communities that make money for many companies.

In many ways, this is part of the larger conversation on what “open source” means. Open source companies and open source communities both use the term “open source”, but they mean quite radically different things by the term. Even if they all share a common licensing definition, there are quite different development, community and IP processes in play that make them distinct models. We really do need a new lexicon, because this is very confusing to anyone outside the FLOSS cognoscenti.

As the Eclipse Trademark Guidelines state:

The Eclipse Foundation holds the trademarks for the project names and logos on behalf of, and for the benefit of, the Eclipse projects. The individual projects are not separate legal entities and thus not able to hold trademarks individually. The Eclipse Foundation is a legal entity and thus holds the trademarks on behalf of the projects.

Our (somewhat belated) goal is to reduce any possibility of confusion between what is coming from Eclipse and what is coming from a commercial adopter. Or for that matter, an open source fork hosted at another organization.

Angry Bill may think this “sucks”, but it’s how communities foster involvement and participation.

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.