1. 十年之约：COSCon‘25 为什么值得被记录
1.1 这届年会的第一感受：从“小众聚会”到“基础设施级”话题
COSCon 走到第十届，很多老人儿都有一种“孩子长大了”的感觉。我走进北京会场时，第一眼看到的是比往年更大的场地、更多的展台、更长的走廊人流。十年前，第一届中国开源年会可以说是“圈内人的小圈子聚会”，聊的大多是 Linux、Apache 项目、代码托管平台这类纯技术话题；而今年，COSCon‘25 的议题覆盖了大模型推理、AI Agent、操作系统供应链、国际合规、开源教育、开源商业化等等，这些话题早就超出了“写代码”的范畴，上升到了产业协作、基础设施安全、人才培养和全球合作的层面。
这场年会的主办方开源社，每年都会强调“社区、开源、创新”这三个关键词，但你真正在现场，才会理解这三个词的分量。会议期间我碰见好几位从外地专程飞来的朋友，大家见面打招呼的方式已经不是“最近在忙什么”，而是“你在哪个分论坛蹲着”“早上那份报告你看了吗”。这种交流密度，是线上开会完全给不了的。
跟前几届相比，今年的 COSCon 还有两个肉眼可见的变化。第一，国际面孔明显变多了，不止是有境外的演讲者通过线上接入，还有不少国际开源基金会的成员和海外项目的维护者专程到场。第二，企业和高校的参与深度提高了。以前很多企业来年会主要为了招聘和品牌露出，今年更多是带着自己开源的底层项目来展示技术路线、寻找合作伙伴。高校侧则集中体现在开源教育分论坛的热度上，好几位教授带着课题组的学生过来宣讲招生和开源课题。
1.2 第十届的特殊意义：站在“中国开源三十年”这个节点上看问题
为什么说第十届有特殊分量？因为今年恰好也是中国开源走过的第三十个年头。从最初少数爱好者翻译文档、搭建镜像站，到如今成千上万中国开发者向全球顶级项目提交贡献，这条路走得很不容易。我觉得这种时间上的重合，并不是巧合——中国的开源生态恰好发展到了一个需要集中回顾、认真复盘的时间点。
过去十年，COSCon 一直承担着“记录者”的角色。每一届年会都会发布当年的报告、盘点当年的社区热点。而第十届年会的回顾环节尤其多：开场有十年照片回顾，会刊里有一整版历届会议的数据统计，还专门安排了一场“十年圆桌”，邀请了从第一届就开始参与的志愿者、讲师和企业代表。这场圆桌没有太多宏大叙事，大家讲的多半是具体的人和事——谁当年在会场帮人改简历，谁因为一次 Lightning Talk 找到了创业合伙人，谁从一个台下听众变成了台上的分享者。
这些故事拼在一起，才让我意识到，开源年会不仅仅是“开会”，它其实是一个社区共同记忆的容器。回看这十年，COSCon 最大的贡献可能不是哪场演讲，而是它始终提供了一个物理空间，让原本只会在线上以 ID 相见的人，能在线下碰面、喝酒、吵架、成为朋友。
1.3 这篇文章写给谁看
文章写这么长，难免有人问：我没去现场，读了有用吗？我会说，这篇文章的目标读者是四类人。
第一类是开源项目的维护者和贡献者，你们可以通过这篇文字获得今年社区讨论的焦点、维护者面临的真实难题，以及一些可以用来改进自己项目治理的参考。第二类是企业技术决策者，如果你们公司正在考虑是否要拥抱开源、如何处理许可证和供应链安全，那文章里关于开源商业化、合规治理、企业开源办公室的部分，都是今年现场讨论出来的干货。第三类是高校师生和开源新手，你们可能想找一个切口进入这个圈子，但又不知道从何下手，我在后面专门写了如何低成本参与开源社区的“第一周行动计划”。第四类是纯粹对开源感兴趣的朋友，你们可以把它当作一份“参会解说稿”，通过文字看看这个圈子里的人们，在 2025 年的秋天，到底在关心什么。
2. 主论坛高光：报告发布、思想碰撞与十年致敬
2.1 《2025 中国开源年度报告》里的几个关键信号
主论坛上午，开源社正式发布了《2025 中国开源年度报告》。这份报告做了好几年了，在圈内已经比较有公信力。我翻了翻实体版，挑几个我印象最深的数据点说说。
第一组数据是关于贡献深度的。报告显示，中国开发者向全球开源项目提交的 PR 数量同比增长约 32%，而且其中“仅修改文档/翻译”的浅层贡献比例在下降，涉及代码逻辑、新功能、缺陷修复的深层贡献占比在提升。这说明了什么？说明中国开发者在开源社区里的角色正在从“使用者”变成“共建者”。早些年很多人提交一个 PR 只是为了过一把“贡献者”的瘾，现在的 PR 更多是真实工作场景里遇到问题、解决问题后的自然产出。
第二组数据是关于项目存活率的。国内企业发起或主导的开源项目总数已经超过 3000 个，但能保持连续 12 个月活跃的项目不到四成。这个数据可以说是“冷思考”——发项目容易，养项目难。很多企业开源项目的生命周期非常短，发布会开完、媒体报道完，项目就进入“僵尸态”。报告里还专门分析了原因，排在首位的是“企业没有为核心维护者配置专职岗位和预算”，其次是“项目缺少清晰的治理规则”，导致外部贡献者即使想参与也不知道该从哪儿下手。
第三组数据来自开发者动机调研。排在前三位的参与动机分别是：技术成长（74%）、解决实际问题（61%）、社区归属感（57%）。只看这个结果，你会发现现在的开发者参与开源，心态普遍比较务实——首先是能学到东西，其次是能解决问题，最后才是“混个圈子”。而“给简历加分”只排在第五位，说明那种“功利性参与”的泡沫正在慢慢消退。
还有一组数据我必须提：AI 相关开源项目的贡献者增速达到了所有细分领域中最高的 87%。但与此同时，AI 赛道也是“僵尸项目”比例最高的。很多项目发布一个模型权重或者一个推理框架之后，就再也没有更新。这也印证了AI开源当前的一种“浮躁感”——大家都在抢发新东西，却很少有人愿意沉下心做长期维护。
2.2 开源社区成熟度模型 2.0：一把让维护者“照镜子”的尺子
除了年度报告，开源社在主论坛还发布了开源社区成熟度模型 2.0。这个模型我在前几年就有关注，1.0 版本主要解决的是“社区健康度怎么看”的问题，2.0 则在可操作性上做了一个明显升级。
简单介绍一下这个模型的结构。它把开源社区划分为五个阶段：萌芽期、启动期、成长期、成熟期、衰退期。每个阶段都有四个维度的评估指标：代码与基础设施、社区与治理、用户与生态、商业化与可持续性。每个维度下还有若干可量化的子项，比如“核心贡献者数量”“Issue 响应中位数”“外部贡献者占比”“代码审查周期”等等。社区维护者可以拿着这套模型，给自己的项目做一次“体检”，找到最薄弱的那一两个维度优先改进。
为什么我觉得这个工具很实用？因为大多数开源项目的问题不是“怎么把代码写好”，而是“不知道自己的社区到底处在什么阶段、下一步该做什么”。成熟度模型最大的价值，是把这些模糊的感觉，换算成相对客观的指标和行动建议。比如一个项目处在“成长期”，模型的建议可能是：建立稳定的治理委员会、明确贡献者晋升通道、完善行为准则、开始探索付费支持或云托管服务。如果没有这种量化工具，维护者往往只会凭感觉做决策，容易导致“该建治理规则的时候还在闷头写代码”或者“项目根本不成熟就急着做商业化”这种错位。
2.0 版本还新增了一个部分，专门讨论“衰退期”的应对策略。以前大家不太愿意聊项目衰落的话题，但这两年社区里慢慢形成了一个共识：能体面地“关停”一个项目，也是一种治理能力。模型里建议维护者在项目明显无法维持时，应该提前考虑三个问题：代码如何归档和移交；用户如何迁移到替代方案；贡献者的劳动成果如何被承认。我觉得这个部分，恰恰体现了中国开源社区变得越来越成熟——敢于正视衰退和终结，而不是靠“假装一切都很好”来回避问题。
2.3 主论坛的“十年致敬”环节为什么能打动人
说实话，每年主论坛的嘉宾演讲我都听，但今年让我印象最深的反而是议程表上没有单独列出的“十年致敬”环节。开场时，主办方在屏幕上放出了一张 2015 年第一届年会的纸质签到表，上面的字迹已经有些模糊了。主持人没有煽情，只是请当年三位志愿者上台，一人聊了几分钟。
第一位志愿者说自己当年负责“搬水”，因为会场饮水机不够用，他整个会期都在跑上跑下搬桶装水。后来他发现这样不行，就自学了 ARDUINO 和传感器，给饮水机做了个“水位监测提醒装置”，这才有了点“参会体验”。他现在是开源社的财务合规负责人，管着整个组织的账目。第二位志愿者当年是大学生，因为做会议速记，对开源产生了兴趣，毕业后直接入职了一家做开源基础设施的公司，现在自己也成了某开源项目的 PMC 成员。第三位更绝，她说自己第一次参会纯粹是“陪室友追星”，结果追着追着，自己变成了一个开源教育公益项目的发起人。
这段“十年致敬”没有什么大词，但现场所有人都安静下来了。我想它打动人的原因在于：开源社区最核心的资产，从来不是代码仓库存量，而是那些因为“参与”而改变了自己人生轨迹的人。当你能看到一组十年的轨迹，你才会理解一个社区真正的“增长”是什么。
3. 分论坛侧记：AI、基础软件与全球化三条主线
3.1 AI 分论坛：从“秀权重”转向“认真地用起来”
如果说前两年的开源AI会议还有不少“秀模型”“贴榜单”的演讲，那今年 COSCon 的 AI 分论坛几乎已经彻底转向了。大家默认你见过足够多的跑分，更想听的是“怎么把模型用起来”。我挑选了自己参加的几场，讲讲里面的干货。
一场关于大模型推理优化的演讲，讲者来自一家做私有化知识库部署的创业公司。他们分享了在 vLLM 上部署 Qwen 系列模型的生产经验。核心套路并不神秘：开启 prefix caching（前缀缓存），调整 KV Cache 的分配策略，配合 Continuous Batching 的默认参数调整。就这么几项，他们在同一批 GPU 上，把服务的 QPS 从不足 50 提升到了 180 左右。这个提升幅度，让台下不少人拿出手机拍照。演讲者给了一个很中肯的建议：先穷尽“推理引擎的配置优化”，再去考虑换更大的模型。很多团队上来就砸钱上更大的卡，却没有意识到自己的吞吐瓶颈可能出在缓存策略和批处理机制上。
另一场关于 AI Agent 的分享，角度更少见。讲者是一个开源 Agent 框架的维护者，他直言自己团队花了大半年时间，最后发现 Agent 翻车的原因里，90% 是工具调用出错了。模型不是“不够聪明”，而是不知道该在什么场景下调用哪个工具、参数该怎么填。于是他们干脆做了一个专门的“tool-use 微调数据集”，把特定领域下工具调用的准确率从 68% 拉到了 91%。这个思路给我很大启发：与其盲目追求“换一个更强的底座模型”，不如先把工具层的语义整理清楚，让模型“知道做什么”比“做得更聪明”往往更关键。
AI 分论坛还有一个隐藏共识：高质量数据集的稀缺，已经成为制约开源模型进步的最大瓶颈之一。有个高校团队分享了一个数据处理流水线，他们把原始网页数据从清洗、去重、过滤到格式化，整个压缩比大约为 130:1。也就是说，130TB 的原始抓取，最后只留下了 1TB 左右的预训练文本。这个数字放出来，全场都安静了一下——数据的“脏”程度，远远超出多数人的想象。那个团队还提到，他们正在把这套处理流水线本身开源出来，欢迎数据方向的研究者一起迭代。我觉得这类“隐形基础设施”的价值，未来可能会不亚于模型权重本身。
3.2 操作系统与基础软件：供应链安全和维护者过劳
操作系统与基础软件分论坛是今年 COSCon 的另一个重头。在这个分论坛上，“开源基础设施”不再是一个抽象名词，而是被掰开揉碎成一个个具体的问题：谁在维护那些全世界都在依赖的底层组件？他们有没有足够的时间、资金和身心支持？
有一场演讲分享了这样一组数据：某个下载量超过 1 亿次的核心开源组件，核心维护团队只有 3 个人。这种“关键组件依赖极少数人”的情况，在开源世界里并非个例。更令人担忧的是，维护者的数量和组件的重要性之间，往往不成比例——越底层的代码，反而越没人去长期维护，因为维护者“出名”了之后，会被无数上层项目依赖，提交给这个项目的 Issue 和 PR 会越来越多，而维护者的精力只会越来越少。
这场演讲的价值在于，它没有停留在“现状很糟糕”的层面，而是提出了一些可能的方向。比如：企业应该设立“全职上游维护者”岗位，把“抽调开发者去改上游代码”从临时性的工作安排变成固定的制度；云厂商和头部互联网公司可以联合为关键基础组件提供资金和技术支持，而不是只“白嫖”开源代码；开源基金会可以考虑建立维护者“备份”机制，为核心项目培训第二梯队，避免“被公交车撞了项目就停摆”的极端风险。
在我看来，今年的操作系统分论坛之所以值得写进文章，是因为它标志着开源社区终于开始正视一个长期被忽视的问题：开源不是免费的，它只是把成本从用户侧转移到了维护者侧。如果整个生态不思考如何“反哺维护者”，那迟早会有越来越多的核心组件无人维护。这个分论坛没有给出完美答案，但“开始讨论”本身就是一大进步。
3.3 全球化与出海：中国项目如何避免“自嗨”
今年 COSCon 的国际交流氛围浓度，明显高于往年。在“开源项目出海”相关的分享中，几位有国际化经验的维护者和基金会的代表聊了很多实操层面的问题。我把他们的观点整理成了几个要点，应该对想做国际化的开源团队很有参考价值。
第一个要点是文档语言要“一条道走到黑”。很多项目刚开始做国际化时，只是把 README 翻译成英文，但中文版本仍作为主要更新对象，英文文档往往滞后好几个版本。这样做带来的直接后果是：海外用户查到的文档永远是旧的，他们的问题反馈和代码贡献就会变得混乱，项目活跃度自然上不去。正确的做法是，如果你决定要面向全球，就把英文当成第一语言来维护，每次代码变更的同时更新英文文档，中文文档反而可以允许一定的滞后，这不是“崇洋媚外”，而是效率管理。
第二个要点是**“时区破壁”不是靠个人硬扛，而是靠流程设计**。中国维护者和欧美用户存在天然的时差，Issue 处理延迟是必然的。解决的办法不是要求维护者 24 小时在线，而是要在 CONTRIBUTING 文档里写清楚响应周期预期，比如“Issue 将在 2 个工作日内获得首次响应”，同时可以配置 GitHub Actions 机器人，对新 Issue 自动发送格式模板和初步排查指引。把“预期管理”做好了，用户在等待期就不会焦虑，维护者的压力也会小很多。
第三个要点稍微反常识：国际化不是“丢掉中文社区”。那位讲者提醒说，很多项目为了“出海”，把整个社区沟通都切换到了英文，结果伤了原本的中文贡献者。一个好的做法是“双轨制”：GitHub Issues 用英文为主，但定期整理中文摘要；Discussions 板块可以中文英文分区；线上开发者会议中英文双语进行。你以为国际化是一个“零和游戏”，其实它是一个“增量市场”。
3.4 开源教育：新手需要的是“无风险的台阶”
开源教育分论坛今年异常火爆，这是我没想到的。现场不仅有老师、学生，还有很多企业里的“开源布道师”。大家讨论的核心问题只有一个：如何让一个完全的新人，从“想参与开源”变成“真的提交了第一个 PR”？
几位讲者都认同一个判断：新手参与开源最大的障碍，不是代码能力，而是“心理安全感”。新人不知道从哪儿下手，怕问问题被喷，怕提交的代码不合规范，甚至怕自己占用了“大牛”的时间。针对这个问题，一位高校老师分享了一套“新手任务设计”的方法。其核心思想是：把参与开源的第一步，拆解成若干个“几乎无风险”的小任务，让新人逐步建立信心。
我现场记录了一下这套拆解思路，大概可以分成四步。第一步：在 GitHub 上给目标仓库点 Star、Watch，或者提一个文档勘误的 PR——这个操作难度极低，但可以让新人完整走一遍 Git 和 PR 流程。第二步：去找标着“good first issue”的 Issue，但这里有个前提，维护者必须把任务描述写清楚，包括涉及哪些文件、预期怎么改、如何本地自测，否则“good first issue”就只是一个政治正确的标签。第三步：让新人在 Discussions 里回答用户提问，这能帮他们快速理解项目功能和使用场景，同时获得社区的“存在感”。第四步：鼓励新人参加一次线上开发者会议，哪怕只是旁听，也能让他熟悉维护者之间的沟通方式和项目的发展节奏。
这位老师说了一句话，我记在了手机备忘录里：“开源不是相亲，而是一场养成游戏。”想让新人留下来，就得给他设计一条能持续获得正反馈的任务路径，而不是一上来就把他扔进满是各种缩写术语的邮件列表里。这句话不仅适用于教育场景，我觉得也适用于任何一个开源项目的 onboarding 设计。
4. 展区与工作坊：动手、体验与项目交流
4.1 开源硬件工作坊：三小时从零做一个“会说话的门牌”
每年 COSCon 都有一块“动手”区域，今年我特意留了半天泡在开源硬件工作坊。主办方给每位报名者发了一套基于 ESP32-S3 的开发板、一个墨水屏、一个语音合成模块和若干传感器，目标是在三小时内做一个“会说话的门牌”。
这个门牌的构思其实很简单：墨水屏上显示房间的三种状态（空闲、会议中、午休），房间里的用户按一下旁边的按钮，语音模块就会播放对应的提示语音。整个项目是一个完整的开源硬件样例：硬件设计文件用 KiCad 绘制，固件源码放在 GitHub 上，外壳模型是三个 STL 文件，可以直接 3D 打印。工作坊的动手重点不在“设计电路”，而在于“把它组装起来并跑通固件”——接线、烧录、修改配置、测试语音播放。对于平时只写后端代码的人来说，这种“物理世界跑起来”的成就感，确实是纯软件项目给不了的。
工作坊间隙，我跟项目作者聊了几句。他说这个开源硬件项目的初衷，是想做一个“入门但完整闭环”的案例，让新手能在一天内接触嵌入式、传感器、无线通信和数据展示这几条技术线。项目在 GitHub 上已经积累了上千 Star，维护者也确实很用心，文档里连“如何在美国亚马逊买对应型号的传感器”这种细节都写了。我后来翻了一下仓库的 Issue，发现提问者的回复速度也很快。这种“小而美”的开源项目，价值不一定比那些大型基础设施项目低——它可能改变了某个人对硬件开发的整个认知。
4.2 展区里的“人气王”：AI 推理、边缘计算和开发者工具
今年展区的布局很有意思，几乎没有那种“拉个横幅发传单”的纯品牌展位，大部分都是在展示具体的技术项目。我绕着展区逛了几圈，发现几个“人气王”项目。
人气最旺的，是一个做端侧 AI 推理框架的团队。他们现场摆了一台几百块钱的 AI 开发板，实时跑着一个视觉识别模型。那个设备并不大，但它能流畅地识别台面上的物体，延迟很低。展台的工作人员介绍，他们用了模型量化和算子优化的方式，把一个原本需要 2GB 显存才能运行的模型，压缩到了可以在移动端芯片上实时跑的程度。很多围观者当场就开始问文档在哪、有没有示例代码、支不支持自己的开发板。这种“马上能上手”的项目，明显要比“发布了一个大模型权重”的项目更有吸引力。
另一个让我驻足比较久的是国产开源监控与可观测性展台。他们不是简单地摆一个 Grafana 面板，而是现场演示了如何在十分钟内，从一台裸机拉起完整的监控告警系统：Prometheus 抓取指标、Loki 收集日志、OpenTelemetry 接入链路数据，最后在 Grafana 里呈现统一看板。整个过程全部通过命令执行，没有使用任何商业 SaaS。对很多中小团队来说，这可能是他们最需要的那类“省心参考方案”。我在现场看到不少人在小本子上记命令，这种“直接抄作业”的氛围，比听一场分享来得更有效率。
4.3 云原生/DevOps 选型的“避坑”参考
在云原生相关的分享和展台里，我收集到了一些比较实际的选型建议。给不专门做运维的开发者提个醒：如果你们团队正准备把 DevOps 工具链开源化，不用一上来就追求“全家桶”，应该根据团队规模和业务阶段逐步演进。
先说 CI/CD。代码托管在 GitHub 就先用 GitHub Actions，代码托管在 GitLab 就先用 GitLab CI。这两个工具的优点是零维护成本、生态成熟、语法资料多。等到项目数量多了、对复杂流水线编排有需求了，再考虑引入更适合长流程的流水线工具。容器运行时方面，Docker 和 Podman 选一个就行——前者生态全、文档多，后者更强调无守护进程和 rootless 安全。日常开发用 Docker 没有毛病；如果是强调安全的生产环境，可以评估 Podman。
Kubernetes 这块，我建议按需引入。如果团队只是十几个服务、没有特别强的弹性伸缩需求，可以先不碰 K8s，用 docker compose 或者干脆上一台云主机的部署脚本就够了。等业务确实需要自动扩缩容、需要应对突发流量时，再从 k3s 这类轻量发行版开始，会比直接上一套完整的 K8s 运维体系要平滑得多。
可观测性是目前开源工具链里最成熟也最“卷”的方向：Prometheus 加 Grafana 做指标，OpenTelemetry 做链路追踪，Loki 做日志，这一套现在已经称得上事实标准。如果你所在的团队还在用“手动 SSH 上去看日志”的土办法，我建议尽早迁移。我意识到一个规律：DevOps 工具链的核心价值不是“让你玩得更花”，而是“让你在出问题时更快地定位问题”。所以选型永远要以“可运维性”为纲，而不是以“技术热度”为纲。
4.4 教育公益展台和资料：开源活动工具包与成熟度模型
在开源教育相关的展区，我看到了一个让人眼前一亮的东西：开源社发布的开源活动工具包。这个工具包把所有执行层面的细节都整理好了，包括活动策划模板、志愿者分工表、预算清单、宣传文案模板、风险管理清单，还有历届活动复盘文档。全部文件以开源协议发布，任何人都可以直接拷贝修改。
这个工具包解决的痛点是：很多高校和中小企业想办一场开源主题的活动，但并不知道从哪里入手。办一场活动涉及场地、议程、预算、嘉宾、宣传、签到、直播、会后复盘等等环节，新手如果不借助模板，很容易漏东漏西。现在有了这套完整的活动模板，按照填空的方式推进，至少可以节省两周的准备时间。我在现场翻了一下那份“志愿者分工表”，光是签到和引导这两个看似简单的岗位，里面都列出了不同方案和应急预案。这种“把细节抠到极致”的文档，背后一定是从一次又一次活动复盘里积累出来的。
配合活动工具包一起发布的，还有前面提到的开源社区成熟度模型。两套工具的搭配逻辑很清楚：成熟度模型帮助你判断社区处于什么阶段，活动工具包则提供在当前阶段可以做哪些事来促进增长。一个诊断，一个行动，结合起来使用效果更好。如果你所在的组织正在摸索如何“社区化运营”，不妨直接去开源社官网下载这两份材料，亲自试一试。
5. 那些值得记住的瞬间与声音
5.1 闪电演讲里的“人间真实”
COSCon 每年的闪电演讲（Lightning Talk）都是保留节目：每人只有五分钟，超时断麦，不讲虚的。今年我听到了好几个特别真实的分享。
第一位演讲者分享的，是他给自己项目提 Issue，结果被自己的自动过滤器当成垃圾邮件拒了。他解释了一下原因：因为项目太忙，他写了一个规则——凡是内容里包含“点击链接”“立即注册”“限时”这类关键词的 Issue，一律自动标记为垃圾信息。结果他自己提的 Issue 里引用了产品文案，刚刚好踩中了关键词。这个故事的荒诞之处在于：一个为了“省时间”写的自动化规则，最后反过来伤害了自己的真实需求。台下笑成一片，但做过开源维护者的人，多少都能从中看到自己的影子——自动化常常是“为了效率”，却偶尔变成“愚蠢的守门员”。
第二位演讲者的主题是“文档不是写出来的，是‘用’出来的”。她分享了一个真实试验：把项目的详尽文档全部撤下，只留一页快速上手指南，然后在 Discussions 里鼓励用户直接提问，她再从高频问题中提取内容，反向补充文档。三个月以后，文档的“命中率”反而比以前高了——以前文档是“写了没人看”，现在文档里每一句话都是“用户真的问过的问题”。这个思路不一定适合所有团队，但如果你发现自己的文档总是没人看，可以试试这种“让用户帮你写文档”的反向操作。
整场闪电演讲听完，我最大的感受是：技术圈的分享经常有一个问题——讲得太“干净”了，好像所有决定都是深思熟虑后的完美决策。但闪电演讲恰恰相反，它允许甚至鼓励你暴露自己的失误和窘境。这种坦诚，是 COSCon 里最有价值的部分之一。
5.2 维护者心声：这不是一个“技术问题”
今年年会上最让我触动的一个环节，是 Open Talk 上一位维护者的分享。那个环节就是开放麦克风，任何人可以上去讲五分钟。那位维护者走上台，说的第一句话是：“我不是不喜欢写代码，我是不知道怎么拒绝别人。”
他讲了自己的日常：维护一个被上千个项目依赖的库，每天打开 GitHub 都是几十条新通知——有人问问题、有人提需求、有人提交 PR、有人发感谢信、也有人催更。他尝试过所有时间管理技巧，但问题不在于时间，而在于“每一次回复都意味着承诺”。拒绝一个 Issue，可能会伤害一个贡献者的热情；接受一个 PR，又意味着后续无止境的 review 和修复责任。两年下来，他没有休过一个完整周末，体检报告也亮起了红灯。
全场安静了很久，然后响起了很长时间的掌声。我想这掌声不只是同情，更是一种自省——那些曾经在 Issue 下面留言“什么时候修”的人，大概也会在那一刻意识到，屏幕对面回答他们的人，其实是一个没有工资、没有下班时间、义务为整个行业打工的普通开发者。维护者的困境不是技术问题，而是一个结构性的“价值分配”问题。一个开源项目给了全世界免费的价值，但“全世界”并没有给维护者足够的支持。这个问题，不是一个模型、一个框架能解决的，它需要整个生态的认知转变。
5.3 展区之外：走廊里的那些“非正式”高光时刻
每年 COSCon 结束后，我回忆起来的内容，往往不是演讲里的金句，而是走廊里发生的一些小场景。今年有两件事让我印象深刻。
第一件是在茶歇区，我看到一个学生模样的参会者，拦住了一位做开源数据库的维护者，掏出手机给他看报错截图。维护者没有敷衍，而是蹲下来在手机屏幕上划了几下，两个人讨论了十来分钟。后来那个学生告诉我，他其实只是偶然路过展区，看到项目名很眼熟，就抱着试试看的心态去问了。结果不仅解决了问题，对方还邀请他加入项目的贡献者群。这种场景在开源会议上并不罕见，但每次看到都觉得很温暖——开源的“开放”，不只体现在开源许可证里，更体现在这种“陌生人之间也愿意认真帮忙”的互动中。
第二件事发生在会场外面的长椅上。几个从不同城市来的开发者，因为排队时闲聊认识，最后发现大家维护的三个项目刚好可以互相整合，当场就约定回去之后开一个线上会议细化方案。他们在长椅上交换了联系方式，又花了半个多小时用手机画架构草图。这让我想起开源圈子里常说的一句话：开源协作的本质不是代码共享，而是“人和人之间的信任建立”。而线下会议，恰恰是建立信任效率最高的方式。这也是为什么，虽然线上协作工具已经非常发达，但 COSCon 这种线下聚会始终无法被替代。
6. 给不同参会者的行动参考
6.1 第一次来 COSCon，怎么安排三天行程
如果你明年计划参加 COSCon，却又担心被海量议程淹没，这里有一份基于我个人经验的行动路线，供你参考。
第一天（主论坛日）：上午雷打不动在主会场听主题演讲和年度报告，快速建立“宏观语境”。下午主论坛还会有几场大的圆桌，值得留在现场。晚上的 Welcome Party 尽量参加，这是结识同行的好机会——很多“重大合作”其实是在饮料和闲聊中达成的。
第二天（分论坛日）：这是信息量最大的一天。我的建议是，上午选一个你最关心的垂直赛道听满半天，下午留出时间逛展区。展区的核心价值不在于拿纪念品，而在于你能直接跟项目维护者对话。如果你对某个项目感兴趣，当场提问、当场扫码、甚至当场提交 issue，效率远高于会后在网上远程沟通。晚上通常会有 SIG 小组的闭门聚会，如果你已经在维护或参与某个开源社区，可以试着申请加入。
第三天（工作坊日）：第三天的内容以动手为主。如果你是开源新手，我强烈建议选择“Open Source 101”这类基础工作坊。不要觉得“太简单”，很多用了 GitHub 多年的人，其实并没有完整理解 fork、PR、review 那套协作规范背后的逻辑。如果你是有经验的开发者，则可以选择开源硬件实验室、数据分析实践营这类动手环节，换换脑子。第三天的傍晚，一般也是各种合作洽谈的高峰时段，如果有约人聊聊组队计划，可以安排在这个时间段。
6.2 社交效率技巧：别把大会当成“大型名片交换现场”
很多人参会容易陷入一个误区：以为“认识的人越多越好”。于是全场都在递名片、加微信，但会议结束之后，大部分联系方式都躺在通讯录里吃灰。我个人的经验是：高质量的社交，不是广度问题，而是深度问题。
你可以提前做三件事。第一，在官网或社交平台上提前查看讲师和议题列表，列一个“想见的人”清单，写清楚为什么想见、要聊什么话题。第二，在活动的 Open Talk、闪电演讲等开放环节里，尽量给自己找一个分享的机会，哪怕只是 3 分钟。人们更容易记住一个“讲了一点什么”的人，而不是一个“交换过名片”的陌生人。第三，加上微信或交换联系方式之后，顺手在备注里写上一句话：在哪里认识、当时在聊什么。否则三周之后，你翻着通讯录，完全想不起来对方是谁，那种感觉很糟糕。
还有一个技巧：提问比自我介绍更容易开启深度对话。在展区里，与其说“我对你的项目很感兴趣”，不如具体地问“你们项目在 XXX 场景下是怎么处理 XXX 问题的”。好的问题，会让对方感受到你是真的在关注他的工作，而不是在走过场。这往往能聊出很多文档里没有的细节。
6.3 开源新手的第一周行动计划：从躺平到迈出第一步
我见过太多人参加完大会之后热血沸腾，回到工位上却不知道从哪里开始。如果你也想成为开源的参与者，我推荐你按下面这个“一周行动计划”来拆解任务，我写过很多次，希望对你有用。
- 第一天：在 GitHub 挑一个你日常工作中真实依赖的开源项目，把它 Star 下来，Fork 到自己的账户，把仓库代码拉到本地跑一遍。
- 第二天：浏览该项目的 Issues 和 Discussions，找一条带“good first issue”或“help wanted”标签的任务。如果描述足够清晰，你可以试着去复现它描述的问题。
- 第三天：在本地尝试解决这个 Issue。就算最后你没有提交代码，解决过程本身就会让你对这个项目的结构有非常深入的理解。
- 第四天：如果你复现了问题，在 Issue 下面回复你的复现结果；如果你解决了，就提交一个 PR。如果实在没搞定，也可以整理一份“复现报告”发上去，这本身也是对项目的贡献。
- 第五天到第七天：尝试参加一次该项目的线上开发者会议，或者写一篇使用笔记发到技术社区，并在文末附上项目链接。
这套流程的关键在于“从无风险到有风险”的递进。第一天到第三天基本没有任何“被拒绝”的风险，第四天最大的可能性也就是 PR 被退回——那也没关系，维护者通常会给你说明理由，你相当于免费获得了一次代码 review 教学。当你完成了人生第一个被合并的 PR，哪怕是修正文档里的一个错别字，你都会发现自己已经正式成为了这个开源世界的一部分。这种“身份感”带来的驱动力，远比任何外部奖励都持久。
6.4 开源维护者的自我救赎建议
最后，我想专门对“正在硬扛”的维护者们说几句。作为开源项目的维护者，我完全理解那种被需求淹没的感受。今年年会上关于维护者倦怠的讨论，我整理出几个亲测有效的策略，分享给同行们。
第一，把“响应时间预期”白纸黑字写下来。在项目的 CONTRIBUTING.md 里，明确写清楚“Issue 预计响应时间为 2 到 5 个工作日”“维护者主要活跃时间在周末”一类的说明。很多人焦虑的根源其实不是“问题没解决”，而是“不知道什么时候会解决”。有了预期管理，提问者安心，你也就不需要被手机通知绑架。
第二，让自动化替你回答“重复问题”。配置一套 Issue 模板和初始回复的 Action，效果非常明显。比如要求新 Issue 必须填写“环境信息”“复现步骤”“期望行为与实际行为”这些字段，否则自动关闭。另一个有效操作是配置一个自动回复，对新 Issue 发送项目 FAQ 链接和过往相关讨论的搜索链接。据我观察，这一步至少能过滤掉三成的“已知问题”提问。
第三，学会“拒绝”并把它写进工作流。维护者常常有一种道德压力，觉得“拒绝”会伤害社区。但实际上，一个方向明确的“婉拒”远比模棱两可的“以后再说”更有价值。如果某个 PR 不在你的路线图内，你完全可以回复“感谢贡献，但这个方向暂时不在维护计划中”，然后把 PR 关闭。这并不残忍，反而是在为项目长期方向负责。
第四，给自己留一个“无责休息日”。我在日历上每周固定划出一个“不碰 GitHub”的日子。刚开始很难，总忍不住去点开通知。后来我强制把手机上的 GitHub 客户端卸载了，在家里电脑上设置了该时段的插件屏蔽，慢慢才建立起了“可以离线”的心理边界。开源是一场长跑，而不是一次冲刺。学会休息，其实也是维护者的必修课。
7. 结尾：我在现场的最大感受
参加完这届 COSCon，回到住处我脑子里转了很久的，其实不是哪个技术方案，而是一个略显“务虚”的念头——开源这件事，正在从“少数人的理想主义”变成“多数人的基础设施”。
十年前，很多人参与开源是出于一种简单的热爱和分享欲；而现在，开源已经嵌入了几乎所有软件的生产方式，甚至成为国家间技术竞争的焦点。但与此同时，开源也面临着真实的困境：维护者过劳、治理滞后、商业模式不清、全球协作摩擦增多。今年的 COSCon 没有回避这些困境，而是把它们放到了台面上认真讨论，这本身就很难得。
技术永远在进步，但技术背后的人才是开源真正的底色。如果你今年没有机会到现场，我希望这篇文章能给你一个站在会场之外的视角；如果你明年计划来，我想说，这不仅仅是一场会议，这更像是一个“回村看看”的仪式——看看老朋友、认识新朋友、聊聊各自走过的路。开源的路还很长，但只要我们还在持续地“共建”，这个圈子就不会让人失望。
