Life at Eclipse

Musings on the Eclipse Foundation, the community and the ecosystem

Archive for the ‘Strategy’ Category

Introducing Eclipse Labs

Back in December, I discussed a number of initiatives that the Eclipse Foundation was going to be working on in 2010. The one that attracted the most feedback was “Eclipse Labs”. Well, we are very happy to announce that thanks to Google, this idea has become a reality. Better yet, Google has already released a cool new project “Workspace Mechanic” on Eclipse Labs.

The Eclipse community has a large and vibrant ecosystem of commercial and open source add-ons to the Eclipse platform. In the open source world, there are two options if you want to start an Eclipse oriented project: 1) propose a project with the Eclipse Foundation or 2) start a project on one of the existing forges, ex. Google Code, SourceForge, Codehaus, etc. For some projects, the IP due diligence and development process expected of Eclipse projects is not warranted. However, creating an Eclipse project on a forge makes it difficult to gain visibility in the Eclipse community. Can we find a third option that allows projects to start and prosper without the process of the Foundation but at the same time gain some of the visibility Eclipse projects often get by being at the Foundation?

Last year, we started a discussion with the people running the Project Hosting on Google Code service to see if they would be interested in creating an Eclipse area on Google Code. They had already been thinking along the same lines and were very receptive to the idea. Therefore, I am excited to announce the availability of Eclipse Labs, a third option for Eclipse oriented open source projects.

What is Eclipse Labs?
If you have ever created a project on Google Code you will quickly recognize Eclipse Labs. Eclipse Labs allows you to very quickly create an open source project with access to an issue tracking system, source code repository (Subversion or Mercurial) and a project web site. The default license is EPL but you can change it to the other licenses available on Google Code. Anyone can create a project on Eclipse Labs at any time. (Assuming you agree to the Google Code terms of use and the Eclipse Labs guidelines.) Eclipse Labs projects are encouraged to use the org.eclipselabs namespace, but are not required to do so.

Eclipse Labs project owners will also be encouraged to create tags/labels to describe your project. We have pre-populated a set of Eclipse specific labels that will be displayed on the Eclipse Labs search page. Eclipse Labs will also have an API that allows people to search on these labels. My hope is that Eclipse projects will begin to highlight on their own web site Eclipse Labs projects that are relevant to their own project. For example, Eclipse BIRT could list all the BIRT add-ons created on Eclipse Labs. We also want to populate Eclipse Marketplace with the projects from Eclipse Labs. The API is not yet available but it should be in the next couple of weeks. I think this will present a lot of opportunity for cross pollination for Eclipse Labs projects.

What is Eclipse Labs Not?
Remember, this is a third option. Projects hosted on Eclipse Labs are not official Eclipse projects. Therefore, they can’t be called Eclipse projects, use the org.eclipse namespace or be included in the Release Train or Packages. If an Eclipse project wants to include an Eclipse Labs project they will need to go through the normal IP process. If a project wants any of these benefits they must become an Eclipse Foundation project. The details have been specified in the Eclipse Labs Guidelines.

Moving Forward
Eclipse Labs is open for business now. It is still in a beta form, so please provide your feedback.

Our hope is that Eclipse Labs quickly grows to a larger number of projects than are already hosted at the Eclipse Foundation. We need to make it as easy as possible for someone to open source their awesome Eclipse based technology. Not all projects need to be hosted at the Eclipse Foundation and in fact I am hoping more projects will start at Eclipse Labs and then, if they choose, graduate to the Eclipse Foundation.

Big Thanks to Google
The people at Google have been great during this process. Google has once again shown their commitment and support for the open source community. Obviously without this support Eclipse Labs would not have been possible.

Thanks also goes to Ian Skerrett for driving this from our side!

Written by Mike Milinkovich

May 13, 2010 at 1:42 pm

It’s a Dessert Topping and a Floor Wax

Last week we saw probably more conversation than any of us wanted about the notion that Eclipse is a trade association and therefore not an open source community. I believe that perspective to be misguided as it implies those two states are somehow mutually exclusive. They are not. And it is our community’s embrace of both that makes Eclipse unique.

The Eclipse Foundation is and always will be a trade association. It is also and always will be an open source community. This duality is built into our bylaws, our organization and, I would assert, our DNA. Consider the following sentence from the first paragraph of our Bylaws:

The purpose of Eclipse Foundation Inc., (the “Eclipse Foundation”), is to advance the creation, evolution, promotion, and support of the Eclipse Platform and to cultivate both an open source community and an ecosystem of complementary products, capabilities, and services.

