Community Standards in FOSS
Community Standards in FOSS
From our recently-released Open Source Guide, read how Zone Leader Lisa Smith frames the current state of community standards in open-source communities.
Join the DZone community and get the full member experience.Join For Free
Find vulnerabilities in your open source libraries in seconds. Get your 30 day free trial today!
One of open-source software's greatest assets — the egalitarian structure of group ownership — introduces one of its thorniest problems— enforceable community standards. As participation in open-source projects grows, so do the problems inherent in any group setting, namely how problem behavior is addressed, corrected, and if needed, punished. Balancing protection and participation is a struggle experienced by projects large and small alike.
Throughout 2017, tech companies reckoned with their bias, harassment, and abuse issues in very public ways. Most of these companies, however, had HR departments or reporting structures in place, though in many cases they were ineffective. Open-source projects lack both of these, which both exacerbates the problem and allows it to go un- or under-reported. Frequently, targets of abuse are forced out of communities either directly through harassment or subtlety by lack of support. Compounding this lack of support is the guilt that goes along with being perceived as unsupportive of the community when reporting problems or ultimately leaving projects. Problematic projects can be toxic, support collaboration in name but not in spirit, make newcomers feel unwelcome, espouse a culture that is exclusionary in word or deed, and lack clear pathways to leadership for interested parties who are not already in such roles.
Technology in general suffers from a lack of diversity and struggles with inclusion and the communities surrounding open-source projects are frequently even more difficult for underrepresented groups to penetrate because of their structure. It takes intention and work to make a community inclusive and if no one in leadership is attentive to addressing these issues it is easy to overlook or ignore. Groups working with AI, for example, will fail to address vital components in their algorithms by not addressing inclusivity in their development process. As with the larger tech community, inclusion and diversity are not simply pipeline problems but systemic hurdles that need to be overcome with support, mentoring, and active interventions.
Community standards and codes of conduct in open-source communities are important tools to strengthen inclusion, encourage retention, and expand opportunities for all members to participate at every level. Systems need to be put in place to not only encourage contribution from all kinds of participants, but to address flawed interactions and abuses of power and privilege.
Many communities have relied on a “Be excellent to each other” or “Just be nice” policy that sounds kind and hip and breezy, but lacks structure, enforcement, concrete examples of what constitutes unacceptable behavior and consequences. Long-standing members cannot be perceived as untouchable simply by virtue of tenure or number of contributions. Allowing misconduct to stand from any member is unacceptable, but when high-volume contributors are given a pass because they are “valuable” to a project, that only serves to make everyone else feel undervalued or worthless entirely. By trying to minimize the risk of “offending” some users, many are effectively silenced. Open-source communities frequently suffer from the fallacy of composition, or believing that what is good for one member is good for all members. Because open-source projects are at their foundation, many people coming together around a shared goal their intentions are always believed to be good despite examples of misbehavior.
Other concrete steps include understanding implicit biases and how to adapt and overcome them, working to use inclusive language at all times, not just when it appears convenient, calling out misbehavior when it occurs and addressing the same in as positive a manner as possible without invalidating the feelings of those affected.
Limited resources are frequently cited as the reason for not investing in governance, but that is a fallacy of short-term economics that fails to take into account future productivity losses when good potential contributors are driven away from toxic projects. Investing in a sustainable model where positive outcomes are encouraged, like "be welcoming," instead of trying to be flippant by asserting "don’t be a jerk" leads to more sustainable inclusion policies. Quality and kindness do not have to be mutually exclusive. And this investment doesn’t have to be costly — as a leader in a large open-source project wisely said, “Don’t roll your own Code of Conduct.” This hard work has been done already. The issue that is more important is to actually adopt a code of conduct and enforce it. Communities that are reluctant to adopt CoC’s for fear of alienating core contributors do so to their own detriment. Having a CoC that is watered down or isn’t enforced is as bad or worse than having none at all. Paying lip service to the concept helps no one. In a 2017 survey on diversity and inclusion in open-source, Mozilla found that the majority of respondents thought that even if their community had a CoC they were skeptical that it was enforced at any level.
To combat this skepticism and inertia, Mozilla has proposed a scalable system for community guidelines that address all of the waypoints between discovery and resolution. Discovery includes accessible information on how to identify and report issues and timelines for the full process as well as specifying who has access to that information since fear of retribution or exposure is a powerful deterrent in reporting.
After discovery comes reporting — a form-based system of easily documenting and quantifying incidents. Once reporting has happened the triage step tags incidents tying them to action triggers and additional communication.
Once an incident has been reported and triaged, it must be investigated and acted on by the appropriate groups, identified by roles defined in a RASCI — who is Responsible, who will be held Accountable, who is in a Supportive role, who should be Consulted, and who is Involved.
Following investigation, a recommendation must be made, based on an escalation of response to the severity of the violation. They have proposed a 5-level escalation ladder from no action to revocation of access to tools and communities.
Once a recommendation has been made, notification of this recommendation must be made to the reporter and the reported. Follow-up will then include concrete plans of action, including the safety of people in situations of risk.
The final step of resolution is only achieved when all the actions of the recommendation have been completed and all parties have been notified.
In the course of proposing this system, the team working on the project reports learning many valuable lessons including the importance of providing and ensuring anonymity for reporters,making sure that resolutions include both teaching and learning, not just punitive actions, making sure that reinstatement procedures include intensive onboarding to try to set up future successes, and ensuring that self-care is part of the process for the front-line members of the community handling these issues. You can read all about Mozilla’s process here, and contribute to their Diversity and Inclusion repo on Github.
2018 has been pledged as the year open-source improves itself by making participation safe and satisfying for participants at every level. Organizations like Stack Overflow are admitting their shortcomings and making concrete plans to address them. Open-source needs to grow and adapt as a whole so that projects can continue to flourish and a strong community of participants grows far into the future.
Opinions expressed by DZone contributors are their own.