“Is something wrong?”, she said
Well of course there is, “you’re still alive,” she said
Oh, and do I deserve to be?
Is that the question? And if so, if so, who answers, who answers?
– Pearl Jam, Alive
I take criticisms that the Eclipse Development Process (EDP) is “too heavy” a little too personally. I guess that this makes sense: as Director of Open Source Projects at Eclipse, I am the one responsible for the maintenance of the process. Whenever I hear this criticism, I always look for the specifics. “What,” I ask, “specifically, is too heavy?” And the answer is almost always a very non-specific “it’s too heavy”. I do, however, sometimes get specific answers: perhaps the most commonly cited specific issue is intellectual property (IP) due diligence, followed closely by reviews, and maintaining a project plan.
The Eclipse IP Due Diligence Process starts with an assumption that adoption is important for a project. If you care about adoption, then you need to care about IP management. If you care about IP management, then you need to do IP due diligence. If you’re doing IP due diligence, then having some kind of process will make sure that it’s done effectively and consistently (inconsistently applied IP due diligence may be more harmful than helpful). I respectfully submit that this is true regardless of where your project is hosted: if you want to develop a community of users, adopters, and contributors around your project, then you need to have an IP due diligence process.
In my Intellectual Property Management post, I went into some detail about all the sorts of things that need to happen as part of a due diligence effort. There’s a lot of important questions that need to be answered; getting those answers yourselves can be labour-intensive, time-consuming, and dreadfully boring (especially for software development types). The Eclipse IP Due Diligence Process takes care of most of the heavy-lifting for you. It can be a little time consuming, but is it “heavyweight”? Probably. But no more heavyweight than the process that a project really cares about developing a community of users, adopters, and contributors, should be following anyway. For Eclipse projects, somebody else gets to do the labour-intensive, time-consuming, and dreadfully boring parts for you. With that in mind, can it still be considered ‘heavyweight”? [probably; there’s no pleasing you, is there?]
Reviews are a way of life at Eclipse. All projects are required to undergo reviews at key points in their lifecycle. Release Reviews are the most common form of review; they must occur before any project makes an official release of their software. Reviews are relatively formal affairs: a project provide review documentation to the EMO, who then disseminates it to the community for their consideration. The documentation describes new features and APIs added with the release, existing features and APIs that are being deprecated or removed, community development activities undertaken by the projects, bug status, and more. In short, it’s the sort of useful information that people in the project’s community of users, adopters, and contributors need to know about. Assembling the document is also a useful opportunity for a project to reflect on the work that they’ve completed and prepare themselves for the work on the next iteration.
Developing that community of users, adopters, and contributors takes work. The adopters and contributors may be following the conversations occurring between project developers in your project mailing list, or bug tracking system; but it’s naive to think that your user community is following those conversations. The review document may be the only outward community that your community of users ever reads. Frankly, every project should be producing a “New and Noteworthy” document with each release (this is probably more useful for the user community), but I loathe to add any new requirements new to the EDP. Is creating the review document necessary? I think so. Is assembling a review document heavyweight? When compared with the alternative of doing nothing, I guess it is. Again, I respectfully submit that if you care about developing that community of users, adopters and contributors, then you need to do this sort of outward communication regardless of where your project is hosted.
I can make the same sorts of argument about project plans. If you care about growing a community of users, adopters, and contributors then your project needs to have a plan. Users can be fickle; sometimes they like surprises, sometimes they don’t. But surprises can be devastating on your adopters and contributors. Adopters need to do their own advance planning and if their product is going to contain your code, they need to know what to expect. Likewise, contributors need to know how they can best add value to your project; if you tell them what you care about, then you improve your odds of getting contributions that you actually want and can use. The best way to make sure that everybody knows what to expect (i.e. is not surprised) and knows what they need to do, is to have a plan. All projects have a plan. Successful projects tend to write them down and make them available to their community. Is maintaining a project plan heavyweight? Again, when compared against the alternative of doing nothing, it is. Is it valuable? Again, I respectfully submit that if you care about developing that community of users, adopters and contributors, then you need to do this sort of outward communication regardless of where your project is hosted.
We’re working on some changes to the EDP for 2011 (see Bug 342328). Most of the changes in this round are concerned with some proposed changes to the Eclipse Bylaws (probably the most significant change is the removal of the Requirements Council). I don’t foresee any changes to any of the topics discussed here this time around, but we’re always open to suggestions on how we can improve on the process while maintaining the integrity of the principles upon which the EDP is based. Post your comments here, open bugs, send me a note (I’m the only “wayne” at eclipse.org), or corner me at a conference or Demo Camp.
