At this year's Opensource.com Community Moderator's meeting in Raleigh, North Carolina, Red Hat CEO Jim Whitehurst made a comment that stuck with me.
"Open source's supply chain is source code," he said, "and the people making up that supply chain aren't very diverse."
Diversity and inclusivity in the technology industry—and in open source communities more specifically—have received a lot of coverage, both on Opensource.com and elsewhere. One approach to the issue foregrounds arguments about concepts that are more abstract—like human decency, for example.
But the "supply chain" metaphor works, too. And it can be an effective argument for championing greater inclusivity in our open organizations, especially when people dismiss arguments based on appeals to abstract concepts. Open organizations require inclusivity, which is a necessary input to get the diversity that reduces the risk in our supply chain.
So why does diversity matter in source code, particularly when the openness theoretically means the pool of contributors is everyone on Earth?
This phrase is sure to be familiar with open source advocates: "vendor lock-in." That term is a four-letter word to many organizations. The idea of being so tied to a single supplier that a change in the supplier's business practices (e.g., pricing models) could have a dramatic effect on the organization gives leaders nightmares. Whether it's the raw material used to make a product, software used to run the business, or anything else, organizations like to have options.
They might never switch to an alternative, but just having the ability to do so helps to mitigate risk. A company might be perfectly happy to keep buying their desktops from Company A because they know if Company A's quality or price ever changes too much, Company B is available. Even within a particular provider, having options aids resiliency. Anyone designing a fault-tolerant cloud service will put resources in a variety of regions, even if it all runs on the same provider.
Similarly, narrowing the pool of people who write our code narrows the range of experiences from which we can draw. Everyone's life is unique, but people can still have remarkably similar experiences when viewed more broadly. Because we write source code to solve problems for people and people are diverse, we need to have a diverse pool of contributors. The actual lines of code might not benefit much from diversity—there are only so many ways to write a printf statement, for example—but the design of that code (and the capabilities it implements) most certainly does.
Have you ever walked down the street with someone on crutches? Or gone through a tall buffet line with someone in a wheelchair? Or watched a woman's replies when she makes an unpopular statement on a social network? People experience the world in different ways, and if we don't design our technology with that in mind, we will fail to serve the people we want to serve.
It's natural to not consider scenarios that you're not familiar with. Even when you try to consider all of the ways your technology may be used (or not used!), it's a challenge and you will miss some things. But having more diverse teams means that you will naturally catch more use cases. And that will help the team brainstorm new ones. You still won't catch everything, but you'll make progress. You'll avoid the risk of bad publicity, lost users, lost funding, etc., because you won't make mistakes that would be obvious to someone who has different experiences from you.
The diversity of your supply chain might not make you successful on its own, but it will help prevent failure.
Comments are closed.