UNICEF—Developing in the open

“We are open, the door is just very heavy”

Best practices

These best practices work well even for closed-source projects; they're especially great for open-source ones, however, as they make it easy for volunteers to understand and contribute to your project.

• Keep a changelog to help stakeholders and community members keep up with your project without having to read every commit.
• Semantic versioning is a low-bandwidth way of quickly communicating to stakeholders (both humans and API clients) what has changed in your project.
• Open a Pull Request as early as possible - "Pull Requests are a great way to start a conversation of a feature, so start one as soon as possible-even before you are finished with the code. Your team can comment on the feature as it evolves, instead of providing all their feedback at the very end." Aside from being a great development practice, it can also be a great way to work in the open and co-build with your community.

  Examples:

  • An unmerged WIP PR from p5.js - while it was never merged, it still documented a useful conversation about how to move forward with a feature.
  • A merged WIP PR from exercism.io - a conversation with multiple participants.
  
  
• Avoid jargon - Going beyond necessary technical terms to write in jargon can alienate potential contributors; especially those with who may have valuable expertise to contribute to your project, but who may be unfamiliar with some aspect of it.
• Continuous integration - Services like Travis CI and Circle CI are free for open-source projects, and can be a great way to reduce friction for new contributors.
• Write a great README - CBoard's README is a great example.
• Establish a code of conduct to foster healthy and constructive community behavior.

Empathizing with contributors

Where are potential contributors coming from? What kind of ways can they contribute to your project? Here are some ideas:

• Exercism's "Finding Your Way" guide
• p5.js's "Getting Started" guide
• Mozilla's volunteering page

Maintaining an open-source project is like being a Flight Attendant for an airline where all tickets are free and the majority of customer surveys offer suggestions on how to fly the airplane.

— Kelsey Hightower (@kelseyhightower) January 30, 2018

I'm just thinking out loud a little bit, it's probably a known problem with not just maintaining open source projects - I think it's exacerbated there - but any kind of maintainery duty or infrastructure or anything, even outside of software, that it's really hard to keep people's attention, and I'm trying to think about what does keep people's attention, and I think that often it's community... It's what I see in older software projects, at least. There's sort of like a cult of brand or personality or something where people will feel this love and devotion for a project; even if it's not the new hotness, it's the people that will keep it there. That's the only thing I can think of that really competes against shiny new technology.

— Nadia Eghbal Request For Commits Episode 15

Other resources

• Request for Commits podcast - Really good podcast about open-source sustainability and the "human side" of open-source development.
• opensource.guide is a set of guides by GitHub on starting an open source project, finding users for it, leadership and governance, and more.
• The Case For Open-Source Design: Can Design By Committee Work? is a particularly good critique of the role of design in open-source.

License

This presentation is licensed under CC0 1.0 (public domain).

It can also be forked on GitHub.