penguin-oss-ops

腾讯开源运营方法论（OSPO 实战）。当用户要决定项目要不要/何时开源、设计开源治理机制与开源战略路线、做开源社区运营与贡献者生态、制定发布节奏与社区健康度量，或问"开源协同怎么搞""要不要捐基金会""怎么参与上游社区"时使用。触发词：腾讯开源、开源运营、OSPO、社区运营、开源治理、项目开源决策、贡献者运营、开源协同、open source governance/operations。不用于：具体某个腾讯开源项目的技术选型咨询、开源许可证法律意见。

§0 场景闸门

本 skill 是被调度成员，不是场景入口。若当前任务会写 GitHub（提 PR / 评论 issue / commit / push / 建仓）且 .oss-task/ 下无 CHECKLIST.md：先停下，加载 routing/oss-workflow 按 §1 识别场景并实例化清单，再继续执行本 skill 对应步骤。无清单裸奔 = 违规交付（#752 实战：T1 裸奔 320s 被作者中止，61% 时间损耗）。运行时另有 penguin-guard 硬闸（PreToolUse）拦截无清单的 gh/git push 类命令。

腾讯开源运营方法论（tencent-oss-ops）

蒸馏自 17 篇腾讯开源相关文章（2017–2026），只收「运营方法论」——怎么选项目开源、治理机制、社区运营、发布节奏、贡献者生态、度量。纯事实性内容（某年开源了什么、拿了多少 Star 的新闻陈述）不单独成条，只作为方法论的证据出现。

每条原子四件套：触发条件（什么时候用这招）/ 内容（怎么做）/ 出处（源文件 + 原 URL，版权可回溯口径）/ 边界或反例（什么时候会失效）。观点冲突不调和，原样并列登记（见第 4 条）。

---

一、项目开源决策（开什么 / 何时开 / 谁来扛）

1. 对外开源评审闸门：数据 × 专家 × 稀缺性 × 通用性

• 触发条件：有人提出"把这个项目开源出去吧"，需要判断值不值得开；OSPO 审开源申请；用户问"我们这个项目适不适合开源"。
• 内容：四维评审缺一不可：①先内部开源试水，用客观数据验证（内部没人用的项目别指望外部有人用）；②专家评定把关质量；③业界稀缺性——同类产品不多，开源才更有价值；④通用性——不是所有开源项目都需要很高的技术含量，很少企业能达到腾讯那种量级，通用性是重点考虑因素。
• 出处：2019-12-tencent-cloud-oss-collab-one-year.md（https://cloud.tencent.cn/developer/news/502122，雷锋文，腾讯方面口径）
• 边界或反例：竞品已红海的领域开源仍有防御与招聘价值，稀缺性只是价值最大化判准而非唯一判准；涉密业务逻辑、安全敏感组件直接否决，不进评审流程；只有内部数据没有外部视角时，评审会退化成内部自嗨。

2. 社区优于代码：团队没有社区运营的能力与意志就不该开源

• 触发条件：开源前评估团队是否 ready；用户问"人手不够能不能先开源再招人运营"。
• 内容：每个开源项目背后都需要团队支撑。如果团队只是为了开源而开源、本身没有推动开源或社区运营的能力和意志，不鼓励开源——因为对外开源就意味着对用户负责。代码不好可以优化，但没有"好的人"，代码再好也可能石沉大海；健康的社区总能纠正代码的问题，不健康的社区难以可持续地维护代码库。
• 出处：2019-12-tencent-cloud-oss-collab-one-year.md（堵俊平，URL 同上）+ 2021-08-infoq-tencent-apache-way.md（https://www.infoq.cn/article/qOKQu6YQFWhqTjp5Vzb2，单致豪转述 Apache "社区高于代码"）
• 边界或反例：纯社区自生长型项目（见第 11 条 ncnn）靠个人热情起家，初期并没有专职团队也成功了——此闸门针对企业署名开源（对外负责）场景；把它当官僚门槛用，会把工程师的自发开源热情耗死在审批里。

3. 先内后外的时机闸门

