团队也能收到用户上报的各种性能问题。这就要求重新关注到在快速开发过程里被刻意忽略的细节，精打细算关键路径上的内存使用，针对性能修改抽象以充分利用机器资源。这部分工作都是细致工作，讲究一个

品牌的过度迷恋”。在我的认知中，往往是对社群本身的发展和软件的价值没什么可说的项目，才会期望以填充市场材料的方式来蒙混过关。相反，真正值得展示已有社群规模的项目，通常寥寥数语就能勾勒其形状，IPMC

项目在一定程度上是由志愿者推动的，但它也在一定程度上是由企业赞助的，并且不仅是基金会成员的赞助。尽管有时我认为企业赞助会对维护者产生不良影响，导致维护者没有动力做那些琐碎的维护工作[16]，但我认为

社群，对于已经确定要做的事情如何做，争论几乎总是无法收敛，而对于不确定要不要做的提案，尤其是核心假设的进化与兼容方案，更是在未来几年内都看不到达成一致的希望。@withoutboats

代码时，我都会全身紧张，视力模糊。当然，这些评论都不能完全代表全部观点：早在四年前就有人提出了一些担忧。在同一条评论中，有人抱怨异步代码让自己全身紧张、视力模糊，但也有很多人同样热情地为异步

https://github.com/alc-beijing/translation/blob/master/apache/incubator/cookbook-zh.md[51]新孵化项目提案:

出现之前开源商业公司追加商业保护条款的常见做法。这个协议很长，所以对开发者极不友好。去掉所有套话，其中最关键的条款是第四条“费用”和第五条“试用协议”。简言之，开发者通过申请，每个自然年最多可以试用

解释器）。如果每次调用都启动一个新的运行时实例，那么这个性能损耗将彻底疯狂，而如果常驻一个目标运行时的进程实例，那么更加成熟的解决方案是进程间通信。说进程间通信或

https://github.com/tisonkun/blog/discussions/16#discussioncomment-2573397[8]@vmihailenco:

在《开源运营当论迹不论心》的评论代表了开源开发者的主要观点：我们要看这个活动创造出了什么价值，而不是活动组织者的动机。灭虫活动有价值吗？有，但是只有一点点，跟维护者需要花时间去找

的方式向上游申请合并，最后大部分用户从上游分支取得源代码使用。在这个模型下，如何协同不同分支的开发，当上游发布了多个版本，尤其是并行维护多个发布版本时，如何管理分支，就是一个亟需解决的问题。Git

https://github.com/openai/openai-cookbook/blob/main/examples/How_to_stream_completions.ipynb[16]

本轮开源之风吹起迄今数年，最大的影响还是越来越多的商业公司开始探索开源方法能够如何改变自己的经营策略。开源策略循序渐进分成使用、参与和发起。在发起开源项目实践一线的，一个是打着开源旗号的创业公司，另一个就是大型企业尤其互联网企业（大厂）。前者我在过去的文章里已经详细讨论了他们的动机、面临的风险和应对策略。本文将关注大厂发起的开源项目的共同特点，讨论围绕这样的开源项目聚拢起来的企业研发团队、市场运营团队、用户开发者之间常见的认知失配问题。值得说明的是，这些问题虽然是大厂开源常见的问题，却不是大厂开源独有的问题，对其他开源项目的建设也有参考意义。用户不买账：我要怎么用起来？首当其冲的问题，是大厂开源的软件，离开了内部需求和重度集成的基础平台之后，很难为其他用户场景产生价值。通常，大厂开源的软件，来自于基础架构团队剥离其提供服务的核心，例如微服务中间件的核心框架、日志收集和分析系统、配置中心和监控系统等等。这些软件开发之初，是为了服务企业内部业务对基础软件的需求。企业内部的需求是特定的，而且往往倾向于把业务的需求推到基础平台来解决，随着集成程度的增强，边际成本不断降低。例如，内部平台上有一个配置中心，其他所有的软件启动时都默认环境里有这样一个配置中心，从中取得对应的参数做初始化。例如，内部平台有一套监控系统，有一套日志上报和分析的流程，这些逻辑都很容易侵入到其他组件当中。这就导致大厂一旦要开源，经常是一股脑的把整个基础平台都打包开源出来。BAT

https://cwiki.apache.org/confluence/display/FLINK/FLIP-92%3A+Add+N-Ary+Stream+Operator+in+Flink[10]

前几天，一篇名为《开源商业模式是个伪命题》的文章横空出世，看似犀利的观点却没有引起激烈的反驳。无论是开发专有软件的企业，还是重度投入到开源软件开发的企业，都认同开源本身并不是企业作为软件及服务提供商的商业模式。行业当中有这样的共识并不奇怪。如果你在国际互联网上搜索『开源商业模式』关键字，其结果从

