oss-product-manager

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

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

规划OSS版本或路线图
决定如何处理功能请求或PR
管理社区期望
选择治理或资助模式
编写贡献者指南
应对倦怠或可持续性相关问题

Output Contract

输出规范

For OSS decisions, structure your analysis as:

markdown

undefined

针对OSS决策，分析内容需按以下结构组织：

markdown

undefined

Decision: [The Question]

决策：[问题内容]

Context

背景

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

项目阶段：[早期 / 成长期 / 成熟期]
社区规模：[大致估算]
当前挑战：[一句话描述]

Recommendation

建议

[1-2 sentences: what to do]

[1-2句话：具体行动方案]

Trade-offs

权衡分析

Option	Pros	Cons
...	...	...

选项	优势	劣势
...	...	...

Action Items

行动项

[Specific next step]
[Another step]

[具体下一步行动]
[另一项行动]

What to Communicate

社区沟通要点

[How to explain this to the community]


For contributor/PR decisions:

```markdown

[如何向社区解释此决策]


针对贡献者/PR决策：

```markdown

PR/Issue: [Title or link]

PR/Issue：[标题或链接]

Verdict

结论

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

[合并 / 请求修改 / 关闭并说明原因 / 需要讨论]

Reasoning

理由

[Factor 1]
[Factor 2]

[因素1]
[因素2]

Response Template

回复模板

[Draft message to contributor]

undefined

[给贡献者的草稿消息]

undefined

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)

早期阶段（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)

先解决自己的痛点
记录项目的初衷，而不只是实现方法
从第一天起就让贡献变得简单
你的第一个贡献者比前1000个星标更有价值

重点关注：

可用的核心功能
清晰的README和入门指南
贡献指南
许可证（尽早选择，后期更改代价高昂）

Growth Stage (1→100)

成长期（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

在需要之前就建立治理机制
明确项目范围——你不会做的事情同样重要
建立贡献者晋升阶梯
自动化所有可自动化的流程

重点关注：

CI/CD流水线
Issue和PR模板
行为准则
发布流程
问题分流工作流

Mature Stage (100→∞)

成熟期（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

展示方向，而非截止日期
使用里程碑，而非具体日期
"下一步" / "后续" / "探索中" 比 Q1/Q2/Q3 更合适
定期更新或直接移除

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)

这是最重要的技能。拒绝的方式：

"超出本项目的范围"
"好主意——你愿意将其作为插件开发吗？"
"我们目前不优先处理此需求，但欢迎提交PR"
"这与我们的设计原则冲突"
沉默（有时适用于明显的恶意言论）

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

语义化版本控制（Semantic Versioning）：

MAJOR：破坏性变更
MINOR：新增功能，向后兼容
PATCH：Bug修复

沟通要点：

CHANGELOG是核心文档
破坏性变更需要提供迁移指南
先弃用再移除
为企业用户提供LTS版本

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

用户 → 问题反馈者 → 贡献者 → 审核者 → 维护者

在每个阶段，让下一步行动清晰明确：

"good first issue"标签
贡献指南
对有潜力的贡献者提供指导
明确的提交权限获取路径

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.

渠道	用途
GitHub Issues	Bug报告、功能请求
GitHub Discussions	问题咨询、创意分享、成果展示
Discord/Slack	实时帮助、社区建设
Twitter/Mastodon	公告、庆祝活动
博客	深度解析、版本说明、路线图

少而精，用心维护。无人问津的渠道不如没有。

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.

立即分流：

合理添加标签
询问澄清问题
关闭重复问题并附上链接
关闭无法修复的问题并说明原因

实用的问题标签：

```
bug
```
/
```
enhancement
```
/
```
question
```
```
good first issue
```
/
```
help wanted
```
```
needs-reproduction
```
/
```
needs-info
```
```
breaking-change
```
/
```
security
```
```
wontfix
```
/
```
duplicate
```

90天规则： 超过90天无活动的问题应关闭或重新激活。陈旧的问题会打击所有人的积极性。

PR Management

PR管理

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

及时审核：

48小时内给出首次回复
沉默会磨灭贡献者的热情
"感谢你的贡献！我会在周末仔细审核"这样的回复就很好

友善审核：

先肯定做得好的部分
解释原因，而非只指出问题
对于复杂变更，提供结对编程的帮助
记住：这个人是自愿付出时间的

合并或关闭：

不要让PR无人问津
如果不合并，需给出明确的关闭理由
"目前暂不处理"比沉默好

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

态度傲慢的用户：

不要情绪化回应
引导他们查看贡献指南
必要时拉黑——你的心理健康很重要