• 触发条件：项目已决定开源，纠结"什么时候开源出去"；用户问"现在开源时机成熟了吗"。
• 内容：内部开源先行验证，跑出生产级证据再对外：MMKV 在腾讯内部开源半年、iOS 微信生产环境近 3 年验证性能与稳定性后才对外；TDesign 历经 2 年内部开源、完成从 0 到 1 的建设并沉淀出能力后对外，目的是借社区力量实现从 1 到 N。内部验证期同时积累多团队使用方和维护经验。
• 出处：2018-09-tencent-cloud-mmkv-opensource.md（https://cloud.tencent.com/developer/article/1354198，微信终端开发团队）+ 2021-12-tencent-cloud-tdesign-oss-launch.md（https://cloud.tencent.com/developer/news/886236，InfoQ 郑思宇）
• 边界或反例：ncnn 2017 年直接对外开源同样成功——纯社区模式不走内部闸门；技术热点窗口期短时（AI 框架热周期），内部验证期过长会错过窗口；没有内部使用场景的项目，此闸门无从谈起。

二、组织与治理机制

4. 自上而下撬动 × 自下而上发现（⚠ 内置观点冲突）

• 触发条件：大组织推开源时"小项目踊跃、重磅底层项目推不动"；设计开源推动机制。
• 内容：自下而上只能撬动前端、工具类小项目，体量大、与业务捆绑紧的底层项目必须自上而下强力推动（技术委员会、总办牵头），且上层用协调沟通解决问题、不强捆。但决策之后主动权交回一线工程师，用内部社区收集真问题（码客、乐问、邮件），甚至办"吐槽大会"让正反方公开辩论并现场收集问题（源文口径：现场提出的问题其后基本全部解决）——腾讯原话："只有从下至上，才能发现真正的问题，只有从上至下，才能快准狠地解决问题。"
• 出处：2019-09-tencent-cloud-tencent-oss-revolution.md（https://cloud.tencent.cn/developer/news/451257，钛媒体，许勇/王巨宏）+ 2019-12-tencent-cloud-oss-collab-one-year.md（郑亚峰：最大困难是统一人心，URL 同上）
• 观点冲突（不调和，并列登记）：单致豪在 2020-07-tencent-cloud-tencent-oss-alliance-interview.md（https://developer.cloud.tencent.com.cn/news/654757）说"真正的开源不是一种自上而下的决策方式，而是由社区里面的人共同做出的决定"——与企业内部用行政力量撬动开源的机制存在张力。源 A（许勇/王巨宏）说企业开源需要自上而下撬动，源 B（单致豪）说真开源的决策权必须在社区。
• 边界或反例：只剩自上而下时会退化成 KPI 表演（党受辉明确"没把开源协同当 KPI，而是让其自生长"）；只剩自下而上时重磅项目永远开不出去（许勇）。

5. 三步走开源战略：内部协同 → 外部开放 → 社区治理

• 触发条件：组织从零制定企业级开源战略、规划 3–5 年开源路线；用户问"公司该怎么系统性做开源"。
• 内容：第一步内部开源协同：打破技术孤岛和重复造轮子，跨团队共建；第二步外部代码开放：优化设计与代码结构、拓展落地场景、利用外部贡献者资源；第三步社区开放治理：大规模技术推广、开发者生态、社区领袖培养。三步顺序有先后但同步迭代推进，不是瀑布——资源优先投第一步。
• 出处：2019-09-tencent-cloud-tencent-oss-revolution.md（堵俊平首次公开的开源战略路线图，URL 同上）
• 边界或反例：纯社区/个人项目没有"内部协同"前提，直接从第二步起步；把三步当严格串行门槛执行会拖死节奏（原文明说同步推进、像开发迭代）；小组织资源只够做一个项目时，套公司级战略框架是过度设计。

6. Oteam 跨团队共建组织法：下层共建，上层交流

• 触发条件：多个团队在重复造同一个轮子、要拉通技术路线；设计内部开源协同的协作结构。
• 内容：组建跨团队虚拟组织（Oteam），把同类项目的不同团队聚合开源共建；能合当然好，不能合也互通有无、接受使用者的自然选择。分层处理：下层基础设施（如 CI 流水线）容易统一，多团队共建、各 BG 只留少量人力；上层贴近业务的度量改进与业务模式耦合、不易统一，只做交流学习不强行合并。"平台开源一步到位，协同按应用情况局部或全员协同。"
• 出处：2019-09-tencent-cloud-tencent-oss-revolution.md（党受辉/卢山，腾讯 CI Oteam 案例：217 名开发者提交插件、287 个组件，URL 同上）
• 边界或反例：强行统一上层会失败（原文明确上层"不容易统一"）；没有强团队牵头时虚拟组织容易空转（腾讯 CI 由蓝鲸团队牵头）；把协同当 KPI 考核会变形。

