Originally published on Opensource.com
When I worked with the Mozilla Foundation, long before the organization boasted more than a hundred and fifty staff members, we conducted a foundation-wide Myers-Briggs indicator. The Myers-Briggs is a popular personality assessment, one used widely in career planning and the business world. Created in the early twentieth century, it’s the product of two women: Katharine Cook Briggs and her daughter Isabel Briggs Myers, who built the tool on Carl Jung’s Theory of Psychological Types (which was itself based on clinical observations, as opposed to “controlled” scientific studies). Each of my co-workers (53 at the time) answered the questions. We were curious about what kind of insights we would gain into our individual personalities, and, by extension, about how we’d best work together.
Our team’s report showed that the people working for the Mozilla Foundation, one of the biggest and oldest open source projects on the web, were people with the least common personality types. Where about 77% of the general population fit into the top 8 most common Myers-Briggs types, only 23% of the Mozilla Foundation team did. Our team was mostly composed of the rarer Myers-Briggs types. For example, 23% of the team shared my own individual personality type (“ENTP”), which is interesting to me, since people with that personality type only make up 3.2% of the general population. And 9% of the team were ENTJ, the second rarest personality type, at just 1.8% of the population.
I began to wonder: Do open source projects attract a certain type of personality? Or is this one assessment of full-time open sourcers just a fluke?
And if it’s true, which aspects of personality can we tug on when encouraging community participation? How can we use our knowledge of personality and psychology to push our open source projects towards success?
The personalities of open source
Thinking about personality types and open source communities is tricky. In short, when we’re talking about personality, we see lots speculation.
Personality assessments and, indeed, the entire field of psychology are often considered “soft science.” Academics in the field have long struggled to be seen as scientifically relevant. Other subjects, like physics and mathematics, can prove hard truths—this is the way it is, and if it’s not like this, then it’s not true.
But people and their brains are fascinatingly complicated, and definitively proving a theory is impossible. Conducting controlled studies with human beings is difficult; there are ethical implications, physical needs, and no two people are alike—so there is no way to have a truly stable control group. Plus, there’s always an outlier of some sort, because our backgrounds and experiences structure our personalities and the way we think. In psychology, the closest we can get to a “hard truth” is something like “This is mostly the way it is, except when it’s not.” Only in recent years (and with recent advancements in technology) have links between psychology and neurology provided us with some psychological “hard truths.” For example, we know, definitively, which parts of the brain are responsible for certain functions.
Emotion and personality, however, are more elusive subjects; generalizations remain difficult and face relevant intellectual criticism. But when we’re thinking about designing communities around personality types, we can work with some useful archetypes.
After all, anyone can find a place in open source. Millions of people participate in various projects and communities. Open source isn’t just for engineers anymore; we’ve gone global. And while open source might not be as mainstream as, say, eggs, I’m confident that every personality type, gender identity, sexual orientation, age, and background is represented in the global open source community.
When designing open source projects, you want to ensure that you build architectures of participation for everyone. Successful projects have communities, and community-building happens intentionally. Community management takes time and effort, so if you’re hoping to lead a successful open source project, don’t spend all your resources on the product. Care for your people, and your people will help you with the rest of it.
Here’s what to consider as you begin architecting an inclusive community.
Introverted versus extraverted
An introvert is someone who gains energy from solitude, while an extravert gains energy from being around other people. We all have a little of both. For example, an introvert teaching might be using his extravert mode of operation all day. To recharge after a day at work, he’d likely need to go into quiet mode, thinking internally. An extravert teacher would be just as tired from the same day, but to recharge he’d want to talk about the day. An extravert might happily have a dinner party and use that as a mode of recharging.
Another important difference is that those with an extravert preference tend to do a lot of their thinking out loud, whereas introverts think carefully before speaking. Thinking out loud can be difficult for an introvert to understand, as she might expect the things being said to have already been thought about. But for an extravert, verbalizing is a way of figuring stuff out. They don’t mind saying things that are incorrect, because doing so helps them process information.
Introverts and extraverts have different comfort levels with regard to participation; they may need different pathways for getting involved in your project or community.
Some communities are accustomed to being marginalized, so being welcoming and encouraging becomes even more important if you want to have a diverse and inclusive project. Remember, diversity is also intentional, and inclusivity is one of the principles of an open organization.
Not everyone feels comfortable speaking in a community call or posting to a public forum. Not everyone will respond to a public list. Personal outreach and communication strategies that are more private are important for ensuring inclusivity. In addition to transparent and public communication mechanisms, a well-designed open source project will point contributors to specific people they can reach directly.
Strict versus flexible
Did you know that some people need highly structured environments or workflows to be productive, while others would become incapacitated by such structures? For many creative types, an adaptive and flexible environment or workflow is essential. For a truly inclusive project, you’ll need to provide for both. I recommend that you always document and detail your processes. Write up your approaches, make an overview, and share the process with your community. I’ve done this while working on Greenpeace’s open source project, Planet 4.
As a leader or community manager, you need to be flexible and kind when people don’t follow your carefully planned processes. The approach might make sense to you and your team—it might make sense to a lot of people in the community—but it might be too strict for others. You should gently remind people of your processes, but you’ll find that some people just won’t follow it. Instead of creating a secondary process for those who need less structure, just be responsive to whatever the request might be. People will tell you what they need; they will ask the question they need answered. And then you can generate even greater participation by demonstrating your own adaptability.
Certainty versus ambiguity
Openly documenting everything, including meeting notes, is a common practice for open source projects and communities. I am, indeed, in the habit of making charts and slides to pair with written documentation. Different brains process information differently: For some, a drawing is more easily digestible than a document, and vice versa! A leader in this space needs to understand that when people read the notes, some will read the lines and others will read between them.
The preference for taking things at face value is not more correct than a preference for exploring the murky possibilities of differing kinds of information. People remember meetings and events in different ways, and their varying perspectives can cause uncertainty around decisions that have been made. In short, just because something is a “fact” doesn’t mean that there aren’t multiple perspectives of it.
Documenting decisions is an important practice in open source, but so is helping people understand the context around those decisions. Having to go back to something that’s already finished can be frustrating, but being a leader in open source means being flexible and understanding the neurodiversity at work in your community.
Objective versus subjective
Nothing in the universe is certain—indeed, even gravity didn’t always exist. Humans define the world around them; it’s part of our nature. We’re wonderful at rationalizing occurrences so things make sense to us.
And when it comes to personality, this means some people might see an objective reality (the facts defined and unshakeable, “gravity exists”) while others might see a subjective world (facts are merely stories we tell ourselves to make sense of our reality, “we wanted a reason that we stick to the Earth”). One common personality conflict stems from how we view the concept of truth. While some people rely on objective fact to guide their perceptions of the ways they should be interacting with the world, others prefer to let their subjective feelings guide how they judge the facts. In any industry, conflicts between varying ways of thinking can be difficult to reconcile.
Open leaders need to ensure a healthy and sustainable environment for all community members. When conflict arises, be ready to “believe” everyone—because from each of their perspectives, they’re most likely right. Note that “believing” everyone doesn’t mean putting up with destructive behavior (there should never be room in your community for racism, sexism, ageism or outright trolling, no matter how people might frame these behaviors). It means creating a place that allows people to respectfully discuss and debate their perspectives. Be sure you put a code of conduct in place to help with this.
Inclusivity at the fore
In open source, practicing inclusivity means seeking to bend your mind towards ways of thinking that might not come naturally to you. We can all become more empathetic towards other people, helping our communities grow to be more diverse. Learn to recognize your own preferences and understand how your brain works—but also remember that everyone’s neural networks work a bit differently. Then, as a leader, make sure you’re creating space for everyone by championing inclusivity, fairness, open-mindedness, and neurodiversity.
(Special thanks to Adam Procter.)