Heavyweight Processes

“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.

This entry was posted in Community, EDP. Bookmark the permalink.

9 Responses to Heavyweight Processes

  1. Daniel Cheng says:

    It is not “too heavy”, it is “look heavier than other projects”.

    IP process is almost nonexistent in most project. Some project go a stricter route like signing a contributor agreement and assume everything he commits are ok.

    Yes, this would cause some pain when the project change hands — but this seldom happens. Individual contributor seldom even think about this.

    Fix can be delegating this process into projects. Or have open some more fast-track (e.g. declaring everything from Apache foundation is okay).

    • waynebeaton says:

      Thanks for your comment Daniel. We actually get a lot of projects that move to Eclipse from other places (m2e, Tycho, and Hudson are relatively recent examples); in many cases, the moving projects cite the Eclipse IP Due Diligence Process as one of their primary reasons (if not the primary reason) for the switch.

      I believe that the centralized IP due diligence process is one of the the key benefits of having your project at Eclipse. With centralized IP due diligence performed by a dedicated team, software developers can focus on actually writing the code while somebody else (and more specialized in the practice) takes care of the IP stuff for them.

      We have discussed the fast track option. One of the problems that we have to sort out, however, is that the IP team does quite frequently actually find IP problems in third-party libraries. I’m not sure what the hit rate is for Apache libraries, but I believe that it’s generally lower than the average.

  2. Konstantin Komissarchik says:

    Re the benefit of release review and plan documents. While the arguments about greater transparency are all very valid, it is not clear that requiring these documents actually increases transparency. Consider that most projects plan via bugzilla. Most project plans I see are little more than a bugzilla query. Most release review docuware is little more than generic wording + a bugzilla query. I would argue that we could drop the requirement for projects to put together a release review doc and plan doc without loosing any transparency in the process. A little bit of auto magic in the dashboard and no one would know the difference.

    • waynebeaton says:

      I would love to make generating review documentation dirt easy. This is definitely going to be a part of any portal replacement plan we build moving forward.

  3. Scott Lewis says:

    Wayne,

    I think there are several things going on here. First, ‘heavyweightness’ is obviously in the eye of the beholder…and project *size* matters a lot in that perception: what’s heavyweight to 5 independent committers that are the core of a successful open source project will see a process as heavyweight, when a corporate project team of even 20 or greater will not.

    Given the above, I don’t think that your assertion that the EF processes…as they are…actually help adoption…is generally correct. That is, it might be correct for the large corporate projects…where *perhaps* the target consumer’s needs benefit from from the EF IP process (although I’m not convinced that’s necessarily the case…even if some believe it), but it certainly is less likely to be correct for the 5-person project…that may looking to address the needs of a completely different consumer (e.g. the individual developer, or the small team, or small org, or new technology area, etc).

    And although EF’s adoption history is obviously dominated by the larger-projects…specifically the Eclipse IDE…I suspect you would agree that in terms of adoption, the smaller project teams (e.g. EMF, Mylyn, ECF, plenty of others, etc) have been able to develop both active contributing communities and a variety of consumers. And this has obviously also clearly been the case outside of EF as well (e.g. Apache projects, Jenkins, others). Further…even at the Eclipse Foundation, it seems to me that there are more smaller projects than ever before…and I suspect that trend will continue due to the ongoing reduction of corporate support for open source projects.

    So I think your equating these EF processes with ‘wanting adoption’ is incorrect. It may help adoption in some cases (certain kind of projects), but in other cases it’s not particularly helpful…and I think what you are hearing from those (small) projects is that it can also be hurtful…because it consumes scarce resources…meaning that other things critical to adoption (like new features, documentation, support, etc) receive less resources…thereby preventing adoption rather than aiding it.

    • waynebeaton says:

      @Scott, I understand the scarce resources problem. My assertion is that the sorts of things that you need to do to drive adoption are universal and that the “heavyweight” processes at Eclipse are actually helpful to a project. Imagine the drain on scarce resources if you had to do all of your open IP due diligence. That, of course, presupposes that you believe that there is value in that due diligence.

      And I will continue to argue that having a documented plan and review documentation are valuable resources that should be a relatively small part of your community development activities. As you know, community doesn’t come for free. You have to dedicate a significant amount of your scarce resources into that community interaction. Where would ECF be today without your community development efforts? Community development efforts like maintaining a project plan, and documenting your releases must have equal footing with new features, documentation, support, etc. No single one of these activities is more important than any other. Take any one of them away and the rest fall apart.

      • Scott Lewis says:

        @Wayne

        With scarce resources, I would argue that having user/developer documentation is more important than review documentation…as I don’t believe the review documentation is generally consumed very heavily…i.e. I agree with Konstantin on this.

        So I agree with you that community interaction is very important…and yes I dedicate lots of my personal resources (more than is healthy, I think) to community support and development. But I think the process and review materials are…for the most part…the weakest link in that interaction…and when faced with continuously reducing resources, it’s more of a burden (for me) than it is valuable to the community…in my judgment. But we’re back to the ‘not all projects are the same’ discussion I think.

      • waynebeaton says:

        We should explore that. Should we replace the review documentation with a new and noteworthy?

  4. Konstantin Komissarchik says:

    > We should explore that. Should we replace the review documentation with a new and
    > noteworthy?

    +1

    Every minor release can be required to have a “new and noteworthy” document. Every major release can be required to also provide a “migration guide” document. Everything else in current release review documentation can be automatically generated from existing sources.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s