When you contribute to open source projects, Dawn Foster makes it abundantly clear that even if “you’re there on behalf of [a] company, you need to do the right things for the community.” In this episode of Community Signal, Dawn outlines the principles that she follows and shepherds as the director of open source community strategy at VMware’s Open Source Program Office. These principles foster projects and communities that are collaborative and encouraging, but of course, it does not always pan out that way. Dawn discusses how documentation and education, having a clear commitment from the company managing the open source project, and balancing for collaboration instead of number of contributions can all help to build healthy open source communities. Unlike social platforms that optimize for getting everyone to contribute an infinite amount, open source projects rely on spreading knowledge and contributions amongst the group. “In some cases we have open source projects [where] almost all of the contributions are made by a single individual. What happens if that individual wins the lottery and leaves VMware, and doesn’t want to work on this project anymore?” That’s a great question for all of us that manage communities. If our top contributors left tomorrow, who would pull the community forward? Patrick and Dawn also discuss: Evaluating open source community health The tools and documentation that help with governance Evaluating the risk of contributing to an open source project Our Podcast is Made Possible By… If you enjoy our show, please know that it’s only possible with the generous support of our sponsors: Vanilla, a one-stop shop for online community and Localist, plan, promote, and measure events for your community. Big Quotes Good documentation begets good contribution practices (7:00): “Even though I’ve been contributing to open source projects for years, every time I pop up in a new community, I still have to read the contribution docs because there will [always] be something that project does in a very specific and nuanced way that the last project I worked on didn’t do. In a lot of cases, people just make mistakes and they don’t really think about what they should have been doing. They just need a little more education.” –@geekygirldawn Illustrating contributor risk (18:37): “Some of these big open source projects are maintained by fewer people than you might think. The biggest example I can think of was OpenSSL. There was a huge security vulnerability in OpenSSL. It’s a technology that almost every single company in the world relies on. This vulnerability was going to require a lot of time and effort to fix. What we quickly realized was that OpenSSL was maintained part-time by two people, none of whom were being paid to work on it.” –@geekygirldawn To truly be open source means to cede a bit of control (23:20): “You don’t, as a company, want to dominate the entire [open source] project because if you do that, you might as well never have open sourced it. You might as well have kept it proprietary. The whole purpose of open sourcing it is you collaborate together, and you innovate, and you get ideas that you wouldn’t have otherwise had as a company.” –@geekygirldawn Open source thrives through collaboration (26:41): “Some of the more social platforms, it’s like the more social, the better. Collaboration doesn’t necessarily work that way. You don’t get more collaboration because I did more stuff. You get more collaboration because you got more people involved, and you gave them some space to contribute.” –@geekygirldawn The benefit of neutral foundations for open source projects (29:42): “What you get by putting [an open source] project into these neutral foundations is some assurance that everybody’s working together on a level playing field. If I want to contribute to a Linux Foundation project, I can rest assured that I can participate on the same field as everybody else. Whereas, if the project is ow