Your open source repo needs a project manager

[alice-i-cecile]

Name

Your open source repo needs a project manager: lessons learned from building Bevy

Contents

Backgound

• I'm Alice
• I'm one of the maintainers of Bevy and Sprawl
• These projects are ambitious: too big to run by yourself!

What makes open source teams different?

• Distributed
  • You must be async first
• Diverse
  • Different languages
  • Different backgrounds
  • Different skill levels
  • Be patient
• Volunteer
  • Constant churn
  • Contributors may vanish randomly
  • Why do people want to help? Must be able to offer them:
    • Compelling vision
    • Critically useful tool
    • Great community
    • Opportunities for non-traditional career advancement

Core values for open source project management

• Vision
  • What are we building and why?
  • Set project values
  • Work with the team to build consensus on roadmap
  • Make decisions: no decision is worse than the worst decision
• Trust
  • Goes both ways: maintainers and contributors must trust each other
  • Transparency
  • Defer to expertise
  • Build a healthy community
• Automation
  • You cannot do this alone: that's the point!
  • Constant churn means you need to hammer out the onboarding process
  • Stronger automation builds trust
  • Docs, Tools, Delegation

Tools of the trade

• Docs!
  • README.md
  • Grand unified theory of documentation: https://documentation.divio.com/
  • CONTRIBUTING.md
• Asynchronous Community
  • Why async?
  • Help
  • Plan
  • Refine
  • Chill
• Issue management
  • Labels
  • Project boards
  • lol Roadmaps
• Automation
  • Safe languages (Rust rocks)
  • Linting
  • CI
• Delegation: the final frontier
  • People will just do stuff if you ask them
  • Community code reviews rock
  • Align on vision, build trust, then hand out rights!

[alice-i-cecile]

Barriers:

1. Non-developers don't know about open-source, don't see the value, or aren't comfortable with the tools.
2. Developer-oriented folks who are already interested in open source don't have the knowledge to do effective product management, or to understand its value.
3. Product management often requires a high degree of trust, and in most communities there's no good way to slowly work your way up there like there is for code.
4. All of the existing product management learning resources assume a very different environment (paid employees, command hierarchies, clear product direction) and their advice is often actively wrong or doesn't apply.

[alice-i-cecile]

1. Teaching users
2. Collecting feedback from users
3. Organizing work
4. Communicating vision

In my experience, these all kind of feed into each other. I'll spend some time answering questions or listening to gripes from users, collect it into an issue, triage it, and then build consensus with the dev team about what we want to focus on next

In terms of building trust, I think you need to have a path for new contributors to do all of those things in small, safe ways. And obviously, any other contributions they can make (docs, art, marketing, technical, assorted admin tasks) also help.