前言
工作 3-5 年后想转架构师、转技术 leader、转面试官，"影响力"都是绕不开的关键词。做开源是做影响力最快的方式——但 90% 的人都卡在第一步："我不知道怎么开始。"
这一篇不讲"开源有什么好处"，直接讲怎么走，从选库到 PR 合进去。
一、先看清现实：开源 ≠ 写框架
新人常以为开源就是"自己造一个框架"。其实大多数贡献者是从这些事开始的：
修 typo、补充文档；
复现并修一个 Issue；
添加测试用例；
把内部工具迁移到上游；
在 Stack Overflow / 掘金答题。
很多资深 Contributor 的"代表作"是"修了 N 个 bug"——而不是"从零写了一个库"。
二、找合适的库
不要直接冲 Compose Coil、OkHttp 这种超级项目。你会卡在：
Issue 列表 2000+ 个，maintainer 根本没时间 review；
没有 Good First Issue 标记，新人不知道从哪下手；
沟通风格、PR 要求对新人很高冷。
更合适的起步：
Jetpack 周边小工具——大部分由 Google 工程师自己维护；
大厂出品的工具库——如 Square 的 Moshi、OkIO、Retrofit；
特定方向的"小而美"——Kotlin 协程周边、Compose Modifier、Lint 规则；
国产开源——如 JessYan/AndResGuard、megatronking/StringFog。
我的第一条 PR 合到 Kotlin 的 kotlinx-coroutines，做的修改是改了一个错别字和补充一个冷门场景的测试——大概用了 30 分钟合进去。
三、第一份 PR 怎么写
PR 写不好直接被 close。即使你代码很对，maintainer 也会觉得"沟通成本高"。
模板
## What does this PR do?
[One sentence summary]
## Why is this change needed?
[Specific bug / missing feature / unclear docs]
## How is this implemented?
[Just enough context, link to related issues]
## Test plan
- [ ] Unit tests added
- [ ] Manual test steps (if UI change)
- [ ] Documentation updated
## Related issues
Closes #1234
关键细节
一个 PR 只做一件事。不要"顺手把别处也改了"——很容易和"修改了某行"冲突；
自己先跑 CI——CI 红了自己改，不要把红 CI 推给别人；
如果有 breaking change，单独标注；
不要为了 PR 而 PR——虚假贡献会被识破。
四、和 Maintainer 沟通
很多新人一上来就喷 maintainer："这个 API 太烂了，必须改！"——这种人会被无情 close。
沟通纪律：
先确认事实。复现是否一样？版本是否一致？
先在 Issue / Discussion 里发起讨论，不要直接 PR。
不要挑战设计决策。如果 maintainer 说"为了向后兼容我们故意这样"，不要争——除非你能给出 5 个 Big User 同意迁移的理由。
永远附数据。"我们这边有 5000 用户因此失败" 比 "我觉得有问题" 强 100 倍。
Issue 模板：
**环境**
- 库版本: 2.4.1
- 平台: Android 14 / Pixel 6
- 复现频率: 总是
**预期**
期望行为...
**实际**
实际行为...
**最小复现代码**
```kotlin
// 几行能复现的代码
日志
stacktrace
## 五、维护一个小库：从 0 到 1000 Star
如果你想"自己造一个库"，下面是已经被验证过的路径。
### 第一阶段：解决你自己的痛点
不要做"做个通用的某某库"——做"我下周就要用的东西"。需求从自己工作里抽出来。
### 第二阶段：起名 + 仓库 + 文档
- 仓库名要短、要可拼读：`ImageOK`、`FedCache`、`RRouter`；
- README 三段式：
- **What**：一行话告诉读者这是干嘛的；
- **Why**：你的库和同类区别；
- **How**：3-5 行代码 demo。
### 第三阶段：发布到 Maven Central
```kotlin
// gradle/libs.publish.gradle.kts
publishing {
publications {
create<MavenPublication>("release") {
groupId = "com.yourname.libname"
artifactId = "libname"
version = "0.1.0"
from(components["release"])
}
}
repositories {
maven {
url = uri("https://s01.oss.sonatype.org/content/repositories/releases/")
credentials {
// 从 Sonatype Token 拿用户名+密码
}
}
}
}
第一次发版本至少要 1 周——OSSRH 账号审核 + GPG 签名 + groupId 验证。提前做这一步，不要等版本号都写好了再折腾。
第四阶段：传播
写一篇"为什么我做这个"的中文博客，发布到掘金/知乎；
准备一份英文介绍，发到 r/androiddev、Hacker News、Twitter/X；
主动联系大 V（先小 V），让他们试用并给建议；
在现有项目 README 末尾加"Used by"列表，列出早期 adopters。
六、常见踩坑
承诺过高的 roadmap — "我要做最牛的网络库"，没人信。改为："这周我要修 3 个 issue"。
回复不及时 — 别人提的 Issue 一周没人回，下次就不来了。可以借 GitHub Actions 自动 reply bot。
代码风格不统一 — 用 ktlint + detekt CI 卡住。
拒绝一切"和我设计不同"的 PR — 这会让库 dead。
七、把开源变成"工作产出"
公司里做开源最大阻力是"老板觉得没用"。把开源变成可衡量的产出：
Bug 反馈与修复 → "季度修复 5 个上游 issue";
方案对外输出 → "季度发 1 篇技术博客 + 1 个开源工具";
招聘 → "季度从社区引荐 3 个候选人"。
把这件事写进 OKR，让老板能看见它对招聘、品牌、业务的价值。
八、一个时间表（针对普通工程师）
小结
做开源不是一蹴而就——它是一份 30 分钟的 PR + 一份 3 个月的方向 + 一年的坚持。下一篇文章我们聊聊如何把技术影响力"带到 App 外"——技术写作与个人品牌建设，这是与开源相辅相成的能力。
参考阅读
《Working in Public》— Nadia Eghbal
Open Source Guides (opensource.guide)
Kotlin 开发者社区 How to Contribute