>…I’m talking not about the goal of project diversification, I’m talking about the actual execution of a project to diversify itself. The DASH project has another nice tool called the Project Diversification Report. It breaks down an eclipse project by the companies working on a project and the percentage of code contributed.
In most cases this also reveals the overall knowledge silos of a project. Knowledge Silos on an open source project are BAD!
I know that in many projects there is a tendency to form knowledge silos. An example being only knowing a certain component, but not how that component is built or released. Resulting in one person or team of people only knowing a part of a system. In an open source project that is staffed by commercial adopters, this is not a practice one wants to encourage. The reason is that as soon as the commercial adopter’s interest change, they can and have in the past pulled those resources to work on other projects. Thus you have a knowledge silo that is very difficult or impossible to replace.
Another example where poor project diversification is bad, is when a project does not actively recruit or encourage contributors to bring them on a project. A perfect example of this is the Apache Xalan-J project. For all intents and purposes the main people that worked on that project were IBM committers. Since IBM’s interests in this area have changed, there is no one really left to vote or bring on new committers to a project. If the project had been more diversified it might be easier to resurrect the project (there is some movement on the xalan-dev mailing list from the community to try and add some life to it).
Why don’t projects diversify? The reasons are many and varied, but ultimately I don’t think they are encouraged by their commercial employers to actively pursue new contributions. Diversifying the contributors/committers is a good thing for the adopter. It gets more eyes on the problem, and potentially makes the base framework more usable overall. Yes, there may be some disagreement and yes you can not necessarily get your particular feature in place, but that is a good thing. As the debate and review that can and should happen may lead to a better overall design and a stronger product for the community as a whole.
I encourage you if you are a committer or project lead on an eclipse project to take a look at the Project Diversity report, what does it tell you about your own projects and sub-projects?