Diversity in Open Source Projects

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.

Reference: Diversity in Open Source Projects from our JCG partner Wayne Beaton at the Eclipse Hints, Tips, and Random Musings blog.

Related Whitepaper:

Software Architecture

This guide will introduce you to the world of Software Architecture!

This 162 page guide will cover topics within the field of software architecture including: software architecture as a solution balancing the concerns of different stakeholders, quality assurance, methods to describe and evaluate architectures, the influence of architecture on reuse, and the life cycle of a system and its architecture. This guide concludes with a comparison between the professions of software architect and software engineer.

Get it Now!  

Leave a Reply


9 − = eight



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

20,709 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books