Google software engineer Jessica Frazelle on the life of a large scale open source project

Tips and tools for building and nurturing open source contributors, maintainers, and supporters, from someone who's been there.
425 readers like this.
open source work experience

Google software engineer Jessica Frazelle is an experienced open source contributor, having participated in Docker, Go, Kubernetes, and the Linux kernel. Over time, she's spotted a number of tools and tips for building and nurturing large open source projects, which she shared in her talk at OSCON 2017, The Life of a Large-Scale Open Source Project.

Here are some of the points she shared.

Tips for getting and retaining contributors

  • Create help-wanted labels on your issue tracker. Explicitly marking some issues as newbie-friendly can draw new activity and help new contributors grow.
  • Be aware of any internal decision-making dynamics. If a project originated inside a company, there may be internal discussions about the project that should be openly shared.
  • Define non-code contributions. We all know that docs are needed, but loudly saying so can help encourage contributors.
  • Value positive reinforcement to turn new contributors into repeat contributors.
  • Be respectful of contributors' time.
  • Clearly define processes for people officially becoming contributors and maintainers. If someone wants to get into project maintenance, they need a defined promotion path.

Tips for nurturing maintainers

  • Create explicit guidelines for acceptable patches and release cutoffs.
  • Encourage frequent contributors to take on more responsibility.
  • Distribute control, starting with low-risk items.
  • Governance is crucial—and also one of the hardest things to do well! The ability to change those in power should not lie with those in power.

Dealing with inevitable vulnerabilities

  • Define a process for dealing with vulnerabilities, and make it public!
  • Make sure users know when and how to upgrade in a way that won't break their world.
  • Keep bug reporters and researchers informed; once you have them in the loop, you don't want them going rogue! Do this well, and some might become contributors.
  • Do not compromise on disclosure dates so that someone can give a talk at a conference. Stick to the process in all cases.
  • Define what happens when the process fails because—at some point—it will.

Dealing with the companies that support the project

  • What happens to fiery passion when it is fueled by a paycheck from a company? It's still possible, but be honest about it.
  • Encourage companies to hire from the community.
  • Maintainership must be earned. Make new hires play by the same rules.
  • Allow saying "no."
  • "Looks good to me" patches last forever—keep the trust of the community, and treat all patches fairly. Patches are tied to individuals, not companies.
  • Love your corporate overlords for funding you. Find a balance between corporate and community needs—collaboration and compromise are the key.

What lessons have you learned from working on open source projects? Share your tips and tricks in the comments.

User profile image.
Ruth Holloway has been a system administrator and software developer for a long, long time, getting her professional start on a VAX 11/780, way back when. She spent a lot of her career (so far) serving the technology needs of libraries, and has been a contributor since 2008 to the Koha open source library automation suite. Ruth is currently a Perl developer and project lead at Clearbuilt.

Comments are closed.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.