Life at Eclipse

I’ve been watching the GPLv3 process since its inception, and I have to admit that I am getting rather disappointed with some of the dialogue surrounding it.

At the risk of stating the obvious, the FSF is completely within its rights to change the GPL, and they deserve high praise for the open process they’ve used in driving new revisions. The Eclipse Foundation has been involved in the process, with Janet Campbell participating on “Committee A”, since the beginning. We’ve had several open and cordial conversations about EPL and GPLv3 compatibility over the past year as well. All of the right conversations have happened with all of the right people. In the end, however, we had to agree to disagree and the EPL and GPLv3 will not be compatible.

So I was surprised to see the comment in the latest draft that the FSF “encourages” us to “… revise the EPL to permit re-licensing under the GPL”. That’s never going to happen. Our contributors and ecosystem picked the EPL for solid business and community reasons, and there is zero interest in taking all of our community’s intellectual property and re-licensing it under the GPL.

Then I read comments from Matt Asay that basically says that anyone that doesn’t support the GPL and the narrow list of business models it supports is somehow “silly”. Although he only talks about Apache in his post, by extension I am assuming that he thinks that IBM’s support of Eclipse doesn’t count. They’ve certainly “given back” to this community. And I definitely do not understand how he could possibly interpret Mills’ comments as demanding that “…the open source world should capitulate to his whims…”.

Matt further points out that some have figured out how “…to monetize open source directly.” How that implies that every other company and community has to embrace the GPL is beyond me. Here’s a newsflash: many companies have also figured out how to directly monetize open source under the Eclipse and Apache licenses as well. Monetizing open source software is not unique to the GPL.

So here are some facts that I think people need to keep in mind:

1. Free software != GPL. Free software is a principle, and the GPL is one expression of that principle. It is not and cannot be the only one. If we replace the monotony of proprietary software with the monotony of a single free software license, we are all losers. Diversity of licenses allows diversity of business models and diversity of competition. Which is a very good thing for the entire community and industry.
2. GPL != copyleft. There are quite a few other copyleft licenses (both “strong” and “weak“), the EPL being one. Not everyone agrees with the specific copyleft approach of the GPL. “Giving back” to the community can be done without requiring strong copyleft. One of our community’s objections to the GPL is the position that it is reasonable to link 5 lines of GPL code to 1 million lines of EPL code and shazam! the result of this hypothetical combined work would need to be GPL’d.
3. GPL != monetization. There are a great many successful companies built on top of the GPL. But in addition there are also some very successful business built on top of other licenses such as the EPL, Apache and MPL. The Eclipse community has built a very successful commercial ecosystem around the EPL, largely because its terms allow greater flexibility and a wider variety of business models. As the title of this post suggests, I would argue that the EPL is the business-friendly copyleft license.

So while the GPL community can be quite rightly pleased with itself on completing GPLv3, I hope that they keep the dialogue with other communities positive and respectful. The open source community is a big place, and there is room for many different viewpoints, licenses and business models.

P.S. I’ve already wasted 20 minutes fighting with Blogger’s random font and font color changes, so apologies if this post looks kinda goofy. This might be the last straw….Wordpress here I come!

Voting for the 2007 Eclipse Board of Directors positions is now open! There are many wonderful candidates for the positions, so please make sure to take the time to vote if you are a committer or add-in provider member.

If you believe that you are entitled to vote and have not received an email with your credentials, please contact us. Despite our best efforts, our record keeping is not perfect.

In an interesting demonstration of the dangers of (what appears to be) auto-generating blog content, the site Modeling Agencies has picked up references to EclipseCon 2007. We do, of course, love to see viral marketing for EclipseCon and heartily encourage regular readers of this particular site to join us at EclipseCon!

The Modeling Project charter is posted here and inherits from the Eclipse … Attend presentations on modeling projects at EclipseCon 2007. …

Hmmm. I wonder if the NetBeans Girls came to EclipseCon 2006 because of this site? 😀

My keynote last week at Open Souce Meets Business in Nuremburg was on a topic that I think bears repeating. Namely: what are the keys to Eclipse’s continuing growth and success? This is at the ten-thousand-foot-level I’m talking here, and definitely not with my technical hat on. This is about the positive business drivers that bring organizations to Eclipse.

I believe that the two main reasons why so many companies are participating at Eclipse are these:

