>Project Diversification Sucks

>…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?

This entry was posted in eclipse, open source. Bookmark the permalink.

4 Responses to >Project Diversification Sucks

  1. Donald Smith says:

    >Just curious if there been any tangible research that shows Diverse projects are somehow better? I know there are hunches, but I'd love to find some research. All the research I see on factors contributing to open source success shows the value proposition of the project, the experience of the developers and number of developers as being most important.From a purely selfish perspective, I like diversity because it means if Organization A runs into some sort of distraction (financial, merger, market), then Organization B can keep the project going. But aside from that purely selfish point, I'm not convinced diversity actually makes a project better in terms of quality. – Don

  2. >I've blogged and talked a few times about Eclipse without IBM. The lack of diversification is only bad when that companies "interests change". I trust IBM as much as I'd like to work there again. And there is one big piece they still control and from what I can see, we are already starting to pay the price.

  3. >BTW, the diversity report is totally flawed. It doesn't take into account committers changing companies. It both under inflates diversity when committers leave the mothership (e.g. EclipseSource), and over inflates when new companies hire existing committers (e.g. a few CDT contributors).

  4. David Carver says:

    >@Donald: Let's take worse case scenario…IBM the largest contributor to Eclipse projects…pulls everybody. (See I said worse case). How many projects survive and thrive? I would lay bets on some of the modeling projects, because they have good diversification (it gets to a grey area one some individual projects though).As for a good example of what happens with a diverse project. Look at the Linux Kernel..even if Linus we to stop working on it, I don't think much momementum would be lost. Can we say the same thing…oh say..about E4 and the Platform? Again Xalan is my poster child from Apache…a popular tool, but the commercial backer's interest changed, and the project has floundered ever since. No recruitement was done to keep it diverse so that the communities needs can be met. And there is a very large community that still depends on Xalan.@Doug: Yes, I agree but how can we help encourage projects to diversify more. We've seen some on E4 but not enough from what I'm seeing in the Dash reports. Again, I think we have to take any of these metrics with a grain of salt, but they do provide some hint even if it is the extremes of where a project is.Overall though, I think projects need to do a better job of recruitement, than they do.

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 )

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s