2025年的这个周末北京的冷空气如约而至但会议中心里几乎感觉不到外面的凉意。COSCon‘25第十届中国开源年会就在这样热闹又高密度的氛围里圆满画上了句号。三天下来主论坛、几十个分会场、工作坊、开源市集、闪电演讲……信息量大到我直到返程路上才开始真正消化。这篇文章不做那种面面俱到的官方新闻稿我想以连续参加多届年会的老熟人身份挑出真正值得记住的片段聊聊这届年会到底在聊什么、哪些话题正在变成主流以及如果你明年打算来怎样逛才最值。作为国内历史最久的开源大会之一COSCon这些年给我的感觉一直是“社区味最浓、套路最少”。没有花哨的舞台特效没有念稿式的演讲很多分享就是项目作者直接上台讲踩坑实录。这届年会依然保持了这种气质但又能明显感觉到AI带来的冲击已经实实在在地渗透进了开源世界的每一个角落。无论你关注的是开发者工具、云原生基础设施还是社区治理与商业化都能在这里找到对应的讨论和最鲜活的实践。1. 先看门道这届年会到底在聊什么1.1 一张议题版图看懂年会的三条主线我习惯在参会前先把议程整体过一遍不是为了做计划而是为了感受大会的主题风向。COSCon‘25的议程版图非常清晰大致可以分成主论坛、技术分会场、社区与治理分会场、特色活动四块。主论坛承担的是定调子的功能议题围绕开源十年、AI与开源、全球化协作这些大话题展开。技术分会场则明显更细AI开发框架、云原生、数据库、前端、操作系统与硬件、安全合规都有独立的专场。社区与治理这一块是COSCon区别于很多商业技术大会的特色讨论的不是怎么写代码而是怎么让项目活下来、社区怎么运转、开源办公室怎么落地。特色活动包括工作坊、开源市集、闪电演讲、圆桌夜谈这部分往往是全场参与度最高的地方。我把三天的议题大致画成了一张思维导图核心就是三条主线。第一条是AI与开源的关系从模型、工具链到智能体框架几乎每个技术分会场都会拐到这个话题上。第二条是开源项目的可持续性包括治理模式、资金支持、商业化路径、合规风险。第三条是工程实践讲的是大规模企业到底怎么用开源、怎么回馈开源。这三条线互相交叉构成了今年会议最核心的内容骨架。1.2 会议设计背后的三个小心思为什么COSCon要同时开这么多分会场我一开始也怀疑过会不会导致每场人都稀稀拉拉。后来发现这个设计其实很聪明开源社区的人群高度分化做数据库的和做前端的语言体系几乎不互通。强塞进同一个大厅只会让两边都听不下去。分场之后每个主题都能聚起真正关心它的人讨论质量反而更高。第二个小心思是动手环节的排期。工作坊并没有挤在第一天的黄金时段而是放在了第二天下午正好是大家听完一轮分享、脑子里充满问题的时候。这个安排的好处是你带着具体疑问去动手比如怎么提PR、怎么写issue、怎么配置CI现场就有维护者手把手帮你解决学习效率比纯听课高得多。第三个细节是闪电演讲一直没被砍掉。每天都在主会场最后安排了五到八分钟的短分享讲的人大部分是普通贡献者、学生、独立开发者。有人觉得这种环节太碎、不够深度但恰恰是这些短分享让更多“还没成名但有好东西”的人有了上台的机会。一个开源大会能不能持续造血看的就是有没有源源不断的陌生面孔愿意站出来讲自己的东西。2. 主论坛高光时刻几个值得记下来的观点2.1 开源的下一个十年从“代码贡献”到“全面协作”主论坛有一位深耕开源操作系统多年的嘉宾讲了这么一句话我印象极深过去十年我们讲“开源就是源代码开放”未来十年开源更多是一种协作方式代码只是协作的载体而不是全部。这句话背后的信息量不小。他展开说了一个趋势现在一个成熟开源项目的贡献者早就不是清一色的程序员了。文档写手、UI设计师、测试工程师、翻译志愿者、布道师甚至法务和财务人员都在以各种方式参与项目。我自己的观察也印证了这一点。这两年不少知名项目的贡献者榜单里非代码贡献的占比越来越高。GitHub也一直在改进对文档、讨论、翻译这类贡献的统计方式。从这个角度看开源的门槛实际上在降低。你不需要成为顶尖程序员才能参与一个项目你只要有一项技能愿意贡献出来项目就多了一个维度的成长。这对整个行业来说是个好信号。随之而来的挑战是项目治理也要跟着变如何给非代码贡献者合理的认可和晋升路径如何设计一套不依赖“写代码量”的评估体系是很多基金会和社区正在头疼的问题。2.2 AI与开源今年所有人都在聊的事如果说往届年会上AI只是某个分会场的专题那今年它已经成了无处不在的背景音。我不只在一个分会场里听到类似的观点开源正在成为AI时代的基础设施而AI也在重塑开源本身的协作方式。现场聊得比较多的一个点是开源模型和开源数据。过去大家对开源的认知集中在代码上但AI时代训练数据、模型权重、评测基准这些东西的开放开始变得和代码同样重要。一位做开源数据集的嘉宾举了个例子很多团队测试模型时喜欢用几个公开榜单但榜单数据本身存在污染风险如果评测数据集不开源、不透明所谓的“超越GPT”就很容易变成一场自嗨。另一个被反复提及的方向是AI辅助开发对开源贡献者结构的冲击。GitHub的数据显示AI生成代码的建议采纳率正在快速上升这意味着大量重复性的代码工作会被自动化。对开源项目来说这可能带来两个结果一是贡献者的精力可以从枯燥的格式调整、模板代码中解放出来专注更有创造性的部分二是项目维护者对代码质量的审核责任变得更大AI生成的代码谁来保证正确性这是一个新问题。现场没有谁给出标准答案但把问题摆在台面上认真讨论本身就是这届年会最有价值的部分。2.3 台上的小插曲台下的真包容主论坛下午场有一个环节嘉宾讲到一半现场的演示环境突然出了问题连不上远程服务器。换在商业发布会的场合这可能是个事故但在COSCon的舞台上与会者的反应让我有点感动。观众席先是安静了两秒然后有人喊“别急我们再等一会儿”还有人在鼓掌打气。那位嘉宾也没有慌张一边排查问题一边自嘲说“这就是为什么我一直强调开源项目要写清晰的错误日志没想到今天自己先示范了一下反面教材”。大概过了两三分钟网络恢复了演示继续。事后我在走廊里听到几个参会的开发者在议论说如果是商业闭源产品遇到这种问题你可能连日志都看不到但开源项目的好处就是所有人都在帮你找问题。这个小插曲没有出现在官方回顾里但我觉得它比很多圆满的演讲更能体现开源社区的氛围。3. 分会场深度拆解六个趋势背后的信号3.1 AI开发框架与智能体从“套壳”走向工程化AI分会场是今年最拥挤的场次之一很多人是站着听完的。我听了几个关于智能体框架的分享最大的感受是大家已经过了“做个Demo”的阶段开始认真讨论工程化问题。比如Agent的记忆怎么管理、工具调用怎么避免死循环、多Agent之间怎么通信这些都是实际落地时绕不开的坎。有个项目团队分享了他们做智能体编排引擎的经验其中一个观点我很认同不要把Agent做成一个黑盒而是把它拆成规划、工具、记忆、执行几个模块让每个模块都可插拔、可替换。这样做的好处是你可以随时换掉其中一个能力源而不需要把整个系统推倒重来。这和开源社区模块化思维一脉相承也解释了为什么很多Agent项目会选择开源的方式来迭代。另一个热度很高的话题是RAG的进阶玩法。去年大家都在说RAG今年的分享更多聚焦到如何把RAG做到足够可靠包括混合检索策略、rerank模型的选型、知识库切分粒度对召回率的影响。有位嘉宾打了一个比方说RAG就像图书馆的检索系统切分文档如果像把一本书拆成一页一页那每一页都失去了上下文检索效果当然差。这种来自一线的调试经验在官方文档里很难找到。3.2 云原生与平台工程开发者的“水电煤”云原生分会场有一个词出现频率极高平台工程。过去几年我们讲云原生关注的是怎么把应用容器化、怎么上Kubernetes但现场不少分享者提出了一个更现实的问题Kubernetes本身已经复杂到普通开发者玩不转了如果每个业务团队都要自己维护一套集群配置效率反而会下降。平台工程的核心思路就是把这些基础设施的复杂度收拢到内部开发者平台里让业务开发者只面对一个简单的自助界面不需要直接跟底层的容器、网络、存储打交道。有嘉宾把这个过程类比成水电煤的供应你家用电只需要插上插座不需要去了解发电厂怎么运作。内部开发者平台扮演的就是那个变电站的角色。我注意到过去这类平台基本都是大厂内部自研、秘而不宣今年却有一个很明显的风向越来越多的企业愿意把内部平台的核心组件开源出来。一位来自某大型互联网公司的分享者说他们一开始也很纠结担心开源后失去竞争优势后来想通了平台工程的门槛不在于那几段核心代码而在于组织流程和落地经验。把通用组件开源反而能吸引外部贡献者一起完善自己专注做最难的定制部分。3.3 数据库与基础设施软件稳字当头数据库分会场没有太多花哨的概念讨论的核心就一个字稳。这也是我每年都愿意蹲数据库专场的理由因为在这个领域任何花哨的PPT都骗不了人压测数据、故障恢复时间、真实生产环境的稳定性才是硬通货。今年有几个分享让我印象深刻。一个是关于分布式数据库在金融场景落地的嘉宾详细拆解了他们如何通过多副本强一致、跨机房容灾、灰度切换等手段逐步把核心系统往分布式架构迁移。这个过程用了将近两年分了四个阶段每个阶段都有明确的回滚预案。这种如履薄冰的态度和我见过的一些“新项目直接上生产”的做法形成了鲜明对比。另一个话题是国产开源数据库如何建立自己的生态。分享者提到一个很现实的问题代码开源了但用户还是不敢用为什么因为缺人、缺案例、缺培训体系。数据库不像前端框架你试个新版本顶多刷新一下页面数据库出问题可能影响几十万笔交易。所以数据库开源项目的社区运营重心往往不是拉更多人写代码而是让更多人敢用、会用、出了问题能找到人解决。这让我重新理解了开源生态建设的含义。3.4 开源合规与供应链安全被低估的硬主题合规与安全分会场的人气这几年一直在涨。早些年大家对许可证的态度是“用了再说”但今年现场讨论的深入程度已经完全不同了。几位分享者不约而同地提到了SBOM软件物料清单这个概念它就像是软件供应链的“成分表”把你项目里用到的每个开源组件、版本、许可证信息都清清楚楚列出来。为什么这件事越来越重要因为现代软件几乎没有“从零写起”的一个应用里百分之七八十的代码可能都来自开源依赖。一旦某个底层依赖爆出高危漏洞影响的是成千上万的上游项目。过去我们只知道“我的项目用了开源组件”但要回答“我这个组件到底从哪里来的、里面还嵌套了哪些子依赖、这些依赖有没有许可证冲突”没有SBOM根本说不清楚。现场有一个非常实用的经验分享讲的是大型企业内部如何做开源合规治理。他们每周扫描一次全量依赖把新增的依赖组件自动匹配许可证白名单匹配不上的自动生成工单让法务评审。这个流程听起来简单落地却有很多细节比如怎么处理那些许可证声明不完整的仓库、怎么区分“直接依赖”和“间接依赖”的不同风险级别。对任何一家深度使用开源软件的企业来说这套流程都值得抄作业。3.5 社区运营与项目治理让项目活下来的关键在社区与治理分会场一个观点被反复玩了几个回合大部分开源项目的死因不是代码不够好而是社区没运转起来。代码写得再好如果没人审PR、没人回答issue、没人发版本项目就会慢慢腐烂。现场有个圆桌圆了挺有意思的一个问题项目火了之后维护者最该做的一件事是什么有人说是继续写代码也有人说是找钱但最后大家比较认同的答案是学会放手也就是建立一套不用靠创始人盯着也能运转的治理机制。具体来说包括清晰的贡献者分级标准怎么从Contributor晋升到Maintainer、透明的决策流程重大变动要不要开会投票、代码评审的轮值制度、以及社区行为准则的执行边界。还有一个我在笔记里专门写下来的观点开源治理不是搞民主选举而是像经营一家公司一样做角色分工。有人负责技术方向有人负责社区运营有人负责对外合作各司其职。很多翻车的社区翻就翻在所有人挤在一起做同一件事。这个类比让我一下子想通了很多曾经困惑的问题。3.6 教育与开源文化在源头播种子教育分会场相对安静但内容耐人寻味。我听到一位老师的分享讲他是怎么把开源文化带进课堂的。他没有让学生一上来就去读大项目的源码而是从修文档错别字、补测试用例这种小任务开始让他们在两周内就体会一次“自己的PR被合并”的成就感。这个思路我特别认同。开源教育最容易犯的错误就是一上来就布置一个“大作业”让学生独立开发一个完整的项目。但在真实的开源世界里大部分贡献都不是从零开发而是在现有基础上改进一点点。让学生先感受“在别人项目上添砖加瓦”的协作模式比逼他们闭门造车更有价值。现场还提到一个数据说参与开源项目的学生在求职时获得面试邀请的概率明显更高。原因不难理解GitHub上的公开贡献记录是一份可以被任何人验证的真实履历。相比只能写在简历上的“精通XXX”一个具体的PR链接显然更有说服力。这也是我一直建议年轻开发者尽早参与开源的原因。4. 工作坊实录现场把第一个PR提交进开源项目4.1 我参与的那场文档贡献工作坊第二天下午我报名参加了一个面向新人的开源贡献工作坊主题是“为开源文档项目提交第一个PR”。这种工作坊每年COSCon都有强烈建议没有提过PR的人来体验一次。整个流程比我预想的要顺畅得多因为现场不仅有项目维护者还有很多志愿者在座位间来回走动随时答疑。工作坊的第一步是选任务。维护者列了一批标注了“good first issue”的文档类任务比如给某个API补一个使用示例、修正几处过时的安装说明。我选了一个给命令行工具补充参数示例的任务因为不涉及复杂的代码逻辑只需要看明白已有文档的格式照着写即可。接下来是标准操作流程先把项目Fork到自己的账号下然后用git clone拉到本地新建一个以issue编号命名的分支。这里有个小细节让我很受用维护者提醒我们分支名字最好直接用issue编号加简单描述比如docs-add-timeout-example-1234这样后续所有人通过分支名就能知道这条分支在干什么。我照做了后来PR被合并后我再回头看确实很清晰。修改完文档后就是提交代码、推送到远程分支、在GitHub上发起Pull Request。这是我紧张的一步因为我担心自己写的格式不合规。但维护者说文档类PR主要看两件事一是格式是否与现有文档统一二是示例是否真的能运行。我在本地手动执行了一遍示例命令确认输出正确才放心提了PR。提交完大概半小时后CI就通过了维护者在评论区留了一条“LGTM”并点了合并那一刻的成就感真的很真实。4.2 新人提PR最容易踩的五个坑结合工作坊现场观察到的现象我把新人提PR最常见的坑整理成了一个检查清单方便你以后参与开源时逐条核对。坑现象正确的做法不读CONTRIBUTING.md就动手提交风格、分支要求、获取协议全不对动手前先把项目根目录下的CONTRIBUTING读完抢别人已经认领的任务评论区已经有人留言“take”了还在做先看issue里有没有人认领有疑问先问一上来就改大文件PR动辄几百行维护者没有精力细看拆成多个小的、相互独立的PR一次只做一件事提交信息写得像聊天记录“update”“fix”没有任何上下文写明改动目的如“Add example for timeout parameter”不回应评审意见提完PR就消失了有评论及时回复并更新代码否则PR会慢慢变脏工作坊结束后维护者还额外提醒了一点如果你的PR没有被立即合并不用灰心大概率不是你的代码有问题而是维护者最近太忙了礼貌地回复一句询问或者直接在项目的Discord/交流群里问一下进展都是被接受的。很多新人项目一受挫就弃坑其实只是还没习惯开源异步协作的节奏。5. 我的参会路线图明年这么规划才不亏5.1 两条实测高效的逛会路线参会三天我最怕看到的情况就是很多人中午吃完饭站在议程板前面盯着看十分钟然后随便挑一个场子进去。这种逛法不是说不行但你大概率会错过最适合自己的内容。结合我这次的经验整理了两种高效的路线供你参考。技术深耕型路线第一天集中泡在主论坛和AI、云原生分会场把技术风向摸清第二天上午去数据库、基础设施或安全合规这类硬核场下午直接进工作坊动手实操第三天留给闪电演讲和开源市集轻松但信息量不完全低。这条路线适合想学具体技术、想为自己的项目找解决方案的开发者。社区社交型路线主论坛挑几个大演讲听其余时间泡在开源市集和圆桌夜谈。市集上每个社区展台的志愿者基本都是核心贡献者聊半小时能获得的信息往往比听一整场讲座还丰富。晚上再参加一场圆桌听老维护者讲社区八卦和踩坑史对理解开源生态很有帮助。这条路线适合社区运营者、布道师、创业者。注意没规划的情况下下午的热门分会场大概率坐满。出发前一定用大会小程序把想听的场次收藏好每场提前十五分钟到否则就只能站在后排听完了。5.2 和大牛聊天的姿势决定了你的收获上限很多人不敢跟台上的嘉宾交流总觉得对方很忙、自己问的问题太初级。实际上开源圈子的人普遍很愿意分享关键看你提问的方式。我观察过现场让我印象深刻的几次交流都有一些共性。不要开口就说“能加个微信吗”而是先介绍自己、说明来意比如“我在用你们的项目做XX遇到了一个XXX的问题想请教一下”。有具体的问题对方才容易接话。也不要一上来就问“你怎么看待开源未来十年”这种大问题这种问题太抽象对方很难在五分钟内给出有价值的回答。更好的问法是“你们项目在X版本里改了Y模块的设计是出于什么考虑”具体到版本、模块、取舍对方才会有聊下去的欲望。另外一个很容易被忽略的场合是大厅外的茶歇区。很多嘉宾讲完自己的场次之后会和大伙儿一样去接咖啡、吃点心。这时候走过去自报家门说刚听了你的分享有个地方没太明白对方一般都会很乐意展开讲。这种“路边摊式”的交流往往比正式问答环节更深入因为没有麦克风也没有时间压力。5.3 会后如何把一面之交变成长期协作年会散场之后能不能把会上认识的人保持住联系很大程度上决定了一次参会的长期价值。我自己的习惯是在三天内拿到的名片或微信备注里都写上“在哪场活动、聊了什么、约定下一步”。比如“COSCon AI分会场-聊了RAG切分策略-答应把测试脚本发我”。不做这个动作两天后你大概率想不起来对方是谁。更有效的做法是在会后的一周内进行一次轻量级的后续跟进。如果你聊到了一个感兴趣的开源项目不要只说“我去看看”而是真的去仓库里逛一圈提一个issue或者在讨论区留言然后把链接发给对方。这种“用行动说话”的跟进方式比任何客套话都更有分量而且它会让你自然而然地成为那个社区里的一份子。6. 照片拍不出来的现场细节6.1 开源市集社区文化的浓度计连着几年参加COSCon我最喜欢的地方不是主会场而是展区里的开源市集。几十个社区的自展位排开每个摊位上摆着各种你想象不到的东西做数据库的社区在发冰箱贴做前端框架的在扇扇子还有一个做硬件开发板的团队直接在现场焊电路板送了几个传感器模块出去。市集上的重头戏是集章打卡。各家社区都有自己的印章设计得一个比一个用心。我看到有个女生拿着一本厚厚的手账本上面密密麻麻盖满了同一品牌的几十个不同项目印章她说是从第一届年会就开始收集的这个本子本身就是一部社区记忆史。这种物质化、可触摸的文化沉淀是线上协作完全无法替代的。更有价值的是摊位后面的志愿者。他们不是公关公司请来的礼仪而是项目真正的贡献者。我问一个开源监控项目摊位的志愿者为什么他们的Webhook通知延迟有时候会偏高他直接掏出一个手机给我看后端监控面板现场分析是某个队列消费线程的压力问题。这种交流的密度和深度你在任何商业展会上都遇不到。6.2 三个让我印象深刻的“真实瞬间”第一个是闪电演讲环节有人讲超时了主持人试图提醒两次以后直接把话筒电源关了全场哄堂大笑演讲者也笑了然后用一句话快速收尾下台了。这个规则执行既严格又友善它保证了后面十几位演讲者都有公平的表达时间一个八十人的长篇演讲不管是多大牌的嘉宾都会被打断。这种对规则的尊重本身就是开源协作的隐喻。第二个瞬间发生在分会场之间的间隙。一位演讲者刚走下台就被五六个人围住了他们没有寒暄直接开始讨论刚才演示时提到的某个数据结构的实现细节。我从旁边路过时隐约听见他们在讨论大key的拆分方式一群人挤在一起用指头在空中画拓扑图。这种“结束后自动形成的小讨论组”每年都有无数个。第三个瞬间是会议最后一天下午市集开始撤摊的时候各社区的志愿者互相串门交换剩余的周边。我看到一个做前端工具的团队把他们没发完的贴纸整包送给旁边的数据库社区两拨人还约好了晚上一起去涮火锅。开源社区就是这么一个小世界领域的边界可以在几分钟内被共同兴趣消解。6.3 为什么开源年会值得你专程飞来一趟有人问我现在线上会议那么多、直播那么方便为什么还要花钱花时间跑去现场参加开源年会我的回答是如果你只想获取PPT里的知识直播确实够用了但如果你想知道一个项目为什么活、一个社区为什么散、一群人为什么要做开源你必须到现场来。线上的交流是异步的、被过滤过的你会看到别人想让你看到的部分。而线下交流里你能看到维护者说起项目未来规划时眼睛里的光能看到志愿者在摊位上忙了一天仍然兴致勃勃的神情也能在散场后的饭桌上听到那些不会写进文档的真实决策过程。这些信息没有知识密度但有情绪密度而情绪才是让人持续投入一件事的原始动力。从另一个角度看开源年会也是观察整个行业的极佳窗口。过去十年中国开源经历了从“拿来用”到“参与进去”再到“主导项目”的变化这种变化在会场上感受尤其直观。今年明显有更多本土项目开始输出自己的治理经验和全球协作模式这在国际开源社区里已经形成了自己的声音。作为亲历者在大环境快速变化的这几年里能在一个地方集中看到这么多坚持做实事的人本身就是一种很宝贵的确定性。这届年会开始前我在朋友圈发了一条动态说“第十届了见老朋友认识新朋友”。散场时再看发现这个愿望超额完成了。我听到不下五位分享者提到自己第一次接触开源就是通过当年在会场领到的一张贴纸、听过的一场工作坊然后一步步变成今天的深度贡献者。一届年会能做的事情确实有限但它能在足够多的人心里埋下一颗种子这就已经很了不起了。对我来说连续多年的参与本身也在反复验证一件事真正能让人长期留在某个社区的不是某一次精彩的演讲而是这里有一群你愿意每年见一次面的人。明年继续。