7. 内外一套治理规范：不要为内部开源另起炉灶

• 触发条件：建立内部开源流程制度时；用户问"内部开源要不要单独搞一套规范"。
• 内容：内部开源建设初期容易以为"不需要外部开源那套规范、直接做更高效"，实践证明不跟外部开源采取同一套标准会出大问题——应把外部开源跑通的规范（安全检查流程、代码规范要求、治理管理办法、工具链）整套引入内部；对外开源走过的每条弯路都以经验形式回馈内部开源，内部出问题时可马上应用。
• 出处：2019-09-tencent-cloud-tencent-oss-revolution.md（王巨宏，URL 同上）+ 2019-12-tencent-cloud-oss-collab-one-year.md（王巨宏，URL 同上）
• 边界或反例：内外合规要求不同的领域（出口管制、涉密代码）不能一套通吃；没有任何外部开源积累的团队此法无从借用，可退而采用社区现成规范（于朵团队从翻译 GitHub 开源指南、Apache 入会指南数十篇起步，见 2020-07-tencent-cloud-tencent-oss-alliance-interview.md）。

8. 内外双循环：内循环孵化输送，外循环引流反哺

• 触发条件：设计开源与业务的长期关系；用户问"开源怎么和业务形成正循环""开源的投入产出怎么算"。
• 内容：内循环：内部代码开源、开源协同，减少重复投入、降本增效，孵化出的新秀项目和毕业的优秀项目输送至外部开源社区；外循环：以产品、社区、商业的形式创造社会与商业价值，同时引入外部优秀开源项目，用外部新鲜血液促进内部技术持续创新。开源项目输出能力的同时不断吸收社区的营养。
• 出处：2020-12-tencent-cloud-tencent-oss-decade-report.md（https://cloud.tencent.com.cn/developer/news/748030，单致豪"腾讯开源十年图谱"发布口径）
• 边界或反例：没有对外输送管道（评审、法务、安全支持）时内循环产物会积压烂在内部；外部引入不投入内部适配等于白引——腾讯引入 Ozone 后做了大量性能与稳定性优化才做到千台节点规模长期稳定运行（2021-08-infoq-tencent-apache-way.md）；只算短期商业回报会把双循环算成双亏。

9. 基金会晋级路径：从项目治理升级到基金会治理

• 触发条件：项目要摆脱单公司色彩、追求中立性和 IP 托管、走向全球化治理时；用户问"要不要把项目捐给基金会"。
• 内容：晋级阶梯：深度参与基金会项目积累信任 → 捐赠项目并转移商标、知识产权甚至专利给非营利机构 → 推动成立专项基金会（TARS 基金会）或进入孵化器 → 从开源项目的治理模式升级为开源基金会的治理模式。基金会提供知识产权管理框架、代码仓库、项目治理、财务和公关管理。捐赠前先回收散落在外面的相关项目、重新规划宣传。
• 出处：2020-07-tencent-cloud-tencent-oss-alliance-interview.md（单致豪/于朵：第一次商标与 IP 转移到非牟利机构、第一个自发起的国际基金会，URL 同上）+ 2019-12-tencent-cloud-oss-collab-one-year.md（王巨宏谈 TARS：牵头推进、专利捐赠给基金会"前所未有"、回收散落项目，URL 同上）
• 边界或反例：捐赠即放弃单方控制权，此后社区决策不再由公司说了算（与第 4 条单致豪的观点同源）；项目活跃度和贡献者多元度不足时进基金会只会变成僵尸孵化项目；与公司商业强绑定的项目不适合立即捐赠。

三、社区运营与协作机制

10. Apache 之道五条内化：社区治理的操作准则

