夜天之书

开源社群虽然是围绕开源软件建立起来的，但是建设繁荣的开源生态，依靠只读的源代码是不够的。建设繁荣的开源生态需要开源协同，而协同的基础是沟通。沟通不仅有论坛和聊天室的交互式形式，还有主动的内容生产和发布，包括不同受众的文档的撰写和翻译，以及技术文章的传播等等。这些内容创造都可以归类为技术写作，也就是说，围绕开源软件的技术写作，是建设繁荣的开源生态的重要一环。

本文尝试讨论这些不同类型的技术写作在现实当中被采纳和运用的情况，以及它们相应的价值。

《开源之迷》是“开源之道”主创适兕所著“开源之道三部曲”的第一部。本书的“迷”是着迷的“迷”，旨在向读者介绍什么是开源，以及开源令人欲罢不能的优势。适兕在《适兕是如何生存的？》提到，自己从 2015 开始运行“开源之道”，2018 年辞去全职工作，一心发展开源之道。开源之迷，一至于此。

本书发售前，我曾经应邀写了一小段推荐词，不过最后因为出版的原因没有随书印刷。这里附上原文内容，也可以对比只读样章跟读完全书以后体感的差别。

适兕老师将他多年关注、学习和参与开源世界的理解灌注在开源之道三部曲当中。这本《开源之谜》里，我最期待的内容莫过于“在所有人看见的地方工作”。这一章的名字取自适兕老师推荐的三十多本开源之书其中一本，开源运动之所以冠上这个名字，就有强调源代码及其研发协作活动的公开性的原因。如果你想知道开源协同为什么是软件开发模式的必然方向，开源协同的价值和做法，阅读这本《开源之谜》一定不会错。

早在今年初，适兕就建立了「开源之史」讨论小组，旨在探讨有关技术、人物、思想、文化等开源世界发生过的事件和演化。

一开始，我对这个小组保持观望态度，既期待能够从中了解一些或许自己还不知道的历史，又对历史研究抱有一定的怀疑。一直以来，我都推崇关注现在，解决实际问题，研究历史尤其是尚未有定论也没有“信史”的“开源之史”，到底有多大的作用，我并不确定。但是，近日来发生的一些事情，让我重新考虑“历史”的价值，也对标题提出的“我们为什么要编纂历史”这个问题有了新的理解。

关于开源软件的发布相关的内容还在构思当中，先摆烂重发部分以前讨论过的关于构建系统的文章。构建和发布密不可分，可以认为都是持续交付流水线的一环。

我会分多篇文章讨论软件发布和开源软件发布的各个方面，文章内容再加以提炼放到编撰当中的《开源指南》里。

构建系统是软件开发的重要组成部分，生产环境中的绝大多数软件都由多个组件所组成，由一系列依赖和分散的编译单元聚合而成，而自动化这些组件的集成的系统，就是构建系统。

笼统地说，构建系统负责除了应用代码编写以外的，所有从代码到可执行文件的步骤的自动化。其中，查找、编译和链接等具体执行由其他工具支持。构建系统本身处理的内容分为两大部分，第一部分是构建过程各个步骤的编排，第二部分是包管理或说第三方依赖管理。这两者的区别可以参考 Java 生态中 Ant 和 Ivy 的区别和联系。狭义的构建系统仅包括第一部分，因为狭义的构建过程只关心有某种方法可以取得依赖并将其引入构建，而不关心依赖本身是怎么管理和获取的。

那么，本文主角 CMake 是哪一种或者两者都是呢？

几天前 @Xuanwo 的一篇文章《开源运营当论迹不论心》讨论了 TDengine 代码灭虫计划活动中不尊重开源协同的规律，只是通过市场运营手段强行把开发者推进来的误区。

本文从这个例子出发，进一步举例讨论开源社群需要什么样的代码贡献。

大约二十年前我刚开始进入互联网的世界的时候，支撑起整个网络的基础设施，就包括了 Apache 软件基金会（ASF）治下的软件。

