I’ve been talking a lot about diversity lately. There are, of course, different kinds of diversity; but when I talk about diversity, I tend to mean diversity in the organizations contributing to an open source project: multiple organizations from different parts of the industry working together.
Doug tweeted recently on the topic:
Why do you need diverse projects? So when the vendor removes all it’s people, you still have a live project. Obvious, no?
I can’t argue with this. But that can’t be the entire answer. Why would any organization care whether or not a project lives on after they pull their resources?
One obvious answer is that they may still actually need the software. In that case–even though an organization needs to divest in terms of contributions–they still need to consume the output. Hypothetically then, growing diversity is important for a organization that’s pulling their resources. I suspect, however, that this is rarely the case. If an organization has an interest in consuming the output of the project, they have a very real need to stay involved with that project. At least in some capacity.
For an organization, the reasons for increasing diversity are more about the steady state: the day-to-day operation of the project.
Diversity is a great way to ensure that a project will survive through periods of time when some of the project contributors are distracted by other interests. Having more than one organization involved in an open source project means that the project will be able to weather periods of inactivity from some subset of the contributing companies. The project can survive a temporary lull in contribution.
Diversity also means a shared burden. Resolving conflicts between the interests of multiple organizations participating in a single open source project can be a real challenge. It takes work to make a diverse team function. But when it works, a single organization can get a lot more value of out a project than they put into. It’s one of those games where everybody wins (even if you do get checked hard into the board every once in a while).
The act of balancing the different interests of multiple organizations makes a code base stronger. Code bases must generalize to accommodate the use cases of everybody involved; APIs must stabilize; and schedules must be set and followed. In short, everything gets very predictable when multiple diverse interests collaborate. I don’t mean to suggest that all this goodness cannot happen without diversity, but diversity increases the probability. I have watched this happen many times.
It may be the case that organizations do not care whether or not a project continues after they divest in it (organizations aren’t people after all 
). But I know from experience that individual committers have trouble letting go. There’s a great deal of pride at stake. Everybody wants be remembered as one of the group who created a great open source project; nobody wants to be remembered as being part of the group that abandoned and let die a great open source project.
So maybe that’s enough. Open source project contributors want to have diversity because it’s the best hope of seeing their baby grow into adulthood.
