Eclipse is Who?
I don’t want to beat a dead horse on the “Eclipse is You” thread (Bjorn, Doug, Steve, Eugene, Doug, Ian, Dennis, Bjorn, John), but I figured everyone else is tired of talking about it, so I might get the last word!
Those of us running projects in Eclipse are faced with the common scenario Doug pointed out: people want you to do things, and they often don’t or simply can’t help with the work. In the Eclipse development process, we sometimes refer to these people as (with tongue firmly planted in cheek) the “User Community”. They are valuable because they help prove your technology without the same expectations and costs associated with a paying customer…or so we sometimes wish.
Yes, the feedback is good, but what about young and struggling Eclipse projects trying to implement their visions? It seems every project talk I attend at an Eclipse venue ends with a statement like, “we have a lot of work to do, and we’re looking for contributors”. 4 of the 6 projects in DSDP are in incubation, and we’re no exception to this need. Case in point, in this week’s face-to-face meeting for the Device Debugging project, we discussed our own staffing challenges and the need for more contributors to accelerate the tools work on top of the Debug Services Framework. Clearly the limit to Eclipse technology growth is not ideas, but staffing.
This brings me back to the three communities in Eclipse: Committers, Users, Plug-in Developers. There is a reality about the three communities that every new project must understand before embarking on their quest. The communities begin (and sometimes end) with a project’s sponsoring company. In just about every new project creation, the sponsoring company finds itself providing all of the project’s initial engineering staff. (Luckier incubation projects might have two companies volunteering engineers.) The task of building the first framework and the first set of tools falls upon this company…and they’re usually sponsoring the project in the first place because it’s the foundation of one of their commercial products. These one or two companies are the project’s first Committer and Plug-in Provider communities.
So what brings other contributors into the mix? In Eclipse, it’s not as likely to be the “cool technology” factor as is typical with other open source communities resembling penguins or wildebeests. I don’t mean to imply that Eclipse isn’t cool, but Eclipse is structured and governed to enable business strategies…collaborate on commodity, differentiate on IP. And the reality is that for projects to attract new contributors, they have to find other companies with a strategic interest in their technology.
Fine, but what about those users? After all, projects are supposed to produce two things: frameworks and exemplary tools. Frameworks are typically the foundation upon which commercial technology is built. Frameworks bring other companies and their engineers to the table. At a minimum, exemplary tools simply help illustrate framework extensibility so companies can easily build their IP on top. But the user community wants free
beer tools to help them do their jobs, and here’s where it can get tricky. If a project’s sponsoring companies have no need to productize those exemplary tools, the project may find it difficult to staff the tool implementations. Alternatively, the tools might be built, but they aren’t meant to supplant their feature-rich commercial counterparts. This is the design of Eclipse and is frankly one of the biggest reasons for the community’s growth. Poor users.
I don’t think we can just accept that. While I agree that sometimes Eclipse is You—users need to pony up some development time—I also think we project leads can’t forsake these evangelists. Our companies moved out of their comfort zones when they embarked on the Eclipse journey, and with that comes the reality that sometimes we have to contribute for no other reason than the benefit of that User Community.