Ed Merks and I gave our talk on Tuesday about building diversity in open-source and attracting new committers to your project. A few people were interested in the talk but weren’t able to attend, so I figure I’d summarize it in two blog posts. The first post will focus on defining diversity and the second will focus on how to build diversity.
To start, we made an assertion that without diversity a project may stagnate or die. There are a few examples of this within open-source in general, but a decent example of this within the Eclipse ecosystem is the Visual Editor (VE) project.
Ed and I then defined diversity in the classic sense… just look at any dictionary and you’ll get the classic definition. However, we like to think in pictures so we correlate diversity to be similar to the variation of life forms in a tropical reef:
We also talked about how in open-source, diversity is a bit different than that of in the classic sense. In the classical sense, diversity refers to things like gender, race, age, culture, sexual orientation, religion etc…. While these things are good still in open-source, we tend to think of diversity in open-source being broken up in to these different items:
- Committer Backgrounds
- Corporate
- Academic
- Independent (Individual)
- Committer Investment
- Full-time
- Part-time
- Contributor-level
Diversity can also be measured at the macro (top-level project) level or micro (a component) level. For example, if you look at dash.eclipse.org, you can see top-level projects like Modeling which have a good amount of diversity in committer backgrounds compared to a project like BIRT where about 99% of the commits come from Actuate. We don’t necessarily believe there is inherently anything wrong with this, but this puts an open-source project at risk in stagnating or dying if Actuate decided to do something else and not invest in its BIRT-related business.
In the next part, we’ll focus on how to build diversity in the open-source space.
