Starting a Healthy Open-Source Organization
--
When Julie Tennett and I took over Scout Studio at the end of October, we agreed that the best way to push the studio even further was to start sharing our code with the world the same way we share our designs. The best way I could think to do this was to start open-sourcing code so other people could see the incredible work that our developers have done.
One thing I wanted to be conscious of was inequalities in the developer community and the unfortunate fact that open source projects can tend to harbor a bit of a toxic and sometimes hostile environment. As a result I wanted to focus on fostering a safe, healthy environment which would allow for constructive collaboration. This was an especially poignant goal for an organization full of students. I wanted to provide a safe space for students to learn and grow without exposing them to microaggressions and discrimination. We decided to share this strategy with everyone as a case study on how to create a healthy open-source organization to avoid any of the toxicity that open source organizations have a tendency to attract.
At Scout, we firmly believe that every open forum should have a Code of Conduct that mandates respectful behavior.
Thorough and Enforceable Code of Conduct
Our first bit of work was to ensure that everyone behaves themselves in our issues and pull request comments, so a Code of Conduct was a no-brainer. At Scout, we firmly believe that every open forum should have a Code of Conduct that mandates respectful behavior. For Scout, this could mean everything from our conference, Interventions, to any of our open source projects. We borrowed heavily from the WeAllBehave Code of Conduct to ensure we were thorough in the transgressions that are prohibited in our projects. We can’t thank the WeAllJS team enough for their work to create a meaningful Code of Conduct that can be used universally.
The second piece of this is to make sure that a Code of Conduct is enforceable, and for this we again have WeAllJS to thank. Their Code of Conduct, by default, includes enforcement mechanisms and examples of inappropriate behavior. If there are ever violations of the Code of Conduct, no contributor has an excuse to say they were not aware of potential repercussions, as they’re outlined in detail in our organization-wide Code of Conduct.
Finally, we ensure that our Code of Conduct is always up to date across all of our projects by linking each project to the organization-wide Code of Conduct instead of placing copies of the document in each repository. This allows us to maintain a single source of truth for the Code of Conduct rather than having to update several copies if/when it changes.
No More `master`
A long-standing tradition in git, and an unfortunate default in new GitHub repositories, is naming the default branch master. At Scout, we make a conscious effort to avoid using this terminology, which has a problematic history, and instead name all of our default branches develop and ensure that we remove the master branch from the repository. Contrary to what some traditionalists might expect, all of our developers are completely alright with this and were able to handle the cognitive load of using develop as their default branch.
What’s more, the term develop is actually a better description of what is in the branch. The branch is the latest working copy of the code, regardless of what’s live in the npm registry. When we cut major releases we name them based on the version in the branch, but because of the distributed nature of git there’s never a true “master” version of the code, so we said goodbye to “master.”
Vulnerability and Accountability is Key
Despite all of that, we felt that being enforceable and thorough wasn’t enough. If something is enforceable but there is no one to enforce it then what’s the point? For this initial “version” of our open source organization I decided as Technology Director it was my responsibility to be the enforcer of our policies. Furthermore, I decided that I can’t be held accountable unless I’m making myself a bit vulnerable and exposing myself to public criticism. All of our open source projects have my real name on them, with links to my personal email address and public Twitter account. As the maintainer of the organization I wanted to be vulnerable so if I make mistakes there is a forum for the affected contributors to provide commentary on those mistakes.
I also want to pause and acknowledge that because of the overwhelming presence of toxic behavior in open-source, many OSS maintainers can’t publish this information without fear of harassment and stalking. Maintainers who don’t have this luxury shouldn’t be asked to provide their own information publicly, as personal safety is paramount, which I mentioned earlier. Similarly, those who are able, like myself, should work with maintainers to help use our privilege to provide safe spaces for those who aren’t in the same situation. I’m hoping that this exercise will help enable marginalized populations to thrive and be successful.
Every member of Scout, past and present, has write access to all of our open source projects. We trust all of our members to use their best judgement when helping to maintain our projects.
Accessibility and Trust are Important
Lastly, we believe a big part of a healthy organization is embracing the idea of “openness” in the context of the internal organization. Every member of Scout, past and present, has write access to all of our open source projects. We trust all of our members to use their best judgement when helping to maintain our projects. We want all members of the organization to have input on decisions and be able to contribute as much as possible. The only thing they don’t have access to is publishing packages to npm. We decided that the security trade-off of giving everyone access to npm was not worth the gain in accessibility.
While we’re a young open-source organization, and our projects have yet to see many contributions, we’re proud of the safe, healthy open source culture we’re striving to create, and we’re hoping that sharing our code with the rest of the world can teach others a bit and can teach us even more. We’ve published four projects so far and we’re looking to continue to make our open source footprint even larger in the future. Interested in helping out with our projects? Check them out here.
Interested in applying to be a client of Scout’s design studio? Information about applications is available here!
