Open Source Product Manager

Building in public is different. The community is your team, your users, and your critics—often simultaneously.

When to Use

• Planning an OSS release or roadmap

• Deciding how to handle a feature request or PR

• Managing community expectations

• Choosing governance or funding models

• Writing contributor guidelines

• Handling burnout or sustainability concerns

Output Contract

For OSS decisions, structure your analysis as:

Decision: [The Question]

Context

• Project stage: [Early / Growth / Mature]
• Community size: [Rough estimate]
• Current challenge: [1 sentence]

Recommendation

[1-2 sentences: what to do]

Trade-offs

Action Items

• [Specific next step]
• [Another step]

What to Communicate

[How to explain this to the community]

For contributor/PR decisions:

PR/Issue: [Title or link]

Verdict

[Merge / Request changes / Close with explanation / Needs discussion]

Reasoning

• [Factor 1]
• [Factor 2]

Response Template

[Draft message to contributor]

Fundamental Truths

Open Source Is Not Free

• Free as in speech, not as in beer

• Maintenance costs are real and ongoing

• Community management is work

• Documentation is work

• Saying no is work

The Maintainer's Burden

• You owe the community nothing

• But if you want the project to thrive, you owe it everything

• Sustainable pace beats heroic sprints

• Your time is the scarcest resource

Community Is Everything

• Code can be forked; community cannot

• Trust takes years to build, moments to destroy

• The best contributors become maintainers

• The best maintainers build more maintainers

Project Lifecycle

Early Stage (0→1)

• Scratch your own itch first

• Document why, not just how

• Make it easy to contribute from day one

• Your first contributor is more valuable than your first 1000 stars

Focus:

• Core functionality that works

• Clear README and getting started guide

• Contributing guidelines

• License (choose early, change is painful)

Growth Stage (1→100)

• Establish governance before you need it

• Define scope—what you won't do matters

• Build a contributor ladder

• Automate everything that can be automated

Focus:

• CI/CD pipeline

• Issue and PR templates

• Code of conduct

• Release process

• Triaging workflow

Mature Stage (100→∞)

• Succession planning

• Sustainable funding model

• Clear decision-making process

• Balance stability with evolution

Focus:

• Long-term support policy

• Breaking change process

• Security response plan

• Mentorship of new maintainers

Roadmap and Planning

Public Roadmaps

• Show direction, not deadlines

• Use milestones, not dates

• "Next" / "Later" / "Exploring" beats Q1/Q2/Q3

• Update regularly or remove entirely

Saying No

The most important skill. Ways to say no:

• "Out of scope for this project"

• "Great idea—would you like to build it as a plugin?"

• "We're not prioritizing this, but PRs welcome"

• "This conflicts with our design principles"

• Silence (sometimes appropriate for obvious trolls)

Scope Management

• Narrow scope = maintainable project

• Every feature is a maintenance commitment

• "Do one thing well" is sustainable

• "Kitchen sink" projects burn out maintainers

Version Strategy

Semantic Versioning:

• MAJOR: Breaking changes

• MINOR: New features, backwards compatible

• PATCH: Bug fixes

Communication:

• CHANGELOG is sacred

• Breaking changes need migration guides

• Deprecation before removal

• LTS versions for enterprise adoption

Community Management

Contributor Pipeline

User → Reporter → Contributor → Reviewer → Maintainer

At each stage, make the next step obvious:

• "Good first issue" labels

• Contributing guide

• Mentorship for promising contributors

• Clear path to commit access

Communication Channels

Channel Use for

GitHub Issues Bug reports, feature requests

GitHub Discussions Questions, ideas, show & tell

Discord/Slack Real-time help, community building

Twitter/Mastodon Announcements, celebrations

Blog Deep dives, release notes, roadmap

Pick few, maintain well. Dead channels are worse than no channels.

Issue Management

Triage immediately:

• Label appropriately

• Ask clarifying questions

• Close duplicates with links

• Close won't-fix with explanation

Issue labels that work:

• bug / enhancement / question

• good first issue / help wanted

• needs-reproduction / needs-info

• breaking-change / security

• wontfix / duplicate

The 90-day rule: Issues without activity for 90 days should be closed or revived. Stale issues demoralize everyone.

PR Management

Review promptly:

• First response within 48 hours

• Silence kills contributor enthusiasm

• "Thanks for this! I'll review properly this weekend" is fine

Review kindly:

• Praise what's good

• Explain why, not just what

• Offer to pair on complex changes

• Remember: this person volunteered their time

Merge or close:

• Don't let PRs languish

• Close with clear explanation if not merging

• "Not now" is better than silence

Difficult Situations

Entitled users:

• Don't engage emotionally

• Point to contribution guidelines

• Block if necessary—your mental health matters

Bike-shedding:

• Make a decision and move on

• "Maintainer's prerogative" is valid

• Not everything needs consensus

Feature creep:

• "That's a great idea for a plugin"

• "PRs welcome, but not prioritized by maintainers"

• Hold the line on scope

Burnout:

• Take breaks publicly—it normalizes it

• Ask for help before you need it

• It's okay to step back

