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.
posted by Doug Gaff @ 1:07 PM
5 comments
5 Comments:
wow, nice post and I share most of your sentiment, however....
The only point I want to make here is that if you want more committers/contributors, you need to get your ass out on the streets and start preaching.
And by preaching, let me give you a few examples. If you look at some of the nominations of this years top contributors: (https://bugs.eclipse.org/bugs/show_bug.cgi?id=168237)
Note that a lot of them came from working with the Eclipse committers on IRC (notably the platform committers). Some examples here are: Tom Shindl and Benjamin Muskalla. I doubt they would become contributors if the platform team didn't establish a relationship with them in the first place on IRC (or some other social forum).
Yes, that's true. We must be our own evangelists.
However, I would add from experience that the situation for some incubation projects is not a lack of "believers", but a lack of company commitment. Put simply, the engineers want to help, but they can't get the time allocated to them by their companies.
That is my call to arms. I want company commitment.
I agree with the company commitment part :)
This has been a problem with companies that treat their open source commitment as charity. The problem is, how do you fun open source activities when they don't directly affect the bottom line?
I'm pretty sure Eclipse was Me at some point, too :-P
For one thing, users aren't always going to have the right skills to help sort things out. And there are some things that users can do that often get overlooked, like overall user experience, typos in documentation, suggestions for improvement and so on. A lot of things are minor changes, and there's only one level -- you're either a committer, or you're not. And it's pretty difficult to get to be a committer if you've only done a few bits and pieces.
Look at wikipedia (as an example). Anyone can fix things, or make changes. It can grow incrementally, and it's a fairly low investment in time to make a change.
Compare that with Eclipse -- or any other large project. Patches have to go through effectively Q&A by doing peer review; then, there's multiple back-and-forths as it evolves, and finally (if you're lucky) it makes it into Eclipse. Most people don't have the time to go through that, especially for small changes. And the small changes that can be done -- you know, like as trivial as an extra / in an xml file -- get ignored because the committers have got more important things to do.
Then there's actually getting the projects. Even once you're familiar with the map of the suite of plugins, still finding the damn thing in CVS is a challenge in itself. Because the View CVS has all the folders (with Attic files in) of any files that might once have existed, you end up drilling down org.eclipse.old.someting/src/java/org/eclipse/something/ to find out that there's bugger all in that module any more. Frankly, Google is about the only way of finding things with a site:dev.eclipse.org +viewcvs (because if you don't put the +viewcvs in, you get hit with tons of messages to dev@eclipse instead.
And even if you've imported the source in from (say) 3.3M4 SDK, the plugin structure has so many different source folders that it not only bears no resemblance to the structure in CVS, but it's impossible to merge any changes that you might have made in the 3.3M4 without loosing some of them.
People like Philippe and Chris are really great, encouraging people to get involved and do things. But the barrier to entry needs to be lowered way, way, down if you want to get more people interested. The Google summer of code was an excellent example of how it can work.
Lastly, for many people, Eclipse and Eclipse JDT are synonymous. Getting people interested in other projects requires more marketing -- whether that's blogs, releases, posts, tutorials or whatever. Ask for more help, encourage people to help fix bugs, and make it easier for them to be involved. Shipping the source jars as zipped forms of the project structure (with CVS meta information) instead of 'Here's a version of the source that we don't actually use' would be a start.
Words don't crash or have to be debugged and maintained forever.
Post a Comment
<< Home