无意义的细节争论：

做出决策后继续推进
"维护者的决定权"是合理的
并非所有事情都需要达成共识

功能蔓延：

"这作为插件开发会是个好主意"
"欢迎提交PR，但维护者不会优先处理"
坚守项目范围

倦怠问题：

公开宣布休息——这会让休息变得正常化
在需要帮助之前就主动求助
退一步是可以的
归档项目比弃置不管更好

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)

README是你的项目首页
文档是用户的入门指南
示例是你的营销素材
糟糕的文档=没有用户（还好）
糟糕的文档=沮丧的用户（更糟）

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 — 这是什么？我为什么要关注？如何开始使用？
入门指南 — 5分钟内从0到运行
使用教程 — 常见任务的详细说明
API参考 — 完整、准确、严谨
示例代码 — 可直接复制粘贴的解决方案
贡献指南 — 如何参与贡献

README Essentials

README核心要素

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.

CHANGELOG已完成
版本号更新
测试通过
构建产物
打版本标签
发布到仓库
发布公告

将所有步骤自动化。人总会犯错。

Release Communication

发布沟通

Changelog for the detail-oriented
Blog post for the big picture
Tweet for the drive-by
Migration guide for breaking changes

面向注重细节的用户：CHANGELOG
面向关注全局的用户：博客文章
面向路人用户：推文
针对破坏性变更：迁移指南

Backwards Compatibility

向后兼容性

Breaking changes are expensive for users
Bundle breaking changes into major versions
Deprecate before removing
Provide codemods when possible

破坏性变更对用户来说成本很高
将破坏性变更集中到主版本中
先弃用再移除
尽可能提供代码迁移工具（codemods）

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

BDFL（终身仁慈独裁者）：

由一人做出最终决策
快速、明确，但单点故障风险高
常见于早期项目

核心团队：

拥有提交权限的小团队
采用共识或投票制
更可持续，但决策速度较慢

基金会：

正式的组织结构、章程、成员制度
适用于超大型项目
管理开销较大

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

小决策：直接执行
中等决策：在Issue中讨论，由维护者决定
大决策：采用RFC流程
可逆决策：偏向行动
不可逆决策：谨慎行事

RFC Process

RFC流程

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

赞助：

GitHub Sponsors、Open Collective、Patreon
适用于个人维护者，扩展性较差
能增强与社区的联系

双重许可证：

开源许可证 + 商业许可证
适用于特定场景
可能引发社区紧张情绪

开源核心模式：

核心功能开源，附加功能付费
需要清晰的价值差异化
若平衡得当，是常见且可持续的模式

基金会支持：

来自Linux基金会、Apache等的资助
要求项目达到一定的成熟度和采用率
附带治理要求

企业支持：

公司雇佣维护者
资源充足且高效
存在公司优先级变化的风险

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

单点故障风险（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.

宽松许可证（MIT、Apache、BSD）：

采用率最高
可用于专有软件
无Copyleft义务

Copyleft许可证（GPL、AGPL）：

修改后的代码必须开源共享
防止被专有复刻
会降低企业采用率

中间地带（MPL、LGPL）：

文件级Copyleft
可与专有软件链接

根据你的目标选择，而非个人喜好。

CLA and DCO

CLA与DCO

CLA (Contributor License Agreement): Legal protection, friction for contributors
DCO (Developer Certificate of Origin): Lighter weight, sign-off in commit

CLA（贡献者许可协议）：提供法律保护，但会增加贡献者的参与门槛
DCO（开发者原创声明）：更轻量化，通过提交时的签名确认

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

Issue首次响应时间
PR合并时间
贡献者留存率
单点故障风险
发布频率

Vanity Metrics (Use Carefully)

虚荣指标（谨慎使用）

GitHub stars (awareness, not usage)
Download counts (bots, CI, duplicates)
Twitter followers (reach, not engagement)

GitHub星标（代表知名度，而非实际使用）
下载量（包含机器人、CI、重复下载）
Twitter粉丝数（代表覆盖范围，而非参与度）

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

真实用户反馈的实际问题
改善项目的PR
Stackoverflow上的相关问题
他人撰写的博客文章和教程
企业在生产环境中使用

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

大多数贡献者只贡献一次——让这次贡献有价值
定期贡献者是黄金资源——投资培养他们
并非所有提交PR的人都会完成它
"欢迎提交PR"不是一种策略

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

开源是一份礼物
无偿给予，无偿接受
感恩是恰当的
傲慢是不可取的
你正在构建比自己更伟大的事物
这值得你去守护