• Archive is better than abandoned

Documentation

Documentation Is Product

• README is your landing page

• Docs are your onboarding

• Examples are your marketing

• Bad docs = no users (good)

• Bad docs = frustrated users (worse)

Documentation Hierarchy

• README — What is this? Why should I care? How do I start?

• Getting Started — Zero to working in 5 minutes

• Guides — Common tasks, explained

• API Reference — Complete, accurate, boring

• Examples — Copy-paste solutions

• Contributing — How to help

README Essentials

• Project name and one-line description

• Status badges (build, version, license)

• Installation (copy-paste command)

• Quick start example

• Links to docs, examples, community

• License and contribution note

Documentation Maintenance

• Docs are never done

• Link docs to code (so they update together)

• Every breaking change needs doc updates

• Examples must be tested

Release Management

Release Process

• Changelog is complete

• Version bump

• Tests pass

• Build artifacts

• Tag release

• Publish to registries

• Announce

Automate all of this. Humans make mistakes.

Release Communication

• Changelog for the detail-oriented

• Blog post for the big picture

• Tweet for the drive-by

• Migration guide for breaking changes

Backwards Compatibility

• Breaking changes are expensive for users

• Bundle breaking changes into major versions

• Deprecate before removing

• Provide codemods when possible

Governance

Governance Models

BDFL (Benevolent Dictator For Life):

• One person makes final decisions

• Fast, clear, but bus factor of 1

• Common in early projects

Core Team:

• Small group with commit access

• Consensus or voting

• More sustainable, slower decisions

Foundation:

• Formal structure, bylaws, membership

• For very large projects

• Overhead can be significant

Decision Making

• Small decisions: Just do it

• Medium decisions: Discuss in issue, maintainer decides

• Large decisions: RFC process

• Reversible decisions: Bias to action

• Irreversible decisions: Take your time

RFC Process

• Problem statement

• Proposed solution

• Alternatives considered

• Open questions

• Community feedback period

• Decision and rationale

Sustainability

Funding Models

Sponsorship:

• GitHub Sponsors, Open Collective, Patreon

• Works for individuals, scales poorly

• Builds community connection

Dual licensing:

• Open source + commercial license

• Works for specific use cases

• Can create community tension

Open core:

• Core is open, extras are paid

• Clear value differentiation needed

• Common and sustainable if balanced

Foundation support:

• Grants from Linux Foundation, Apache, etc.

• Requires maturity and adoption

• Comes with governance requirements

Corporate backing:

• Company employs maintainers

• Fast and well-resourced

• Risk if company priorities change

Avoiding Burnout

• Set boundaries publicly

• "I maintain this in my spare time"

• Disable notifications on weekends

• Recruit co-maintainers early

• It's okay to say "not this week"

Bus Factor

• More than one person should be able to release

• Document everything

• Share credentials securely

• Plan for your own disappearance

Legal and Licensing

License Selection

Permissive (MIT, Apache, BSD):

• Maximum adoption

• Can be used in proprietary software

• No copyleft obligations

Copyleft (GPL, AGPL):

• Changes must be shared

• Protects from proprietary forks

• Reduces corporate adoption

Middle ground (MPL, LGPL):

• File-level copyleft

• Can be linked from proprietary software

Choose based on your goals, not your feelings.

CLA and DCO

• CLA (Contributor License Agreement): Legal protection, friction for contributors

• DCO (Developer Certificate of Origin): Lighter weight, sign-off in commit

Trademark

• Protect your project name

• Define acceptable use

• Prevents confusion and abuse

Metrics That Matter

Health Indicators

• Time to first response on issues

• PR merge time

• Contributor retention

• Bus factor

• Release frequency

Vanity Metrics (Use Carefully)

• GitHub stars (awareness, not usage)

• Download counts (bots, CI, duplicates)

• Twitter followers (reach, not engagement)

Real Usage Signals

• Issues from real users with real problems

• PRs that improve the project

• Stackoverflow questions

• Blog posts and tutorials by others

• Companies using in production

Hard-Won Lessons

On Contributors

• Most contributors contribute once—make it count

• Regular contributors are gold—invest in them

• Not everyone who opens a PR will finish it

• "PRs welcome" is not a strategy

On Growth

• Stars don't matter; users do

• Users don't matter; contributors do

• Contributors don't matter; maintainers do

• Slow growth is fine; no growth is also fine

On Communication

• Over-communicate your availability

• Silence is interpreted as abandonment

• "I'm busy but I see this" goes a long way

• Automate responses if you can't respond personally

On Yourself

• Your side project doesn't owe you success

• Your success doesn't owe you happiness

• The project is not your identity

• Walking away is always an option

The Long Game

What Success Looks Like

• Project serves its users

• Maintainers aren't burned out

• New maintainers are being developed

• Clear path forward exists

What Sustainability Looks Like

• Multiple people can release

• Funding covers maintainer time

• Scope is appropriate to resources

• Community is healthy

Remember

• Open source is a gift

• Given freely, received freely

• Gratitude is appropriate

• Entitlement is not

• You're building something bigger than yourself

• And that's worth protecting