Hi Jay,
If I had to chose between "a couple of contributions that don't bring much to the
table but have the potential to break something and make my life difficult to making
the blame annotations useless" and "keeping the existing high-value committers in high spirit
by not putting them through this kind of breakages that could cost them their weekend,
discussions like these in the name of broader mind", then I will go with the latter
every single time.
Let's try another choice (which is a corollary): if you have to choose between "JDT becomes a more diverse project with more contributors, but at the cost of something broken from time to time, and useless blame annotations" and "Only Jay and Stephan and a few other blessed people work on JDT forever because apparently we assume all other committers are not good enough for this task", which one would you chose? And even further, which one would your project manager choose as being the most strategic in mid/long-term? Which one do you think Red Hat, which is investing in Eclipse stack and consuming it downstream, should encourage to make it's JDT-based offering last the longest?
Relying on a few non-replaceable people is a risk for the project they support, it's management 101. So to mitigate this risk, there is no other way than trying to get more people involved in the project to learn from the experts, progressively taking care of some of their tasks. Of course, this is not perfect at 1st try, it requires training, and this is sometimes extra work for the experts to deal with this "training". But in the end, it's profitable for everyone.
An OSS project community that is not willing to welcome and train new contributors is IMO putting an extremely high risk on the project of dying as soon as a few individuals reduce their investment (for whichever reason). This risk is strategically much bigger than the risk of something broken in the code from time to time.
Cheers
