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.
Transparency
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.
Alignment
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.
Sponsorship
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.
Governance
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.
posted by Doug Gaff @ 10:58 AM
3 comments
3 Comments:
"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."
I personally would love that attitude to change in Eclipse. It would be nice if there were possibly sponsorship packages for projects without corporate sponsors that other people would find useful. To build a good ecosystem that lasts, I would like to see more involvement for projects that aren't tied to corporations specifically.
Yeah, I suppose I agree philosophically. It would be nice if we had more sourceforge/linux-like dedication. I'm speaking pragmatically in the post, though. I see a lot of "good will" coming from engineers on some DSDP projects. But this good will just doesn't translate to code contributions, because these engineers don't have corporate support. It's a fundamental problem in Eclipse. So I'd rather have companies back the work with committed engineers. Or perhaps we could have shorter workdays to free up some time.... :)
Great post, Doug! You are bang on with transparancy, too. I've seen projects so non-transparent, you'd hardly know the project is still active (i.e., Cobol). And, yes, even with the CDT, we're not perfect. I had a number of conversations at EclipseCon that should have been in the open. Although with all the developers spread throughout N.A. and Europe, we end up being forced to work via the mailing list.
And I agree with you on the sponsorship thing. Hardly any projects on sourceforge make it into commercial products and the ones that do, plus Linux, are staffed by sponsored developers. It's just the best way to produce software that you can rely on commercially.
Post a Comment
<< Home