今天，在许多开源软件项目乃至任何稍带开放性的项目的宣传中，我们经常能看到营销内容包含“共建”的字样，似乎说了这个魔法的词汇，项目就能迎接纷至沓来的“共建者”，其乐融融地“一起做大蛋糕”。然而，现实情况却是作为被营销对象的开发者日渐对这个词失去兴趣到产生反感。一眼看到某个项目营销言必称“共建”，心里就默默给它扣分拉黑甚至拉黑。共建的神话是如何产生的，为什么这个口号今天不能吸引和凝聚开发者呢？“共建”一词的释义是：共同建设，体现共同参与，发挥自身优势和潜能，形成新的合作优势。商业公司起初提这个词的动机，我想是成功的开源协同案例大多社群生态丰富、成员活动频繁。公司希望自己发起的项目也能一步到位整出一个人见人爱的社群，于是直接无差别宣传拉人共建，企图跨过中间阶段直达结果。我曾经在以前的文章里把共同创造价值作为开源社群发展的重要指导理念。为了做到共同创造价值，你需要回答潜在的用户和开发者他们能为你做什么和应该怎么做到的问题。今天许多项目“共建”的营销内容，上来先说的是自己如何如何的牛逼，或者庆祝完成了一二三四五件事情，到底期望营销的对象来共建个啥，全凭自己领悟，其画风大致如下：•我出弹药，谁能帮我打下这个山头？•我指出这个山头，谁能自备弹药帮我打下这个山头？•我也不知道哪里有山头，谁能自备弹药和地图，帮我找到和打下一个山头？一份有号召力的“共建”宣言，应当形如以下模式：1.一个新的产品或功能发布，期待用户给出反馈或使用测试报告；2.一个新的集成点已经就绪，诚邀生态项目和开发者评估并支持集成；3.一个新的技术难题被攻破，欢迎同领域的专家评鉴、探讨和改进；4.一个新的标准由权威机关提出，号召相关项目和开发者参与认证；5.一个新的组织或活动立项，介绍清楚纲领或目的之后招募成员。可以看到，这些模式在包括事实的基础上，明确了“谁”是我们的营销对象，我们希望给你带来“什么价值”，期待你做“什么具体的事情”。否则，所有可以“共建”的点，在营销文案里都不存在。要么说某个组织已经成立了，但是跟我有什么关系呢？要么说某个功能已经完成并发布，那还要我共建什么呢？这样漫无目的的“共建”营销，只会让被营销对象走向两个极端：1.完全不知道你要做什么，只能理解为我需要自己发现问题并解决问题，你在期待有人

的乔布斯是著名的远程工作反对者，他曾经说过“创造力源于自发的会议，来自随机的讨论。你遇到一个人，问问他在做什么，听了就说‘哇’，然后很快就有各种各样的点子冒出来。”我在某电商公司上班的时候，CRUD

我在《企业开源该选什么软件许可证？》一文当中，已经从软件许可证的角度讨论过不同协议对企业开源的意义。不过，那篇文章主要是从许可证内容出发的，即先给定了协议，分析完协议细节，再判断是否符合企业和计划公开的软件的情形。本文从企业开源的不同诉求和风险出发，结合现存的企业组织实践，重新讨论源码公开第一步就要面临的选择软件协议问题应该如何决策。完全开放源码完全开放源码，即以符合开源定义[1]的软件协议发布企业自研软件的情形。在讨论什么样的企业针对什么样的软件会采用完全开放源码的策略之前，我们先讨论完全开放源码的策略会给企业带来什么风险。符合开源定义的软件协议既包括宽容软件协议，也包括

在上一篇文章中，我介绍了企业开源的完全开放源码策略及其风险。完全开放源码，即以符合开源定义的软件协议发布企业自研软件的情形。本文介绍应对完全开放源码后的风险的第一种策略：提高市场占有率与开放标准。与其说是策略，不如说是促使企业完全开放源码的动机。策略：市场占有率与开放标准选择和坚持完全开放源码策略的一个主要原因，是企业希望完全开放源码的软件赢得广泛的市场占有率，甚至形成开放标准。以开源的程序设计语言实现为例，在语言本身赢得用户之前，很少有企业能够直接通过售卖语言实现的编译器或解释器来盈利。瑞典电信公司