That sentence captures the very essence of the Eclipse Foundation. Our mission is to both move the technology and community forward and to work on its commercialization. The “trade association” of member companies financially support the operations of the Eclipse Foundation. Over 70 of them also provide committers who work on projects. There are relatively few obligations that an Eclipse member company undertakes when they sign the membership agreement, but one of the most important is to create a commercial offering based on Eclipse technologies. It is that obligation which completes the loop from open source to commercialization to trade association and back. Those trade association members are not strangers: they are companies that are intimately involved in and committed to the success of the entire Eclipse community.

There is no doubt that the focus on commercialization places added burdens on Eclipse projects. Our development and IP processes require real work to comply with. But there is value in that labour, and the value is in the added use, adoption, commercialization and plain old respect that the Eclipse brand brings to a project. Not every Eclipse-based open source project needs to be hosted at the Foundation. For some projects, our processes may be too heavyweight. But those projects are still a valuable part of the broader Eclipse ecosystem.

The Eclipse community is also an open development community. I strongly believe that our development process has all of the attributes of openness, transparency and meritocracy that open development requires. Our unique approach to open source development is what enables things like the annual release train, which is arguably the best run, most predictable feat of software engineering on the planet. And let’s not forget that although many projects at Eclipse are supported by developers working at member companies, there are many also projects with active participants who are here as individuals.

But there is also no denying that we have our challenges. Every project would love to have more resources and more community involvement. We need to make it easier for newcomers to contribute. There are projects who frankly don’t do a great job of welcoming contributions. We have to attract more resources committed to evolving the core platform. We have a major new release of the platform coming next year. The staff and the Board of the Eclipse Foundation recognize all of these challenges and are working very hard to address them.

The balance between a trade association and an open source community makes Eclipse unique in the software industry. We have always been both, and that has always been an important part of our success. We are different, and in my mind that is a very good thing. I believe that we should all be very proud of the organization that we have created.

Written by Mike Milinkovich

December 11, 2009 at 10:21 am

Posted in Foundation, Strategy

Membership Value Programs for 2010

Monday I blogged about some of the program plans we have for 2010 that are targeted at our project and committer community. Today, let’s turn to some of the things that we have in store for our members and the commercial ecosystem around Eclipse. Not all of these are new, but in each case there is significant value to the community, and there are at least a few new twists that we have planned for 2010.

  • Events: First of all, we are going to be continuing with the program items which have been very successful for the community the past couple of years. Amongst the most successful are the event programs that deliver the Eclipse Days and the Democamps. You may not be aware of this, but each of these events is sponsored in part by the Eclipse Foundation, in conjunction with one or more member companies. They have been enormously successful for bringing the community together, and in delivering value to members. For next year we are planning Democamp programs that line up with the Helios and e4 releases. And we hope to work with the members to bring even more topical Eclipse Days to your locale.
  • Conferences: EclipseCon and Eclipse Summit Europe are significant events in the annual calendars of the ecosystem. Although the content is very technical, a great deal of the talks are relevant to Eclipse users and adopters. The exhibit halls are also a great place for companies to show the cool products that they’ve been building with Eclipse. Running these conferences is a huge amount of work for a small organization such as the Eclipse Foundation, but they do great things for the ecosystem.
  • Eclipse Marketplace: As Ian blogged about yesterday, this week saw the launch of our new “Eclipse Marketplace”. This is a completely new replacement for the venerable Eclipse Plug-in Central (EPIC) website that has served the community well for so many years. Marketplace is a new code base with more features and more flexibility. (As an aside, I would like to recognize the great work that Genuitec, Instantiations and EclipseSource (formerly Innoopract) did in creating EPIC, and then helping us with transitioning its hosting to the Eclipse Foundation.) In 2010 we are going to be looking to expand Marketplace’s visibility in a couple of interesting ways:
    • We are going to be creating a Marketplace client that will ship with the Helios packages. The hope is that by making it easy to get plug-ins directly from within the IDE that will be able to drive more traffic to the commercial and open source plug-ins which make up the Eclipse ecosystem. Please comment on the bug where we are gathering requirements.
    • We are going to be working to make it easier for users and adopters to find products and services which are based on particular Eclipse projects. Using the data that we will have in Marketplace you will, for example, be able to find the companies that offer services for a particular Eclipse project.

    By the way, if you just read the above and are thinking “that’s lame, where’s the Eclipse AppStore?” you are not alone. We looked long and hard at doing an appstore in 2010 but in the end decided that we just did not have the resources. It turns out that while building the infrastructure for a commercial appstore may be tractable for an organization as small as the Eclipse Foundation, dealing with the legal and tax issues of selling in countries around the world is not. We will be re-evaluating this decision again next year.

  • Ship Helios and e4: Many readers may be surprised to see this topic listed under the program value for the commercial membership. After all, aren’t these Eclipse open source projects? They are indeed. But in terms of the value that the Eclipse Foundation brings to its commercial membership, these major new releases represent a lot of marketing, IT and IP value add from the Foundation staff. The annual release train brings enormous value to the commercial ecosystem because it provides them with a stable, predictable and IP reviewed platform each year upon which products can be built. The release train has been enormously beneficial to the commercial ecosystem. Obviously, most of the work is done by the project community. But it also represents the single largest work item on our annual calendar at the Eclipse Foundation.