1. The Eclipse community has established the best existing model for multiple corporations to create innovation networks, enabling co-operation on the development of product-ready open source software.
2. Eclipse has a proven track record of helping companies get started with open source, and assisting their migration to the next level of open source maturity.

First, what do I mean by an “innovation network”? Basically, I’m talking about the concepts promulgated by Henry Chesbrough in his books Open Innovation and Open Business Models. The basic notion is that firms need to treat their R&D as an open, rather than closed, system. Disregarding his lengthy discourse on patents and intermediate markets for intellectual property, I believe making his vision a reality requires a business model for companies to particpate in joint development. As I think of it, an innovation network exists where there is a interconnecting web of both collaborative production and consumption of innovation. Companies are attracted to Eclipse because it provides the best existing mechanism available today to do this.

For concrete examples of what I mean, I encourage you to take a look at the contributors and consumers of projects such as Web Tools and CDT.

As Chesbrough defines the term “business model”, there are two elements: value creation and value capture. (“Value capture” means “make money”.) The predictability, licensing model, open governance and vendor neutrality of Eclipse makes it possible for direct competitors to collaborate on value creation for technology which they require for their products, but which are not necessarily key product differentiators. I cannot possibly stress enough the importance of open governance and vendor neutrality in enabling value creation.

Value capture then occurs by adoptors shipping products and/or services based on this shared technology. Although this seems obvious, Chesbrough believes differently:

Open Innovation is sometimes conflated with open source methodologies for software development…While open source shares the focus on value creation throughout an industry value chain, its proponents usually deny or downplay the importance of value capture. (Open Innovation: Researching a New Paradigm)

Not so at Eclipse. In fact, our community embraces value capture. We want to see commercial adoption and go out of our way to facilitate it. There are two key pieces of evidence to support this:

• The first is the expectation that Eclipse projects ship solid frameworks and well-constructed APIs. Of course, due to factors such as maturity and resources the mileage varies from project to project. But the expectation is there across the Eclipse community, and is enshrined in our development process. This is probably the least understood element of Eclipse as to the casual observer, Eclipse ships tools. In fact, our community first and foremost strives to ship product-ready frameworks and components. The tools are there to demonstrate the utility of the frameworks and to help drive adoption in order to enable to creation of a full ecosystem of users, extenders and vendors.
• The second is our annual release trains. Our community’s success in shipping an every-increasing stack of product-ready technology on a regular basis provides commercial consumers of Eclipse projects with something they crave: predictability. If we want companies to build products on top of open source projects, they need to know that they can build their product plans with a reasonable degree of certainty that the community dates will be met. When combined with those key elements of open development — openness, transparency and meritocracy — predictability is a key part of the success Eclipse has had with respect to commercial adoption.

So to return to the beginning: Eclipse enables innovation networks focused on value creation in the form of product-ready technology and value capture in the form of commercial products and services.

It is important to note that that the key elements in Eclipse’s governance, licensing and development processes pre-date my tenure at Eclipse. So full credit goes to the folks who worked on the Eclipse Foundation Bylaws and other core documents. You’ve created something pretty special.

Coming next: part two on Eclipse’s track record in helping companies get started with open source.

I ran across a post by Joel West which I both agreed and disagreed with. He was commenting on a previous post by Matt Asay on the importance of community to any organization that wants to portray itself as truly open source.

The obligation of a real open source company is to create governance structures which allow external participants to feel that they have the full right to participate and influence the outcome of the open source project; the best example of this is what IBM did with Eclipse.

So first the part I agree with. Yes, I think that Eclipse’s vendor-neutral, open, governance structures are a huge part of its success and the best example existing today on how to enable an open source ecosystem. And yes, I believe that IBM (and others!) did a great job when they established the Eclipse Foundation. As I’ve said many times, governance matters.

But I do feel that it is incorrect to compare the Eclipse Foundation to an open source company. Eclipse is a not-for-profit. That is a huge difference. No matter how much an open source company behaves well, and acts in the interests of its community, its role is to make money for its shareholders. Or in the terms used in Open Business Models, the business model of open source companies is based on capturing value created by its community.

At the Eclipse Foundation, we work not to make money for the Foundation itself, but to look for ways to make money for others: namely, our members and the broader Eclipse ecosystem. Or in other words, our role is to enable others to capture value from the technology and innovation developed within the Eclipse projects.

That’s a big difference IMO.