• 触发条件：制定社区协作与决策机制、设计社区行为准则；用户问"开源社区怎么治理""社区决策怎么做"。
• 内容：腾讯从 Apache 之道内化的五条：①人人可参与，凭公开贡献获得影响力与权威（功绩制）；②扁平结构，角色平等、投票权重相同；③开放交流——分布式社区靠邮件列表等异步机制，代码与决策过程公开透明；④共识优先的决策机制，无法完全共识时用投票等协调方式产生有约束力的决定；⑤社区高于代码——健康社区总能纠正代码问题。
• 出处：2021-08-infoq-tencent-apache-way.md（单致豪 2021 ApacheCon Asia 演讲，URL 同上）
• 边界或反例：这五条是社区治理准则，不等于公司内部管理方式（内部推动仍靠第 4 条的行政撬动，两套并行）；冷启动期项目强行全套流程（正式投票、邮件列表）会拖慢迭代，先跑通再补治理；贡献者个位数时谈扁平与共识是空转。

11. 社区运营双模式：纯社区自组织 vs 专职团队运营

• 触发条件：为开源项目配置运营资源时；用户问"开源项目要不要配专职维护/运营人员"。
• 内容：腾讯内部并存两种成功模式，按战略地位与资源选型。模式一（ncnn）：不由内部团队主导运营，作者个人维护（GitHub 上近 80% 维护工作由 nihui 一人完成）+ 高活跃用户群（5000 人 QQ 群，每天讨论技术与生活），社区纯粹、成本极低，但巴士因子极低。模式二（TNN）：在开源协同大背景下推出，内部有专业全职工程师做开源和社区维护，负责人高频出席开发者大会"站台"推广，资源充足但公司主导性强。
• 出处：2020-12-tencent-cloud-youtu-oss-three-years.md（https://developer.cloud.tencent.com/news/744647，InfoQ 王利莹）
• 边界或反例：模式一严重依赖关键个人，作者倦怠或离职即项目风险；模式二成本高，非战略项目养不起专职团队；最差解是名义上配了专职、实际无人投入。

12. 异步 issue 协作替代即时拉群

• 触发条件：跨团队/跨公司协作信息传递成本高、讨论浅；设计开源社区日常协作机制。
• 内容：企业惯性是即时拉群沟通，开源的做法是异步 issue 讨论：问题可以被深刻讨论和思考，更容易得出符合预期的结论，开发时效率更高。配套原则：无论个人还是团队使用者，坚持公平、公正、透明——日常讨论的问题、方案、计划全部在 GitHub 公开展示；引入 CI/CD 降低人工参与比率。
• 出处：2021-12-tencent-cloud-tdesign-oss-launch.md（TDesign 团队，URL 同上）
• 边界或反例：时效敏感场景（安全漏洞应急）不适合等异步共识；书面表达能力不足的团队，异步讨论质量可能比拉群更差——TDesign 自己就是先因"大量时间精力消耗在传递信息上"陷入僵局，第二期才改用异步 issue 的；公开透明与保密需求冲突时需划定边界。

13. 开源 ≠ 一次性动作：代码开放 → 社区建设 → 生态回报

• 触发条件：项目刚开源或准备开源、规划开源后的运营路径；用户问"代码 push 上去了，然后呢"。
• 内容：代码开放只是第一步；第二步是建立好的社区；第三步才是通过社区进行技术挖掘、给生态上的企业带来回报。这是很长期的过程，不是一次代码开放就解决的。配套预期管理：给文化建设设 3–5 年目标，协同是持续性问题。
• 出处：2019-11-tencent-cloud-xuyong-oss-deep-water.md（https://developer.cloud.tencent.com.cn/article/1538274，堵俊平）+ 2019-12-tencent-cloud-oss-collab-one-year.md（郑亚峰 3–5 年目标，URL 同上）
• 边界或反例：把三阶段当严格里程碑会误判——社区建设从开源第一天就开始（TDesign 开源即带透明协作机制）；商业回报不明显的基础设施项目，第三阶段周期可能超过产品生命周期，回报要从第 8 条双循环的别处收。

四、贡献者生态与人才培养

14. 贡献者成长漏斗：试用 → Bug Issue → Feature MR → Code Review → 方案制定