我在《企业开源该选什么软件许可证？》一文当中，已经从软件许可证的角度讨论过不同协议对企业开源的意义。不过，那篇文章主要是从许可证内容出发的，即先给定了协议，分析完协议细节，再判断是否符合企业和计划公开的软件的情形。本文从企业开源的不同诉求和风险出发，结合现存的企业组织实践，重新讨论源码公开第一步就要面临的选择软件协议问题应该如何决策。完全开放源码完全开放源码，即以符合开源定义[1]的软件协议发布企业自研软件的情形。在讨论什么样的企业针对什么样的软件会采用完全开放源码的策略之前，我们先讨论完全开放源码的策略会给企业带来什么风险。符合开源定义的软件协议既包括宽容软件协议，也包括

系统，弃之可惜，所以只能麻烦点装双系统。硬件配置我自己是不会配的，找的好兄弟一揽子解决，这里就不介绍了。装双系统这件事我在大学时候就做过，当时还干过替换内核和开发内核模块，还有利用显卡写

的核心生产力在上游，所以大的技术方向红帽公司也只能配合上游社群前进。这种情况下，红帽选择的商业模式是提供面向企业需求的订阅服务，解决企业重视而上游社群不提供的版本稳定性、售后支持和维保承诺。后来的

春节在家整理存书，发现了当时在拼多多做业务开发工作的时候，用来帮助理解互联网企业服务架构的若干书籍。这些书里的技术方案可能有一定的落后，但是对于帮助新入职场的互联网公司程序员，了解一个典型的互联网企业核心服务架构，以及治理服务和分化出数据团队的过程里会发生的技术服务体系变化，还是很有帮助的。这里做一个分享。企业

条是相对静态的，软件使用层面的自由。用户可以出于任何目的自由地运行程序，可以自由地再次分发程序未经修改的拷贝，无需取得他人或公司的许可，自然也就打破了专有软件收取许可费或额外购买密钥的惯例。第

的导航栏是框架内定义的，预定义的类型里没有点击按钮回调的类型，只有点击图标跳转页面的能力。一开始，我做了一个点击登出图标后跳转到登出页面，在登出页面里做了登出按钮，但是这个体验就很别扭。所幸我发现了

https://airbyte.com/blog/a-new-license-to-future-proof-the-commoditization-of-data-integration[13]

社群就要到五个月后了。对于最好的编程语言的追求大多是一阵风，早晚会发现只有最适合的编程语言，而没有所有方面都最好的编程语言。幸运地是，我在五个月后的新学期开始做编译原理的实习课题的时候，发现

开发现实世界中解决问题的整体方案。•短视频和长视频短视频往往侧重于讲清楚一个用例或者展示一个炫酷的应用，长视频则大多是对功能设计或者行业解决方案的系统论述。社群体验实时交互•在线聊天渠道，例如

https://github.com/spring-io/start.spring.io/commit/51e3920f86c8da483f2adb3d35f79d99766d0d6b[7]

一样，对自己的用例有效，其他自己用不到的地方就不管了。但是把自己的修改提交到上游接受评审的时候，才发现原来这个改动可能牵扯到这个那个模块。上游同时被许多下游依赖着，因此它们所选择的解决方案很可能不是

https://airbyte.com/blog/a-new-license-to-future-proof-the-commoditization-of-data-integration[13]

开源社群存在的目的，主要是制造高质量的开源软件，并促进该软件的使用。为了达到这两个目标，开源社群需要调动参与者的积极性，并且协同背景多样的参与者的贡献，共同修复软件缺陷、改善软件体验、增加软件功能、组织社群活动和发展软件生态。大多数开源社群的环境里，实际进行组织协调工作的成员，就是社群的维护者（Maintainer）。不同开源社群对角色的定位和命名有着各自的风格。Vim

越来越多的开源软件占领了各个领域依赖链条的关键环节，越来越多的程序员也以参与知名开源软件的开发为荣，将开源贡献和在开源社群当中获得的头衔作为简历当中浓墨重彩的一部分。在这样的背景下，技术驱动型公司的

分布式系统的开发者知道，不同于本地方法调用总是被执行，要么成功要么失败，分布式系统之间各个组件的远程调用还存在第三种可能，那就是超时。从消息发送者的角度看来，超时意味着没有确认信息返回。但是当前调用对应的一系列操作到底是已经成功，只是回复丢失，还是其中某些失败某些成功，或者全部失败，甚至是请求本身没发出去，这些情况一概无法断言。大部分开源社群是分布式组织，社群成员分布在不同的地域乃至不同的时区。相比于线下集中办公的组织而言，分布式组织与分布式系统一样存在着“超时”的挑战。线下集中办公时，负责同一个工作项目的人经常会坐在一起，有什么事情转过头、走几步也就当面说清楚了。工作关系紧密的几个人往往会共享午餐时间，休息娱乐时间。这种面对面的合作带来的信任感和大小事情都能当面沟通的效率，是分布式组织很难直接做到的。不过，无法效仿线下集中办公的方式直接面对面沟通，并不意味着开源社群这样的分布式组织的沟通效率就总是低下的。从我在开源社群数年的观察和实践来看，要想做到在开源社群这样的分布式组织当中高效地协同，确保事情在异步沟通和分布式合作的情形下仍然能够稳步前进，一个不可缺少的点就是饱和沟通（Overcommunicate）。饱和沟通的重点落在“饱和”，这意味着沟通反馈必须是及时的，甚至会稍微超出必要的限度。我刚进入到开发者社群关系的角色的时候，曾经被问过这样一个问题：为什么你能够在

