Life at Eclipse

Bjorn and guests have been blogging about the results of the recent committer satisfaction survey at Eclipse. I think that the survey itself embodied genius in its simplicity: one question on “…how happy are you with the Foundation’s support of you and your project?”

As the Executive Director, I am pretty thrilled with the response, as 82.5% are on the “happy” side of the equation. That’s a darn good result.

Of course, there is always work to do and improvements to be made. You can see those thoughts well reflected in the comments that Bjorn gradually worked his way through in his blog series. The good news is committers are generally pretty happy with the IT infrastructure and the support they get. Unsurprisingly, they are a little less happy with the processes that we impose on them. There’s a shock!

To all of the staff at the Eclipse Foundation, I want to extend a hearty congratulations. I know that as the pointy haired boss I rarely say “thank you” enough for the great work that you do. So here are a few thank you’s, along with my personal favourite quotes from the survey.

To Denis Roy, Matt Ward and Karl Matthias: You are obviously taking customer service seriously and it is being noticed by our community. Thanks

Very happy, especially with the fast response time of the webmasters

To Bjorn Freeman-Benson, Anne Jacko and Gabe O’Brien: The development process and portal have come a very long way over the past year and your work is helping to improve our committers day-to-day interactions with the Foundation. Thanks!

The development process is well thought out. I also _really_ like the portal.

To Janet Campbell, Sharon Corbett and Barb Cochrane: You bear the brunt of running our IP due diligence process. A process which clearly puts a burden on our committers, but one which has been an enormous part of our community’s success. And you do it with grace and humour. Thanks!

Their’s is a tough job and, in my opinion, they do it very well

Some of you might have noticed that when Ganymede was first launched yesterday, the eclipse.org website was reeeaaallllyyyy slow for a little while.

By way of explanation, I offer the following:

But more seriously, many thanks to Denis, Matt, Nathan and Karl for all of their work in getting our IT infrastructure ready for the deluge.

As a Friend of Eclipse, I was able to download Ganymede this afternoon. Not only did I get it sooner, I got it faster. In fact, thanks to the dedicated bandwidth it was crazy fast to download.

Thanks goes to Denis Roy and the webmaster team. It looks like the Ganymede distribution setup is well architected and running smoothly.

So friends get benefits!

Ganymede is just around the corner, and I wanted to take a moment to say thank you to the many Eclipse committers, project leaders and contributors who have all participated in its success. You have done our community proud.

I was tempted to list some of those who have made particularly significant contributions, but I am certain I would miss too many deserving people. Please feel free to provide their names in comments. From releng to packaging to developers to CQ reviewers to bug triagers to movie poster competition organizers to Ganymatic kickers, there are a many individuals who have chipped in to helping make Ganymede a reality.

One interesting note: as most readers are well aware, I’m pretty much useless when it comes to shipping these releases. My personal contribution is primarily in support of the press and analyst activities in support of the release. As this was the third release train, Ian and I were pretty much convinced that the press interest in Ganymede would be lower than in past years. You know: same old same old. We were dead wrong. There is a ton of interest in Ganymede, and how the Eclipse community continues to predictably deliver value and innovation year after year.

So: congratulations and thank you!

Continuing from yesterday’s post on the Usage Data Collector, I thought we should also describe how we plan to use the UDC data. In the official, lawyer-approved Terms of Use, we have stipulated the following:

• The Eclipse Foundation may, in its sole discretion, make available to organizations and individuals, on a case-by case-basis, the data that it collects through the Usage Data Collector, whether in raw or aggregated form.
• The Eclipse Foundation will publish summary reports based on the data obtained. These reports will be made available in machine readable format that will allow individuals and organizations to undertake further analysis.
• Potential uses of the summary reports may include, but not limited to: 1) Eclipse project committers who want to better understand how individuals are using their projects, 2) usage of Eclipse projects and third-party Eclipse plug-ins, and 3) an estimate to the number of individuals using Eclipse. It is expected that the summary reports and raw data may be used for other purposes that we have not envisioned at this point in time.

However, I think it would be useful to explain more about how the Foundation plans to use the data. First I think it is important to reinforce what and how we are collecting the data.

1. UDC will only be included in the EPP packages. If someone does not want to download UDC, the ‘classic’ Eclipse SDK will be ‘udc-free’.
2. UDC is opt-in, so each user must agree to send the data, along with any optionally selected general demographic information.
3. UDC provides the ability to filter the data, so you can send only information about org.eclipse bundles or specifically not send information about bundles that have ‘xxx.yyyyy’. This is important if you want have sensitive plug-ins that you don’t want to share data about.
4. All the data that is collected is anonymous. For each participant, a unique ID is created by the UDC that allows us to aggregate data for that participant. The unique ID does not allow us to identify the participant in any way. We are not collecting any IP addresses and can not aggregate the data by organizations or companies. To be really specific: we cannot trace the ip address from the upload to the keys contained in the uploaded files. The data is completely anonymous from the source.
5. We do plan to capture the country location so we can report the data by geography.