Apache Httpd 是开启这个故事的软件，巅峰时期有超过七成的市场占有率，即使是在今天 NGINX 等新技术蓬勃发展的时代，也有三成左右的市场占有率。由 Linux、Apache Httpd、MySQL 和 PHP 组成的 LAMP 技术栈，是开源吞噬软件应用的第一场大型胜利。

我从 2018 年参与 Apache Flink 开始正式直接接触到成立于 1999 年，如今已经有二十年以上历史的 Apache 软件基金会，并在一年后的 2019 年成为 Apache Flink 项目 Committer 队伍的一员，2020 年成为 Apache Curator 项目 PMC（项目管理委员会）的一员。今年，经由姜宁老师推荐，成为了 Apache Members 之一，也就是 Apache 软件基金会层面的正式成员。

我想系统性地做一个开源案例库已经很久了。无论怎么分类筛选优秀的开源共同体，The Apache Community 都是无法绕开的。然而，拥有三百余个开源软件项目的 Apache 软件基金会，并不是一篇文章就能讲清楚的案例。本文也没有打算写成一篇长文顾及方方面面，而是启发于自己的新角色，回顾过去近五年在 Apache Community 当中的经历和体验，简单讨论 Apache 的理念，以及这些理念是如何落实到基金会组织、项目组织以及每一个参与者的日常生活事务当中的。

近日尝试利用 Apache Ratis 这个项目包装一个 Raft 协议驱动的状态机的时候，遇到了需要用 Protobuf 传输数据的场景。由于 Gradle 构建工具的门槛和 Java 语言项目的某些惯例碰到了使用上的问题，这里记录一下我在这个玩具项目当中的用例。

时隔两年，以姜宁老师的分享为契机，我重读了《知识社群》一书。结合这两年在开源社群方向的经验，我从中发现了不少极具实践价值的内容。

《知识社群》一书从知识社群的社会性出发，从知识社群的历史沿革，全球知识经济的发展进程，以及知识社群在知识时代的机遇三点立论，阐述了知识社群的时代价值。进一步地，本书介绍了知识社群的三个结构要素，划分了知识社群发展的五个阶段，归纳了知识社群培养的七个原则。本书对知识社群的定义如下。

知识社群是这样一群人，他们有共同的关注点、同样的问题或者对同一个话题的热情，通过在不断发展的基础上相互影响，深化某一领域的知识和专业技术。

如何吸引开源开发人员参与项目？如何让他们留下来，成为项目共同体的一部分？这是两个做开源运营必须回答的问题。

我对这两个问题的回答，简而言之是和开源参与者共同创造价值，使得开源项目和开源共同体能够回答潜在参与者的两个事关去留的灵魂提问。

1. 我能为你做什么？
2. 我应该怎么做到？

从共同创造价值的角度出发，通过开源运营回答参与者可以做什么的问题，只有可做的事情是令人兴奋的价值创造，才有可能触发潜在的参与者的兴趣。进一步，只有潜在的参与者能够在文档材料与其他成员的帮助下共同完成价值创造，这样的正向激励才能让参与者留下来，成为项目共同体的一部分。

随着越来越多新的要素进入开源领域，如何建立一个高效的开源共同体，如何维护一个富有价值的开源共同体，逐渐成为每个参与者或多或少关注的问题。

Apache 软件基金会为每个项目提供了基础的治理原则，并在项目孵化到顶级项目的过程中通过孵化器导师的帮助建立起开源项目的治理模型，但是这一模型对每个具体项目在特定时期未必是最优的。同时，其他不在 Apache 软件基金会治理的项目，虽然拥有灵活设计治理模型的自由，却也时常陷入不知道该如何开始的窘境。

本文从开源治理的目的出发，介绍一个开源共同体什么时候需要考虑设计治理模型，然后讨论开源治理的原则，结合实例分析如何设计开源共同体的治理模型。这里所说的开源共同体，主要指的是围绕单一项目或单一主题项目群形成的开源共同体。