Maslow's hierarchy and expanding the open-source community

On the last day of SCALE 14x, Sarah Sharp delivered the morning keynote, speaking about what individual community members can do to foster increased diversity in the open-source community. Sharp took a unique approach to the question, though; she looked at the factors identified in Maslow's hierarchy of needs, examining what those in the open-source community can do at each level to help people participate fully.

The hierarchy, she said, was first articulated by Abraham Maslow in his 1943 paper "A theory of human motivation." It describes five levels through which human motivation progresses, starting at the most fundamental and with each subsequent level building on the those below. For people to reach their fullest potential, each level's requirements must be satisfied, progressively up the hierarchy. That is, it is impossible to work on level three until levels one and two are satisfied.

The exact terms applied to each level can vary a bit depending on where one looks; Sharp described them, from the lowest level on up, as "homeostasis," "security," "community," "esteem," and "self-actualization." Homeostasis is the physical-survival need. In general usage, this means needs like food and water. For a geek in the open-source community, Sharp said, the equivalent need is the ability to get into "deep hack mode" where a person sufficiently tunes out the world to pour themselves into their projects.

To get there, Sharp said, a geek needs four things: sufficient uninterrupted time, some sort of computer, the electricity to run it, and (usually) some form of Internet access. But not everyone has access to all four. Uninterrupted time is a scarce commodity for many people—in particular, for anyone who is the caregiver to someone else (children or the elderly, for instance). And caregivers today are statistically more likely to be women than men—and, disproportionately, women of color.

Things the community can do to help people with limited time, she said, include providing daycare at events like conferences or hackathons, and not treating periods of inactivity (as can happen when caregiving duties become particularly time-consuming) as a negative—which is a particularly common bias when assessing job applicants' resumes. Individuals can also support initiatives like OpenHatch that try to provide "non-standard entry points" to open-source participation.

As for computer access, it is often taken for granted these days, but reality is more complicated. Even in the US, there is a significant disparity in computer ownership based on race, and an even bigger disparity based on income. Furthermore, the statistics quoted often focus on "households with a computer" or similar metrics—but they do not tell the whole story. A household might have a computer, but in many cases it belongs to one member of the household (say, the father or an older sibling), and others in the house have limited or no access to it.

And many of the computers in such statistics tend to be low-end devices like Chromebooks when, too often, the open-source community assumes everyone has access to a powerful PC (e.g., one fast enough to run a virtual machine at comfortable speed or with hundreds of gigabytes of storage). To accommodate people with reduced access to computers, she said, projects can set up development servers on which community members can run builds or do other work. They can also donate systems to non-profits that revamp them to distribute to low-income households, or contribute to low-cost-computing projects like Raspberry Pi.

Electricity and Internet access are not distributed evenly, either. In particular, it is easy to overlook the fact that people in developing regions often pay by the byte for their Internet access. This creates a barrier to entry, as many open-source projects expect new volunteers to download enormous source-code bundles or to contact the project through always-on services like IRC. A 500MB data plan in India, she said, costs the equivalent of 17 hours of average wages (and 500MB happens to be roughly the size of a current kernel source bundle). It takes an average of ten page clicks to file a bug report, she said, which at the average web page size works out to nearly an hour's wages in India. That makes bug reporting a rather unappealing way to contribute.

Projects can help reduce these barriers to entry by consciously reducing their web site's footprint (in terms of of bandwidth and page-click count), by fully supporting asynchronous communication channels, and by bundling important resources like documentation with source-code downloads. In addition, she noted that Git still does not support interrupting and resuming download operations, which is an important bug to fix. And few web sites make any effort to detect when a session is over a slow or unreliable connection; site owners would do well to fall back to low-bandwidth versions of a site in such circumstances.

The homeostasis level occupied the longest portion of the talk, Sharp said, but that is because it is the most fundamental. The next most fundamental level is security, which means ensuring that each individual feels personally safe. Sharp did not want to spend time debating the frequency of online harassment, she said. Instead, she referred the audience to the Petrie Multiplier, which describes why members of a minority within a group encounter bad behavior with considerably greater frequency than do those in the majority. All else being equal, a few bad actors disproportionately make participating in the group unpleasant for those in the minority, just due to the minority:majority ratio.

The takeaway, Sharp said, is that projects should not discount reports of bad behavior experienced by those in the minority. If someone says they have experienced bad behavior, the community ought to believe it even if it does not seem to match with their own experience. Codes of conduct are what most projects employ to make people feel safe in their community; Sharp said it was good to see more and more projects using them, but cautioned that they should not be taken for a "magic checkmark." They only work when they are put into action. She also advised projects that "rolling your own" code of conduct is a bad idea akin to rolling your own cryptography. Instead, projects should contact experienced professionals like Frame Shift Consulting or Safety First PDX.

Codes of conduct are effective at cutting down on negative incidents, but they do not encourage participation—which is the goal at the community level of the hierarchy. Many projects would like to encourage more diverse participants, she said, but if 90% of all newcomers fail to make a contribution and drop out, minorities cannot be expected to do better.

She cited several things that projects can do to encourage new participants, including taking a look at on-boarding procedures and at documentation. Leaving newcomers to explore on their own is unlikely to succeed; projects need to document how to communicate with the project, how to get started with builds, how the release cycle works, and what the coding style and testing procedures are like. It is important to identify appropriate tasks for beginners and for intermediate participants, and to provide mentors.

The esteem level concerns recognizing a person's work, giving them attribution for their contributions, and acknowledging their successes. The key factor for enabling such recognition is providing open doors and invitations. It is too easy for us to unintentionally overlook individuals that do not match our preconceived expectations, Sharp said, and to accidentally limit who hears our invitations by advertising them only to the circles of people we already know or who resemble the people we know.

Projects can help improve this situation by deliberately focusing on growing new contributors into leadership roles: documenting what those leadership roles involve, appointing backup and "vacation maintainers," and seeking out those with diverse perspectives. Open-source projects already have a bad habit of burning out longstanding leaders and contributors, she said; introducing planned succession for leadership roles would alleviate that problem as well.

The last level, at the top of the hierarchy, is self-actualization, which means being able to reach your full potential at the things you are passionate about. It is important to recognize that self-actualization may mean something quite different to one person than another, Sharp said. For some, self-actualization means helping other people reach their full potential. She then listed a number of individuals who choose to work on projects that encourage diversity, like Mariella Paulino of Code For Progress, Asheesh Laroia and Karen Rustad Tölva of OpenHatch, Leslie Hawthorne of Google Summer of Code, and Karen Sandler of Outreachy.

But one does not need to start a large project to help other people achieve their goals, Sharp said in conclusion. Her own story, she explained, involved numerous allies along the way who encouraged her in her journey through the technical community—from her first computer, through college, into the general open-source community, the kernel community, Outreachy, and now the graphics community. Everyone in the audience, she said, can do the things mentioned in the talk. The important thing is that they stop being a bystander and start to contribute.

Note: you can avoid this step in the future by logging into your LWN account.