The Perils and Pitfalls of Young Eclipse Projects
A wise Eclipse Director of Open Source Process once told me, "Don't incubate too many projects at once, it's very difficult." As he incubates a ridiculous number of them himself, I guess he speaks from experience. Lately I've been thinking about the many young projects in DSDP and what we are currently struggling with.
Before all you old-timers say "duh", let's pause for a moment and define this, because you, too, may be guilty. Transparency means that anyone and everyone who's developing, observing, or using your project can see what's going on at all times. This requires communication on steroids. I'll bet that very few projects in Eclipse have truly mastered transparency. Some examples: Did you have a hall conversation with a colleague on the project? Better create a bugzilla for that work item you discussed. Did you have a phone call with some developers? Better put those notes on the Wiki. Are you emailing colleagues outside of the dev lists? Tsk, tsk. How current is that project plan or the website in general? Did you commit something that others on the project had no idea you were even working on? What, no bugzilla entry or technical discussion with the group? Transparency separates the successful Eclipse projects from the ones that will eventually die. For small projects with small staff that are new to this mindset, it's a steep learning curve.
Team alignment, alignment with dependent commercial products, alignment with the user community, architectural alignment…it's all typical software project stuff. In Eclipse, alignment with commercial products and the user community should come from bugzilla and the project plan. Perhaps more important is getting the development team aligned on the architecture, on who is doing which parts of the implementation, and on how and when those parts are going to be delivered. Just because we're in open source doesn't mean we can forgo good project management. Eclipse project development shouldn't be a free for all, especially not when we're building something that our respective companies depend on commercially.
I've blogged about this before, so I'll only summarize: without corporate sponsorship that ties an Eclipse project to a corporate product strategy, the Eclipse project will eventually starve from lack of developers.
While good project management is important, it's also true that Eclipse projects are not corporate projects. Here's the big difference: in a corporate software project, someone is the boss (manager/architect) and many others are the workers (coders). The boss has final decision authority, and the boss has coercive influence over the workers because of the reporting structure. In Eclipse projects, there is no such reporting structure. It's true that the PMC has ultimate authority over what gets done in a project, but most decisions are far more collective than they are authoritative. Decisions are based on influence, merit, communication, and good old fashioned horse-trading among peers. Eclipse projects must understand this subtle leadership difference to be effective.