Eclipse, a new model for open-source innovation

As I told Mike Milinkovich, executive director of the Eclipse Foundation, my understanding of Eclipse is several years old. I called him today to get an update on Eclipse, and learn what all the fuss is about.

As it turns out, quite a bit.

Eclipse may be the most important open-source "project" that people outside the industry, and even some within it, have never heard of. Here's why.

Eclipse started small, though with big aspirations. It was originally created by IBM in 2001 and is now supported by more than 150 large and small software companies. In late June, Eclipse made available the largest-ever simultaneous release of open-source software, called Europa: 17 million lines of code, representing the contributions of 310 open-source developers in 19 countries. Twenty-one new tools were included in the Europa release, all free to download.

Think about that. The Linux kernel has around 6 million lines of code... The Java Development Kit that Sun open sourced has 6.5 million... Sun's StarOffice release in 2000 (which was believed to be the largest open-source release to that point) had 9 million... Firefox has 2.5 million. Europa, for its part, is more than double the size of last year's Eclipse release, code named Callisto (like Europa, it was named after a moon of Jupiter).

Getting such a massive release out the door (and on schedule) required coordination on a huge scale that's usually only attempted by large commercial software companies, and often unsuccessfully (Can you say Vista?). But it's never been tried by the open-source community.

Even more intriguing, this coordination happened between widely diverse companies, including fierce, bitter competitors, as Mike noted:

The interesting wrinkle about Eclipse from a business perspective is that it's in our DNA to care deeply about commercial adoption of the technology. It's not a side effect of what we do - it is what we do. I can't think of another open-source organization with the same mission and system for achieving that mission.

This might not be a big deal if Eclipse were still simply about development tools. You need to step out of your comfort zone as to what Eclipse is. It's no longer just about development tools. Eclipse now houses a wide range of "runtime" projects like application frameworks (service-oriented architecture (SOA) frameworks, etc.) or things one would expect to find in a Java application server.

We've come up with a way to help multiple companies - including direct competitors - to work together on a level playing field to build next-generation platforms and then compete with the applications they build on top of this platform. In other words, they use Eclipse to collaborate on a platform and then compete on the products that run on the platform.

Importantly, we're not just talking about enterprise software. In fact, Eclipse is now the standard for C/C++ development in the embedded/mobile market (the only real-time operating system company that hasn't standardized on Eclipse is Green Hills). So, in the mobile/embedded space we have Symbian, QNX, Wind River, Nokia, and others working together on common platforms, then aggressively competing on the products they build on top of these platforms.

Given some things that I've said recently about Mozilla, it was surprising to me to hear how well Eclipse seems to run. And so I asked Mike, "Is this perhaps the first real open-source collaboration platform? And is it a better model than other collaborative projects like the Linux kernel and Apache?" After all, Linux is a bit of a benevolent dictatorship, with vendors like Red Hat essentially controlling it at the distribution level. MySQL is a corporate governance. Mozilla is a foundation that (mostly) acts like a software company.

Then, from a licensing perspective, Eclipse is very pro commercial/downstream adoption. It uses a permissive copyleft license which allows an ecosystem that's either commercial or open source. Like Apache, it doesn't try to nudge users one way or the other. With MySQL or JBoss, or other GPL-type communities, it's hard to cross over. Is Eclipse better?

It's not better, just different. The difference is that things like Apache and Linux allow competitive collaboration as a side-effect of the projects. They say it's OK if you collaborate, because the license allows such.

But Eclipse has a corporate membership model that has resources (16 full-time staff) to help proactively foster collaboration. Also, the way we're set up and the way our organization is defined, we're explicitly set up and tasked with fostering collaboration and commercial adoption of our products (and commercialization of the application written on top of what we do).

You read the literature on ecosystems and there's always this expectation that there's a for-profit organization at its core that essentially makes things work. In the Eclipse context, at its heart is a not-for-profit organization with an open-governance and open-licensing model. Having a not-for-profit organization at the heart of Eclipse makes a big difference.

And so I asked the natural question, Is that why Eclipse needed someone from outside the United States to run this in order to remove the American greed taint?

[Mike laughs.] I think there's real value to being based outside the Bay Area. There's just something about Silicon Valley - everyone drinks the same Kool-Aid...

Besides, most of our downloads come from Asia-Pacific and, secondly, EMEA. North America comes in third. In terms of countries, China just surpassed the U.S. as the top download site for Eclipse, with the United States in second, and Japan and Germany tying for third/fourth.

[Matt note: This was interesting to me since most open-source vendors have these numbers completely inverted. Most software vendors - open source or proprietary - in fact, normally do most of their business in the US, secondly Europe, and thirdly Asia-Pacific. It's very interesting how different Eclipse's pattern is.]

All very well, but I wanted to dig into why Eclipse has succeeded where Open Source Development Labs (OSDL) and other industry organizations have miserably failed?

We're more of a standards group than an open-source project group. We're structured more like a standards group than a traditional open-source project group. But unlike a standards organization, we're not shipping specifications. We're all about the code. When I look at open-source communities, I look for code. Does the community help to get code in the hands of developers?

OSDL was a corporate consortium but it didn't actually host open-source projects. But it also also wasn't a real standards organization. It was neither fish nor fowl. That sort of fuzzy mission probably caused them to have problems. We're member-supported and member-funded with a very clear mission: ship code that our members can build upon.

Back to how Eclipse works with its member companies. I asked Mike, How do you decide what comes next? That is, which projects to fund and build?

Project proposals come organically from the broad Eclipse community. We no longer actively recruit projects, because we don't need to anymore.

All Eclipse projects are built in terms of Eclipse plug-ins. All share this common architecture. One of our questions, then, for any new proposals for Eclipse plug-ins is, will they build it in this way? If no, we're not interested.

If yes, there is a well-defined process for how things make their way into the Eclipse family. You can track proposal status on the Eclipse site. The entire process is highly transparent, which tends to greater success for Eclipse and its projects.

Talking with Mike, Eclipse is clearly extremely important in the software industry because, from an economic point of view, the software business model has a fundamental problem (unless you have monopoly profits like Microsoft). It is this: a relatively small part of a software vendor's research and development budget goes to software that customers actually care about. A lot of money is spent reinventing the infrastructure wheel.

Eclipse allows the industry to standardize much of this infrastructure so that vendors can compete on innovation and product features that move businesses forward. This fact allows Eclipse to overlook the free-rider problem that might normally plague an organization with its mission:

Free riding happens, but it hasn't been an issue that has caused us any major problems. Every biological system has natural things like symbiotic relationships, parasitic relationships, etc. Those same things happen in the Eclipse ecosystem.

But the advantages of working with Eclipse to get things done far outweigh the advantages of getting something for free. Do you really want to rely on someone else to fund a project to solve someone else's customer problems, rather than yours, and leave it to a process that may take more time than you have?

But it's not just a time/money tradeoff, but rather a question of what is platform and what is product? Building proprietary infrastructure is rarely a good idea anymore. If a vendor is wasting R&D money on infrastructure then they are both wasting money and time, both of which could be better employed building on Eclipse.

If someone is going to make something proprietary, they need to be really, really sure that it's giving their company sustaining, differentiating value. If they're just reinventing the wheel, it's the wrong business move 99 percent of the time.

Fascinating, fascinating stuff. As I think about it, it's not that a profit motive isn't involved in Eclipse, but rather that Eclipse is the channel for the diverse profit motives of its members. By focusing on platforms upon which its members can compete, Eclipse does a great job of balancing its members' self-interest with a fantastic group product.