的原始文件，所以可以直接以当前时间为基准框出前后十二个小时的数据集文件名后过滤。我没有那么大的存储空间，只能从当前最新的数据往后连续数一天了。具体的脚本逻辑不逐行讨论，只说几个值得一提的点。1.导入

随着信息化和数字化的发展，传统企业的业务发展在软件的帮助下突飞猛进。软件技术日新月异，几乎每隔几年就会有全新的技术和产品颠覆过往业务开展的方式。然而，掌握前沿软件技术的人相对于全行业的需求可谓是凤毛麟角。为了规模化前沿技术的价值，越来越多的软件服务公司如同雨后春笋一样不断出现。顾名思义，软件服务公司主要以提供高质量的软件或软件服务来提高其他企业开展业务的效率。随着软件技术日益复杂，采用何种软件服务逐渐从以往的

我在《企业实践开源的动机》和《如何应对云厂商的“搭便车”行为》两篇文章中对这种商业模式已经有详细的介绍和议论。鉴于最近企业服务领域的创业公司以源代码可读为卖点，并大肆渲染“开源

│└────────────┴───────────┴───────────────┴───────────────────────────────────────────────┘*/除了

https://airbyte.com/blog/a-new-license-to-future-proof-the-commoditization-of-data-integration[5]

开源软件不是凭空出现的，开发开源软件是一项艰苦卓绝的工作。每个开源软件的背后少则有原作者一人的投入，多则协同了成千上万人组成的开源社群的共同努力。然而，开源软件的源代码总是免费可得，并且开源软件协议总是不限制用户的使用形式。基于开源软件完成工作乃至搭建业务盈利的用户，并不总是参与软件开发的人，这种形似经济学中“搭便车”的行为，在国内被提及的时候总会被称为“白嫖”，以至于后者称为圈内的一个热词。那么，开源世界当中到底存不存在“白嫖”，不同角色眼中的“搭便车”行为到底是怎么样的？本文将对此做些讨论。用户的“搭便车”行为从经济学的角度上，“搭便车”行为意即不付成本而坐享他人之利。由于开源运动的精神就包括了制造出来的开源软件的源代码免费可得，并且不限制任何人将其用于任何用途，所以我们可以说，开源世界当中“搭便车”的行为是广泛存在的。实际上，当我们编译一个

《程序员修炼之道》[1]讲了一个有趣的“石头汤”寓言。这个寓言里，饿着肚子的外来人在村子里烧了一锅水，放了三块石头，开始煮“石头汤”。这样的行为引来好奇的村民围观，外来人顺势在“石头汤”的基础上引导村民们添加食材以改善这锅料理。最后，村民和外来人一起煮出了一锅靓汤，外来人于是把石头从汤里扔掉，所有人分享了这顿美餐。开源协同的工作方式与制作“石头汤”的方式有些相似。开源社群的核心成员与寓言中的外来人一样，充当了催化剂的角色，将这些各自拥有不同背景的人群组织起来。这样，社群成员才能聚在一起做出他们单独无法做到的事情。最后，所有人都是赢家。当然，在这个版本的“石头汤”寓言里，村民被外来人骗了，石头并没有为最终的美味产生直接价值。《开放式组织》[2]指出这种行为是一次性的，并且价值仅仅单向地从村民一方流向外来人一方，以至于它被冠以“汤姆·索亚合作模式”的恶名。开源协同的模式保留了“石头汤”寓言当中催化剂的内核，但是这一次，外来人提供的不是水煮石头，而是初具规模的汤底和食材。《大教堂与集市》[3]在揭示集市模式的必要条件时阐述了这一点，这个隐喻意味着一个能运行的软件，并且让潜在的合作开发者相信，这个软件在可以预见的未来，能够演变成一个非常棒的东西。Apache