• 触发条件：想扩大外部（或内部）贡献者规模、设计激励与晋升机制；用户问"怎么让人给我的项目贡献代码"。
• 内容：给贡献者铺阶梯：个人项目试用 → 提交第一个 Bug Issue → 提交第一个 Feature MR → 参与 Code Review → 参与方案制定，逐级放权。配套：公开透明的协作（第 12 条）+ 招募与激励机制 + 指名道姓的成长路径（Contributor → Committer → PMC）。内部同理可复制：腾讯 CI 的 Oteam 中 217 名开发者提交过插件。
• 出处：2021-12-tencent-cloud-tdesign-oss-launch.md（TDesign 核心贡献者约 100 人的成长路径观察，URL 同上）+ 2021-12-tencent-cloud-weopen-anniversary.md（https://cloud.tencent.cn/developer/article/1924619，WeOpen Star：指导开发者从 Contributor 到 PMC）+ 2019-09-tencent-cloud-tencent-oss-revolution.md（Oteam 数据）
• 边界或反例：上手体验（安装、文档、首个 demo）没做好时，漏斗第一层就断了；企业开源的漏斗大头常在内部（TDesign 280+ 贡献者中外部仅 17 人），只盯外部会误判；没有 review 人力承接时放权就是放任。

15. 分难度任务设计的人才漏斗：学员实践反哺项目质量

• 触发条件：设计开源新手任务、开源编程活动、校企合作培养计划；用户问"怎么带新人进开源项目"。
• 内容：任务按难度分层，简单任务配非常详尽的参考代码和资料，让更多人通过学习就能达成目标；困难任务（行业空白型）让学员定期与导师交流同步结果，导师据此改进工具——学员实践同时成为项目的测试与质量来源（LLM-ncnn：学生模型转换失败率高 → 导师持续改进转换工具 → 反过来发现 ncnn 自身问题）。配套体系化动作：开源课堂 + 开源实践 + 贯通式培养（从中学到研究生）。
• 出处：2023-09-tencent-cloud-ncnn-nihui-interview.md（https://developer.cloud.tencent.com/news/1201907，nihui 谈犀牛鸟开源人才培养计划指导）+ 2023-04-tencent-cloud-wangjuhong-interview.md（https://developer.cloud.tencent.com/news/1043246，王巨宏谈贯通式培养体系）
• 边界或反例：任务无梯度、无参考资料会变成劝退器；学员产出需要导师审查投入，人力不足时漏斗反成负担；学员以刷经历为目标时产出质量不可靠，须有 review 门。

16. 切入外部社区的晋级路径：使用者 → 贡献者 → 主导者

• 触发条件：企业/团队想参与已有的外部开源生态（而非自建项目）；用户问"我们怎么参与/贡献上游社区""怎么在上游社区获得话语权"。
• 内容：先用起来并用到深处：大规模生产采用（腾讯对 Ozone 部署了 1000+ 节点集群）；使用中产生的需求与问题带回上游——把客户需求落实到社区里（OpenStack 路径：使用者 → 超级用户奖 → 白金会员 → 基金会董事）；持续贡献特性与 patch 直至获得版本主导权（腾讯成为第一家在社区发布 Hadoop 和 Spark Release 的中国公司）。冷启动能力建设可以从翻译文档起步（于朵团队翻译 GitHub 开源指南、Apache 入会指南等数十篇，为后续开发者提供规范性指导）。
• 出处：2020-07-tencent-cloud-tencent-oss-alliance-interview.md（贺阮/堵俊平/于朵，URL 同上）+ 2021-08-infoq-tencent-apache-way.md（Ozone/Pulsar/APISIX 深度应用与反哺贡献，URL 同上）
• 边界或反例：没有真实生产使用时，贡献缺乏场景驱动、容易沦为刷 commit；上游社区被单一厂商把持、治理封闭时晋级有明显天花板，应考虑换社区或走第 9 条自建路径。

五、工程协同、发布节奏与度量

17. 技术选型要算贡献者门槛账