So those are a few areas that the Foundation staff will be working on next year. I hope you agree that it looks like a busy and productive year coming up in 2010.

Written by Mike Milinkovich

December 9, 2009 at 4:28 pm

Posted in Foundation, Strategy

Collaboration Is Just Good Business

Last week at the Open World Forum, I had the pleasure of attending Michael Tiemann’s talk on the “Road to the Digital Recovery”. Michael kindly summarized his key points on his blog.

The most interesting sound bite from Michael’s talk was his estimate that $1 trillion is wasted every year in ICT spending. His logic is:

…18% of all applications are abandoned before ever reaching production, 55% are “challenged”, meaning they are either late, missing key functionality, buggy, or some combination of the three that results in measurably degraded performance. Back when this study was done, the scope of the analysis concluded that $78B/year was being wasted by US CIOs on “bad software”, but that is the tip of the tip of the iceberg: with global ICT spending over $3.4T USD in 2008, money wasted on “bad software” now exceeds $1T USD per year.

I actually think that the reality is worse. Much worse.

Michael’s conclusion is based on the number of projects which fail to accomplish or only partially accomplish their stated objectives. Everyone in the software industry knows that these types of failures are a simple fact of doing business-as-usual. The proposed solution is to lower the percentage of complete or partial failures by improving the quality of the software being built through using open source processes and techniques.

While I have no disagreement with that conclusion, I think that it is missing a huge part of the problem, which is that we all collectively waste massive amounts of human and commercial capital by building too much software. The sheer amount of wastefully duplicated effort endemic to the ICT industry is staggering.

Note that I am not referring to the software which provides companies any source of competitive advantage. I am referring to the software infrastructure which every company needs to merely operate in their particular industry. In every single industry you will always find some amount of software required by 100% of the players, for which 0% get any sustainable or even measurable competitive differentiation.

For one example, imagine the scenario where a new government regulation in the (say) insurance industry requires all of the companies in that industry within that jurisdiction to implement a new set of procedures. Pretend that there are 30 companies impacted. Even if the implementation project within each of those 30 companies was executed flawlessly, the wastage is 30x, because none of those companies achieved any customer differentiating value from their efforts. Multiply this scenario across all of the companies in all of the industries and the wastage of human effort, skill and imagination is depressing.

In my view, the future impact of open source on the ICT industry is not simply to make software better quality. It is to reduce the amount of wasteful effort squandered on implementing and re-implementing and re-implementing yet again the same bags of stuff that our current corporately-silo’d development structures require.

Open source communities such as Eclipse, Apache, Linux, et al offer enormous potential cost savings to industry. By establishing the licensing, IP management, governance and development processes to enable cross-company collaboration, these communities open the possibility that much of the “operating systems” of various industries could be built and shared. This will require some cultural shifts, but I predict that the business and economic rationale will inevitably drive companies in this direction.

Written by Mike Milinkovich

October 5, 2009 at 5:07 pm

Posted in Open Source, Strategy

Ideas Are Cheap

By far and away, my favourite quote from Cory Doctorow‘s talk at EclipseCon was: “Ideas are cheap. Execution is hard.” Those truly are words to live by.

Remember that as I walk through some thoughts on Eclipse and our community’s strategy. Tony Baer, who writes OnStrategies has been an avid Eclipse-watcher for some time, and one that I very much enjoy reading. His latest theme seems to be that Eclipse is in flux, largely as a result of the growth in projects and the resulting lack of focus. Tony raises many very good points. I don’t agree with all of them, but even where I disagree I find them thought-provoking. I certainly gain a lot more from reading something which challenges our assumptions than those who agree with them.

