Summer madness has force me to leave a gap in the delivery of my award-winning “Eclipse is…” blog series. But I’m back now. In this series, I walk through the many different aspects of Eclipse, starting with the definition that most people are comfortable with: Eclipse is a Java IDE. But, as the series discusses, Eclipse is more than that. Technology-wise, Eclipse is a platform for building IDEs, tools, applications, runtimes, and more. Eclipse is open source projects. Lots and lots of open source projects covering a vast array of topics from modeling to identity management and object-relational persistence.
It’s certainly true that great technology is an important part of what makes Eclipse what it is. However, technology alone isn’t enough. Technology needs to have a community. And at Eclipse, we’ve got community. At Eclipse, we bring the community together to do great things.
Community is about coming together to do things as a group that no single person can do by themselves. Whether it be chasing snakes from a local watering hole, or building great technology and support.
Eclipse is actually a collection of communities that intersect. The Eclipse Development Process defines three different communities: users, adopters, and contributors/committers. Each of these communities has different requirements and expectations from Eclipse.
The first community, users, tends to regard of Eclipse primarily as a consumable product. They are primarily concerned with using an Eclipse-based IDE to build solutions. We estimate the size of this community to be between four and six million in size; though the fact that more than a million downloads of the new Helios packages occurred in the first month of availability leads me to believe that the community is even larger than our estimate.
The adopter community contains individuals and organizations that build solutions based on Eclipse technology. This can be as simple as providing a plug-in that runs in an Eclipse IDE, or as involved as basing an entire product on the Eclipse Rich Client Platform (RCP) or Rich Ajax Platform (RAP). It also includes those individuals and organizations who base a business on providing development assistance and support for Eclipse technology. One way or another, adopters tend to be building Eclipse plug-ins to provide solutions that directly or indirectly leverage Eclipse technology (though this is not necessarily the case as some Eclipse technology–like EclipseLink, and EMF–can be leveraged in plain-old-Java application). We don’t even try to estimate the size of the adopter community; it’s just too hard to do. There are more than a thousand “solutions” in the Eclipse Marketplace. This is really just the tip of the iceberg; it doesn’t include, for example, the bajillions of in-house applications (some of these are captured in case studies) that leverage Eclipse technology.
The contributor/committer community contains that group of individuals and organizations who contribute directly to Eclipse projects. These are the individuals who provide patches and/or contribute new functionality to the various Eclipse projects. Contributors tend to participate directly in an Eclipse project by providing code, ideas, answers to questions in the forums, and more. Committers are a subset of the contributors with write access to the resources maintained by a project (committer access is provided on a project-by-project basis). The idea is that over time, a contributor is invited to become a committer and elected into that position based on credibility established over a period of time. At last count we had almost a thousand committers and thousands of contributors (more than 11,000 individuals have contributed at least one patch to an Eclipse project).
Developing a community is an important part of being an Eclipse project. In fact, an integral part of the Eclipse Development Process. As part of a review process, a project is required to demonstrate their community-building activities, like blogging, speaking opportunities and more.
The graphic on this slide attempts to show that the various communities interact with each other. Users consume the software produced by the contributors/committers and the adopters, and provide feedback. Some subset of those users will provide feedback and other input into the project. Adopters also provide feedback and input. Some number of adopters may become contributors and ultimately committers. Projects with large communities have greater potential to have very diverse committer communities and broad consumption by adopters. There’s really more to it, but I’ll leave this discussion for a later post.
At this point in my presentation, I usually stop and ask the audience how many of them already have Eclipse Bugzilla accounts. Then, noticing that a large number of people haven’t put up their hands, I facetiously marvel that so many people have managed to use Eclipse for so long without ever having encountered any sort of problem. I use this opportunity to tell people that it’s okay to open bug reports (I once tried to use Erich Gamma‘s bug-reports-are-like-love-letters analogy but decided that that wasn’t my style).
So, Eclipse is a community. A big community. A growing community. A diverse community. More than a community, though, Eclipse is… an Eco-System.
On a side note… committers: get your talk proposals for Eclipse Summit Europe in today!
