Personality in Open Source
In September, Ether Shein interviewed me for an article she was writing for Functionize about how personality affects the development process in open source projects. The article was inspired by a study published in 2019 about the effects of personality traits on the acceptance of pull requests. Both the article and the study are worth a read.
What follows are my responses to the questions Esther sent.
What is your reaction to the research suggesting that a developer’s personality has an impact on the ability to successfully contribute to an open source project?
What’s the adjective for “the furthest thing from surprised”? Because whatever that word is describes my reaction to this finding. While the research phrases it academically as “personality,” what they mean by that is someone’s ability to interact with others, the application of social interaction skills as well as technical skills.
Of course social interaction is critical to a successful open source contribution, because it’s critical to any endeavour that involves more than one human being. 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. This is why we as humans spend so much time researching and discussing how to interact better: it affects everything we do as a civil society.
It’s also why so much of my book ended up being about the social interactions involved with contributing to an open source project: it’s vital to the success of your contribution. 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. However, we have relatively little documentation about the social expectations for that contribution. Not that projects ignore the social expectations, of course; it’s simply that they rarely document them. Instead these expectations are a part of the tribal knowledge that a new contributor is expected to absorb. This can lead to a frustrating contribution experience. The book collects these previously unwritten social rules of open source contributing in a single spot, giving people a better chance of success.
Which isn’t to diminish the importance of the findings of this research. These personality factors have a massive impact on the end result of an open source contribution, and this research has done a lot of work to prove that. Unfortunately, many people require that proof. They would rather throw a [citation needed] gauntlet on the table than make an effort to learn how to interact better with others. This research is the latest in a long line of responses to that gauntlet.
Should maintainers apply personality categorisation methods to open source contributors?
People who are curious about where they score in the Big Five personality traits can take the test at Open Psychometrics, while simultaneously (but optionally) contributing their results to ongoing research: http://openpsychometrics.org
As pointed out by the researchers, so far Big Five holds up to rigorous study. As such, it’s proven useful for broad sociological research such as this. Other personality type methodologies, such as the Myers-Briggs Type Indicator (MBTI), do not hold up to study and are considered problematic.
Regardless of personality categorisation method, a category is not a judgement. For instance, scoring lower in the Neuroticism factor in Big Five simply means your emotional state is more variable as compared with the others who took the test. It’s a research label, not a diagnosis.
I believe it would be dangerous for individuals or projects to start incorporating this research into their contribution workflows at this time. It’s easy to picture some nightmare of a startup spinning up to “leverage AI, ML, and NLP to analyse your open source contributions and maximise the contributor-maintainer synergy, creating a more scaleable, sustainable, and delightful contribution experience” or some such rubbish.
Yes, responding to and reviewing contributions can be time consuming, but applying generalisations intended for research to real-world situations typically causes more harm than good. Please bury that terrible startup idea in a deep hole somewhere and pretend it never existed.
How about the impact of social traits, professionally speaking, when it comes to software development?
You can’t feasibly remove people from software development. Even if you go low-code or were to step into a sci-fi world and automate all code generation, you’re still creating software to solve problems for humans. Humans must be involved in the process somewhere, or it’s very unlikely that their needs will be met (in which case, why bother having the software at all?).
Right now code generation isn’t automated (for the most part); code is written by people. People creating software to solve problems for other people. With so many people in the mix, of course social interactions will have an outsized impact on the end result. Communication, conflict resolution, and empathy are key to successful social interactions. They’re important, and thankfully they’re learnable. You may never be perfect at—for instance—conflict resolution, but you can learn how to get better at it.
Therefore a practical takeaway from this research is that time spent learning how to improve your social interactions will have a larger return on investment for your career than the time spent improving your technical skills. Which isn’t to say that you should neglect your technical skills. This isn’t an either-or situation; it’s both-and. A software development career with technical but not social improvements is like a cake without the sugar: not very appealing.
Another important and practical takeaway from this research is the one that most people are overlooking: Having a diversity of social traits in an open source community leads to a better contribution experience. There’s plenty of research that supports this. Homogeneous teams consistently underperform those with diverse membership. In this case, the researchers found that communities with diverse social and personality traits have more successful (i.e. merged) contributions. Therefore it follows that anything you can do to increase the human diversity in your open source project will also lead to more contributions.
That’s a powerful finding, and is possibly more important than the findings that are focused on the individual person submitting or reviewing a contribution.