So what do we plan on doing with the data? The first priority is to provide a service for the committers and projects. We intend to create and publish a series of reports that will only include information about bundles that include ‘org.eclipse’. Information about bundles from other organizations will not be included in these reports. We intend to make these reports publicly available. The committer community will not have access to the raw data.

We have already been approached by a number of academics in universities that are interested in analyzing the data as part of their academic research. In principle we would like to support and encourage this type of research. One valuable results of UDC could be a better understanding of how people use IDE’s and develop code. At this time, we don’t have a process to make the raw data available to academics but if we do the raw data would be made available under a confidentiality agreement that enforces the Eclipse Foundation privacy policy.

In the future we do think that organizations, in particular the Eclipse membership, will be interested in accessing the UDC data. We think they will be interested in understanding how their products are being used and how they compare with other products in the industry. If we provide this information, it would be in the form of machine readable reports, not access to the raw data. The reports would be scrubbed to ensure only information about the relevant products are included.

Finally, I’d like to address the question of ‘selling the data’. We will not sell the raw data to anyone. Period. However, we may sell reports of the data to organizations. At this time, we have no idea if there is any commercial value for any reports. We do hope there is some commercial value and we can develop either a future revenue stream for the Eclipse Foundation, or use the UDC reports to generate increased value for memberships at Eclipse.

As a reminder, the Eclipse Foundation is a not-for-profit entity that is funded by membership dues. If we want to provide additional services to the Eclipse community and its projects, we need funds. If we are able to create either new revenue stream, or enhanced membership revenue in a way that respects the privacy and integrity of the Eclipse community, it could be a good thing for the entire community.

I hope this provides a bit more insight into our current thinking. A lot will depend on how many people participate with UDC and the type of information we can report from the data. I am optimistic that this will be a great service for the Eclipse community.

One of our challenges at the Eclipse Foundation is understanding how and what people are using Eclipse. Millions of people come to our web site to download the various projects, find different Eclipse based plug-ins (open source and commercial) and use them to create amazing software. If we can gain insight into how people use the different pieces of the Eclipse ecosystem we should be able to improve the overall user experience.

This whole initiative got started after I went to a talk at last year’s OSCON by Joe “Zonker” Brockmeier. At the end of his talk, he made that point that open source projects have a particular challenge in getting to know their users: we don’t ask people to register, and we don’t have even the most basic information we need to help improve our software. We lack the stats to make good decisions. His suggestion: ask your users to provide useful data. So that’s what we’re planning on doing. This is about helping our projects and our ecosystem to make Eclipse better.

For this reason, I am very interested in seeing the response we get to the Usage Data Collector (UDC) that we are planning to include in the Ganymede EPP packages. For those that might not have seen Wayne’s previous posts on this subject, UDC is a piece of technology that will track how and what people are using in Eclipse. UDC has been included in the EPP Ganymede milestones packages and over 1500 individuals have participated during the past four months. We have created some initial reports and I hope into the future we will be able to provide some interesting information for our committers and the wider Eclipse community.

As you can imagine with any data collection technology, privacy is a huge concern. Therefore, to be clear, UDC is 1) opt-in, so only people that agree to send the data will participate, and 2) completely anonymous. No personal data, including IP addresses, is being collected. In addition, the Eclipse Classic package will not contain any UDC code at all, so there is a simple option for users who really want to avoid this. For those who are interested you can review the code in CVS.

So far it seems that our approach to UDC has been well received by the community. No one has expressed any concerns to date, and 1500 opt-ins has more than met our expectations during the development phase.

Coincidentally, in the last month the Mozilla community has begun talking about a somewhat similar data collection program. In Mozilla, some strong opinions have been expressed about collecting data at all. Therefore, I want to make sure everyone in our community has an opportunity to respond to this program before we make the final decision to deploy it.

We are very excited about the potential of UDC but we also want to ensure we respond to any community concerns. Please feel free to contact me (mike at eclipse dot org) or better yet leave a comment letting me know your thoughts on UDC if you have any feedback.

I just recently agreed to be a speaker at Joel Spolsky’s Business of Software conference in September. I guess it is in some way returning a favor, as Joel gave a very memorable keynote at EclipseCon 2006.

The talk is going to be focused on providing a practitioner’s guide to software ecosystems, a concept we have been thinking a great deal about at the Eclipse Foundation. There is certainly literature on what business ecosystems (and innovation networks, which I am now starting to think of as a specialization of the ecosystem concept) are in theory, but relatively few experience reports on actually building and maintaining these things.

Given that the Eclipse Foundation is one of the only places I have ever heard of that has “…cultivate an ecosystem of complementary products, capabilities, and services…” right in the mission statement for the organization, I think we have an interesting viewpoint to bring to the conversation. There will be lessons drawn from Eclipse as I think that we’ve managed to build a pretty successful and interesting ecosystem, but mostly in blissful ignorance of the theory.

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