Exceptional Circumstances

Sometimes open source projects lose steam. This is the way of things. Developers get pulled off projects. Sometimes the resulting gaps get filled naturally. Diversity in a project is one way of making sure that gaps fill naturally: if the developers from one organization lose interest, then developers from other organizations step in. The more organizations involved in a project, the better; more involvement means more options when one of the contributors steps away.

But sometimes gaps don’t get filled. This is generally the case when the sole sponsor of a project steps away. Sometimes the right thing to do is to just terminate the project. The Eclipse Technology PMC, for example, terminates inactive projects in a regular annual purge.

Sometimes the right thing to do is to find replacement developers for a project. This may be the case, for example, if the project code is being used by adopters who have not yet stepped up to join the project. The Eclipse Development Process has a provision for this. Section 4.6 states (in part):

In exceptional situations, such as projects with zero active committers or projects with disruptive Committers and no effective Project Leads, the Project Leadership Chain has the authority to make changes (add, remove) to the set of committers and/or Project Leads of that project.

This passage is useful if there is somebody waiting in the wings to take the project over. I actually don’t like to exploit this power and reserve its use for truly exceptional circumstances. If there is somebody “waiting in the the wings”, then I have to ask why? Why are they waiting and not already participating in the project? It’s also not a particularly transparent or open process. When this sort of “rip and replace” happens, we do try to document what’s happening in public mailing lists. But they tend to happen fast (at least by our standards) and oftentimes include the appointment of committers who haven’t accrued the generally-required level of merit.

When we do invoke the “rip and replace” rule, I monitor the project for a few months after the change to make sure that they are adjusting well and working in accordance with the Eclipse Development Process.