Here’s a roundup of some of their Eclipse-specific articles:

  • Guess Who’s Coming to Dinner? provides an excellent summary of the interactions with both Microsoft and Sun last week at EclipseCon. There were two money quotes in this article:
    1. No longer defined by the IDE, the spreading of Eclipse’s mission means that members and neighbors aren’t necessarily drinking all the Kool Aid.
    2. In other words, as Eclipse gets broader, its mission is in the eyes of the beholder.
  • Eclipse’s Vernal Equinox came out the day EclipseCon 2008 opened, and picked up on the theme from the previous year. To whit:

    Eclipse is undergoing organizational growing pains made possible by its embrace of a technology (OSGi) whose versatility opens up huge new possibilities. But as any organization spreads its wings, preserving consensus becomes far more challenging, not to mention maintaining focus. Although the Eclipse Foundation is not a standards organization per se, it shares challenges similar to confederated standards bodies like Oasis that have lean, loose governance structures. All too often, you wind up with anarchy as competing, overlapping projects admitted with the intent of encouraging participation instead compromise the very principle by which most of these organizations were founded: interoperability.

  • Eclipse Eclipsed? came out around the time of EclipseCon 2007 and first raised the issue that Eclipse was losing its focus in a way very similar to the JCP. By spreading ourselves too thin, we are….well, actually this article never actually states what the downside might be. After pointing out that Eclipse had moved from its “...almost comical…” origins to “…the Java world’s de facto response to Microsoft Visual Studio…“, it singles out RedHat’s decision to open source their Eclipse plug-ins on their own forge rather than at Eclipse to indicate “…that the open source community does not necessarily want Eclipse to become all things Java.

As I mentioned earlier, I don’t agree with all of these points. But there is one over-arching theme that I definitely do agree with: life is getting more complex as Eclipse projects spread into more areas. Runtimes in particular, have ummmm generated some interesting conversations, as various organizations have sought to understand what’s happening at Eclipse and how that might affect their business.

Tony is also completely correct in believing that companies like IBM, Oracle and RedHat are going to be selective in which technologies from Eclipse they adopt. It is highly unlikely, in fact, that any of the current players are going to adopt all of the projects in the new EclipseRT project (see EclipseCon slides). The whole point of the stackless stack is, of course, that selection is not only possible but desirable.

Where I disagree with Tony’s analysis is his assumptions. Eclipse is not only “…not a standards organization per se...”, it is nothing like a standards organization. Our goals, processes and outputs are very different than a standards organization. That’s why open source organizations make excellent complements to open standards, but are not a replacement for them.

Open source communities such as Eclipse and Apache are innovation engines. They are places where ideas can be forged to usefulness in the crucible of a meritocratic community. Remember: ideas are cheap. Achieving the expectations of a successful Eclipse project (quality, APIs, community and commercial adoption to name just a few) requires some very hard execution indeed.

Similarly, assuming that interoperability a goal of Eclipse is off the mark. At least in the way term is used. I believe that one of the single strongest elements of Eclipse is that we do, as a community, have a great deal of interoperability. The fact that Equinox provides a common OSGi-compliant runtime shared by every single project at Eclipse gives us good (but not perfect) interoperability across our projects. But the purpose of the Eclipse Foundation is not to specify interoperability between its many projects. Our goal is “…to advance the creation, evolution, promotion, and support of [a vendor-neutral, open development platform supplying frameworks and exemplary, extensible tools] and to cultivate both an open source community and an ecosystem of complementary products, capabilities, and services”. We are on a development platform mission, not an industry-wide interoperability mission. We actually seem to be having some very real victories in interoperability, but don’t confuse side-effects with the main mission.

So when I hear comments that Eclipse is losing focus, I ask: what do you think our focus is? I believe our focus is to create a community and ecosystem, not — with the possible exception of the base platform — any particular technology. “Development platform” is a broad term that encompasses quite a bit of technology. Or put another way, the secret sauce of Eclipse is not any particular technology; it is that we have come up with the best model we know of for doing collaborative development amongst both individuals and corporations. Our primary focus at the Eclipse Foundation is to constantly invest in improving the development and IP processes and the IT infrastructure to support that collaborative model.

Of course we also like to raise awareness when the community builds some cool technology as well. And once some technology has demonstrated broad utility and adoption, then it might be useful to send it off for a formal specification.

As long as we are seeing a steady stream of innovative new projects at Eclipse we are making progress IMHO. The Eclipse Foundation does not pick winners by trying to decide a priori which projects will succeed, if for no other reason than my utter confidence in our inability to pick those winners. Competition and the community will sort that out for us. And competition — which is the universal constant in successful ecosystems — means that failures must exist. But I assert that any philosophy other than embracing competition and its inevitable winners and losers will result in a dysfunctional community. Even if that means that we sometimes suffer “…anarchy as competing, overlapping projects…” arrive at Eclipse.

Ideas are cheap. Execution is hard. Think of Eclipse as the place where ideas have an opportunity to be executed. Shameless pun intended 🙂

Written by Mike Milinkovich

March 24, 2008 at 10:16 am

Posted in Analysts, Strategy