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 没有回避这些困境而是把它们放到了台面上认真讨论这本身就很难得。技术永远在进步但技术背后的人才是开源真正的底色。如果你今年没有机会到现场我希望这篇文章能给你一个站在会场之外的视角如果你明年计划来我想说这不仅仅是一场会议这更像是一个“回村看看”的仪式——看看老朋友、认识新朋友、聊聊各自走过的路。开源的路还很长但只要我们还在持续地“共建”这个圈子就不会让人失望。
