How personality traits affect the open source development process
Perhaps you are a skilled technologist. But beware: If your personality is as scintillating as a dish rag, you could jeopardize your open source projects.
Perhaps you are a skilled technologist. But beware: If your personality is as scintillating as a dish rag, you could jeopardize your open source projects.
According to a recent study, a developer’s personality could significantly impact their contributions to open source projects. The researchers at the University of Waterloo found that social factors, including experience, remain the most influential factors in whether a contributor’s work is accepted or rejected. But the study also found that personality traits play a key role in how their work is perceived.
“People who voluntarily work on open source projects need to be aware of how open they are to change and how conscientious they are, as these two personality traits will impact how willing people are to work with them,” says Meiyappan Nagappan, a professor in Waterloo’s David R. Cheriton School of Computer Science and a co-author of the study, in a statement.
Nobody works in a vacuum. A person’s behavior comes out when they interact with other people, whether it’s in person, in a Slack channel, or in code comments. Software development often involves creating a team where it’s comfortable and safe to share ideas. As the researchers note, it’s not enough to complete a task; developers also need to listen and consider other people’s opinions with an open mind. In fact, some developers say, the more diverse personalities on a team, the better the end product.
The researchers collected their data from GitHub. They analyzed the personality traits of 16,935 active developers from 1,860 projects. Each developer had at least 250 pull requests, the process by which GitHub developers notify other open source contributors working on the same project that they completed a task.
The researchers then used the IBM Watson Personality Insights to retrieve the big five personalities of the software developers in GitHub: openness, conscientiousness, extroversion, agreeableness, and neuroticism.
“We found that social factors are still more important than technical factors in getting your open source work accepted,” says Alex Yun, a master’s student in Waterloo’s faculty of mathematics and another study co-author, in a statement.
The researchers also examined the importance of personality factors. They found that biases may be involved in the acceptance or rejection of open source work. That’s true despite the apparent advantage of open source whereby you can contribute with a level of anonymity; your persona shows in your code and comments. Someone reviews and comments on your work based on what they see in front of them, and not how they know you as a person.
“Managers are more likely to accept a contribution from someone they know, or someone more agreeable than others – even though the technical contribution might be similar,” Yun says.
Developers are not surprised
People who work in the open source community agree with the research findings.
“If your work is being reviewed and you immediately shoot down any suggestions made by others, I could then foresee this negatively impacting the views of the decision makers who merge your work,” observes Matthew Arnold, a senior software engineer at global call intelligence provider Infinity.
“What's the adjective for the furthest thing from 'surprised'? Because whatever that word is describes my reaction to this research finding,’’ says VM (Vicky) Brasseur, an open source leader, speaker, and author of the book, Forge Your Future With Open Source. “While the research phrases it academically as ‘personality,’ what they mean is someone's ability to interact with others: the application of social interaction skills as well as technical skills.”
Those with an extroverted personality likely find it easier to hit “submit” when sending pull requests to open source repositories, Arnold adds. “By submitting this pull request, you're agreeing to let the internet community review and judge your work. That can be quite daunting, especially when open source projects often attract some of the finest minds in the industry.’’
To some degree, each of us can assess our own capabilities – for good or ill. Arnold’s personality falls into the introverted, intuitive, thinking, and judging (INTJ) personality type within the Myers-Briggs personality assessment. He considers himself to be open and conscientious. But we may see ourselves with a different perspective than do outsiders.
Personality traits have some impact on software development, but social factors are more influential, says Dawn Foster, director of Open Source Community Strategy at VMware. “In my experience, the social factors have had a bigger impact on my ability to successfully contribute to open source projects.”
Foster describes herself as “primarily conscientious with a bit of agreeableness,” which she says has served her well because she is usually prepared and detail oriented. This “allows people to feel more comfortable relying on me to perform my duties.” Being agreeable helps her empathize with others and make them feel welcome, she says.
Social factors carry more weight
Both Foster and Brasseur agree with the Waterloo study finding that social factors are more influential on the likelihood of pull request acceptance of contributions into open source projects.
“Open source communities often feel like very small worlds where I keep running into the same people over and over again,’’ Foster explains. “My past social interactions in previous communities have helped smooth the way for my participation in new ones.”
For example, when Foster started contributing to Kubernetes, she wanted to help out with the Contributor Summit. Because she had worked with several of the organizers on other projects who could vouch for her work, it was relatively easy for her to get involved as an organizer despite being relatively new to the project.
Another example the CHAOSS Project where Foster eventually joined its governing board. “Because many of the existing board members and maintainers knew of my past work on open source project health metrics, it allowed me to participate in meaningful ways much more quickly than I might have if I didn’t have those previous social interactions,” Foster says.
Brasseur points out that social interaction is critical not just to a successful open source contribution – but to any endeavor that involves more than one person.
“Collaboration is difficult if not impossible when people aren't able to interact well, whether due to personal skills, language differences, or some other obstruction,’’ Brasseur says. “We in open source have abundant documentation about the technical aspects of contributing, such as writing tests or the mechanics of sending your contribution for review, but relatively little about the social expectations for that contribution.”
Projects don’t necessarily ignore the social expectations, Brasseur adds. “It's simply that they rarely document them.”
Like Foster, Arnold says that being open, conscientious, and agreeable has benefited him professionally. These traits have helped him to “gel well with teammates, which to me is a massive benefit.” But, he adds, “I have to be careful, however, that I don't let this cloud my judgement when receiving feedback around changing how I have done something. I need to make sure I'm not too quick to go with what makes the other person happy.”
The result is a willingness to accept suggestions that go against his initial view. “My impediments tend to come from a lack of extroversion along with levels of neuroticism,” Arnold says, “making experiences such as presenting and training a lot more stressful and anxiety inducing than they necessarily need be.”
Don’t expect arguments. Most developers are agreeable! “The times that I see a pull request being hindered most by personality are when you have a small pool of developers reviewing the work,” Arnold says. In those cases, “The author is implementing review comments without really critiquing the suggestions, which can sometimes cause a reduced level of quality.”
Being a good communicator speaks volumes
Someone who is a good communicator always is in demand. Employers are always looking for that soft skill in candidates across industries, says Lusen Mendel, director of developer relations at Karat, which conducts technical interviews for organizations hiring developers.
“Just as we validate software correctness with tests, it often takes bouncing ideas off a peer to validate the degree of our own understanding and the effectiveness of our insights,’’ Mendel says. “Being a good, concise communicator lets developers quickly identify what information is salient to specific brainstorms, decisions, and open source projects.”
In virtually every interview Karat conducts, regardless of what they were supposed to be evaluating, “Interviewers inevitably tell the hiring manager how the candidate communicated,’’ he notes.
More change is needed
While he is not a developer, Jack Wallen, who has covered open source for decades as a journalist, finds that “Developers are very much like artists, in that they can be very sensitive to criticism and place a very high value not only on their work, but on the acceptance of both their work and who they are.”
Many developers pride themselves on their individuality and tend to hold that trait very dear, Wallen says. “That can translate to either being very satisfied with a project, when they and their work are accepted – or walking away when they are not.”
For Wallen, there is another longstanding issue in the development community that needs to be addressed. “It’s become clear that there needs to be significant improvement in the way the development community treats people of color, women, and members of the LGBTQ community,” he says. “At this point, there must be a zero tolerance for unwanted or unequal treatment.”
Wallen says he knows very talented developers who have been affected by this. “And until things drastically change, there will remain an atmosphere of tension and unease.”
One element that might help optimize communication is a project champion who cares about software quality. This white paper goes into detail about the role of a Chief Quality Officer.