• 触发条件：为开源项目做多技术栈实现方案选型；用户问"用 Web Components 统一套壳好不好""一份代码转译出多栈好不好"。
• 内容：跨技术栈方案评估时，除兼容性与稳定性外，把「对开源社区活跃度的影响」纳为硬判据。TDesign 评估三条路：Web Components（浏览器兼容性风险，政企场景 polyfill 不可小觑）、React 代码转 Vue（真正一份代码，但中间层"既不是 Vue 也不是 React，对贡献者来说门槛比较高，会进一步导致开源社区不够活跃"）、各栈原生实现（成本高但社区友好）——最终选原生实现，并用「API/交互稿统一评审前置 + API 管理平台自动生成各栈文档与定义文件」压回维护成本。
• 出处：2022-07-tencent-cloud-tdesign-best-practice.md（https://cloud.tencent.com/developer/news/916735，InfoQ 郑思宇）
• 边界或反例：项目根本不打算接受外部贡献时，贡献者门槛判据失效，维护成本优先；原生多栈实现的人力成本是转译的数倍，单人/小团队项目可能应该收缩到单一技术栈做深。

18. 发布节奏与社区健康度量口径

• 触发条件：评估开源项目运营效果、向上汇报、跨项目对比健康度；用户问"开源项目该看哪些指标"。
• 内容：四类口径组合使用：①节奏——固定发布节奏（TDesign 保持每周迭代一个新版本）；②规模——Star/Fork（ncnn 10.4k Star / 2.6k Fork）；③结构（含金量最高）——贡献者总数 / 核心数 / 外部数（TDesign：280+ 贡献者、核心 47、外部 17），以及演进方向（TARS：从 100% 贡献者来自腾讯 → 80% 核心开发者来自外部）；④交互——Issue 关闭量（TDesign 一年关闭 1k+）、CR 次数（5k+）、社区群规模与活跃度（ncnn 5000 人群每日活跃）。
• 出处：2021-12-tencent-cloud-tdesign-oss-launch.md + 2022-07-tencent-cloud-tdesign-best-practice.md（TDesign 数据）+ 2020-07-tencent-cloud-tencent-oss-alliance-interview.md（单致豪谈 TARS 贡献者结构）+ 2020-12-tencent-cloud-youtu-oss-three-years.md（ncnn 数据），URL 均同前
• 边界或反例：Star 是可刷的虚荣指标，不预示活跃；外部贡献者占比高也未必健康（可能是维护失守的信号）；任何单一指标都会被 Goodhart 化，必须组合看、看趋势；结构指标要结合运营模式解读——ncnn 一人维护近 80% 在结构上是红灯，但纯社区模式下项目依然成功（见第 11 条）。

---

附：蒸馏审计摘要

• 候选池 25 个方法论单元；通过三重验证（V1 来源充分 / V2 可执行 / V3 任务增益）18 条；3 条合并进相邻原子（内部触达渠道与吐槽大会→第 4 条；王春雨"吸收社区营养"→第 8 条；于朵翻译文档起步→第 16 条）；4 条丢弃。
• 丢弃明细：①2019-11-github-blog-tencent-token-scanning.md——600 字符纯事实（加入 token 扫描计划），无方法论；②2026-09-woshipm-weknora-analysis.md——产品功能介绍文（RAG/沙箱/Skill 机制），运营方法论缺失；③2021-02-tencent-cloud-ncnn-design-philosophy.md——工程设计方法论（可用性/移植性/Human editable param），属工程非运营，V3 对运营任务无直接增益；④2017-07 新智元专访中"ncnn 与 TensorFlow 侧重不同故无竞争"——单源单句事实陈述，V1 不足以重建可执行的定位方法，其思想已被第 1 条稀缺性维度覆盖。
• 观点冲突登记：第 4 条（许勇/王巨宏 vs 单致豪，自上而下 vs 社区决策），未调和。
• 每条原子均含失效条件（边界或反例段），对应 RIA-TV++ 阶段 4 压力测试要求。

退位条款（2026-09-29 #752 实战教训）

本 skill 管开源运营决策（要不要开源/怎么治理/社区节奏），不管具体 issue/PR 操作。检测到任务包含「处理 issue / 提 PR / 修 bug / 回复评论 / 关闭 issue」时：停下，不执行，改走 oss-workflow（套件唯一场景入口，会生成 checklist 走完整门禁）。直接用本 skill 处理具体协作操作 = 零门禁裸奔。