随着开源软件全面占据软件供应链的各个阶段，商业公司开发基础软件或业务逻辑的时候，已经避不开对软件的使用了。经过一段时间对开源软件的使用，以及开源吞噬软件的趋势影响，研发能力突出的公司或团队，也会加入到开发开源软件的行列中来。商业模型当中开源软件位置的不同，体现出企业实践开源动机的不同，并且会很大程度影响企业实践开源的行为。本文将讨论不同商业模型下，企业实践开源的动机和行为的差异。商业模型是销售开源软件第一类商业模型是直接销售开源软件。这种类型的企业以

的原则，也就是上面提到的所有重要的讨论都应该记录在案，所有线下的讨论事后也都应该公开记录。关于这一点，《制造开源软件》[19]专门有一章《避免私下讨论》[20]做了详细分析。独立性

关于开源软件的发布相关的内容还在构思当中，先摆烂重发部分以前讨论过的关于构建系统的文章。构建和发布密不可分，可以认为都是持续交付流水线的一环。我会分多篇文章讨论软件发布和开源软件发布的各个方面，文章内容再加以提炼放到编撰当中的《开源指南》里。构建系统是软件开发的重要组成部分，生产环境中的绝大多数软件都由多个组件所组成，由一系列依赖和分散的编译单元聚合而成，而自动化这些组件的集成的系统，就是构建系统。笼统地说，构建系统负责除了应用代码编写以外的，所有从代码到可执行文件的步骤的自动化。其中，查找、编译和链接等具体执行由其他工具支持。构建系统本身处理的内容分为两大部分，第一部分是构建过程各个步骤的编排，第二部分是包管理或说第三方依赖管理。这两者的区别可以参考

如何吸引开源开发人员参与项目？如何让他们留下来，成为项目共同体的一部分？这是两个做开源运营必须回答的问题。我对这两个问题的回答，简而言之是和开源参与者共同创造价值，使得开源项目和开源共同体能够回答潜在参与者的两个事关去留的灵魂提问。1.我能为你做什么？2.我应该怎么做到？从共同创造价值的角度出发，通过开源运营回答参与者可以做什么的问题，只有可做的事情是令人兴奋的价值创造，才有可能触发潜在的参与者的兴趣。进一步，只有潜在的参与者能够在文档材料与其他成员的帮助下共同完成价值创造，这样的正向激励才能让参与者留下来，成为项目共同体的一部分。本文内容部分整理自我在开源社举办的

开源正在掀起一轮新的浪潮。如今的基础软件创业公司，或多或少面临同类开源软件的隐性竞争，以至于当公司想要制造一个新的软件或解决方案的时候，总躲不开“代码是否开源”这个问题。可以说，现在的基础软件如果不开放源代码，那么它的竞争力就会大打折扣。在这样的背景下，几乎每一个项目创始人都不得不思考一个问题，既然代码必须要开放，那么选择哪种开源许可证能够满足我的需要呢？文章合为时而著。本文就立足于这样的背景，讲一讲开源许可证的选择。首先声明本文内容没有作为法律依据的效力，仅为个人观点。其中提到的许可证也并非全是开源许可证，包括部分仅与开放源代码有相关性的许可证。选择开源许可证的意义运行一个开源项目，建设一个开源共同体，包括很多方面的工作。但是如果你问我从哪里开始，除了产生核心价值的软件以外，我会说最重要的是确定项目采用的开源许可证。不同的开源许可证给开源共同体带来不同的保证。选择一份开源许可证，集中表达了项目创始人对开源的认识，以及其所认同的开源理念。开源共同体的调性深刻地影响到此后每一个阶段的发展，也包括如何基于开源软件创造商业价值。关于这一点，我经常引用

peers），也就是说成员的角色与个体相关，而不是与他在某个组织的职位相关，在这种情况下依然把委员会的人员增加与企业员工入离职挂钩，这种组织形式就是非常危险的。具体地说，部分项目照猫画虎地搬来了

然而，其中大部分项目由于成员背景的单一性，最终都终结于仅源码可得的形态。对于这些新兴项目来说，初始成员从属于同一企业是既定事实。在这样的前提下，企业应该如何实践开源协同，形成开源共同体呢？

本文重新发布了如何高效利用有限的时间参与开源社区的两篇文章，修复了大量影响阅读的措辞。大部分人参与开源社区会面临的一个巨大挑战，那就是缺乏时间。本文试图提供一种方式，帮助想要参与开源社区的同学高效利用有限的时间。在一个开源社区里，maintainers

每个开源社区都会有独特的做事的调性，这种调性往往是从最初的维护者群体的个人喜好生长出来，在与参与者的双向选择和磨合当中演进的。参与者的做事方式与社区的调性相符，维护者需要的沟通成本将会显著降低。