我们为什么要编纂历史？
早在今年初，适兕就建立了「开源之史」讨论小组，旨在探讨有关技术、人物、思想、文化等开源世界发生过的事件和演化。
一开始，我对这个小组保持观望态度，既期待能够从中了解一些或许自己还不知道的历史，又对历史研究抱有一定的怀疑。一直以来，我都推崇关注现在，解决实际问题，研究历史尤其是尚未有定论也没有“信史”的“开源之史”，到底有多大的作用，我并不确定。但是，近日来发生的一些事情，让我重新考虑“历史”的价值，也对标题提出的“我们为什么要编纂历史”这个问题有了新的理解。
CMake 是怎么工作的？
关于开源软件的发布相关的内容还在构思当中，先摆烂重发部分以前讨论过的关于构建系统的文章。构建和发布密不可分，可以认为都是持续交付流水线的一环。
我会分多篇文章讨论软件发布和开源软件发布的各个方面，文章内容再加以提炼放到编撰当中的《开源指南》里。
构建系统是软件开发的重要组成部分，生产环境中的绝大多数软件都由多个组件所组成，由一系列依赖和分散的编译单元聚合而成，而自动化这些组件的集成的系统，就是构建系统。
笼统地说，构建系统负责除了应用代码编写以外的，所有从代码到可执行文件的步骤的自动化。其中，查找、编译和链接等具体执行由其他工具支持。构建系统本身处理的内容分为两大部分，第一部分是构建过程各个步骤的编排，第二部分是包管理或说第三方依赖管理。这两者的区别可以参考 Java 生态中 Ant 和 Ivy 的区别和联系。狭义的构建系统仅包括第一部分，因为狭义的构建过程只关心有某种方法可以取得依赖并将其引入构建，而不关心依赖本身是怎么管理和获取的。
那么，本文主角 CMake 是哪一种或者两者都是呢？
开源社群需要什么代码贡献？
几天前 @Xuanwo 的一篇文章《开源运营当论迹不论心》讨论了 TDengine 代码灭虫计划活动中不尊重开源协同的规律，只是通过市场运营手段强行把开发者推进来的误区。
本文从这个例子出发，进一步举例讨论开源社群需要什么样的代码贡献。
Apache 开源社群的经验
大约二十年前我刚开始进入互联网的世界的时候，支撑起整个网络的基础设施，就包括了 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 的理念，以及这些理念是如何落实到基金会组织、项目组织以及每一个参与者的日常生活事务当中的。
Protobuf Gradle Plugin 的用例
近日尝试利用 Apache Ratis 这个项目包装一个 Raft 协议驱动的状态机的时候，遇到了需要用 Protobuf 传输数据的场景。由于 Gradle 构建工具的门槛和 Java 语言项目的某些惯例碰到了使用上的问题，这里记录一下我在这个玩具项目当中的用例。
共同创造价值
如何吸引开源开发人员参与项目？如何让他们留下来，成为项目共同体的一部分？这是两个做开源运营必须回答的问题。
我对这两个问题的回答，简而言之是和开源参与者共同创造价值，使得开源项目和开源共同体能够回答潜在参与者的两个事关去留的灵魂提问。
- 我能为你做什么？
- 我应该怎么做到？
从共同创造价值的角度出发，通过开源运营回答参与者可以做什么的问题，只有可做的事情是令人兴奋的价值创造，才有可能触发潜在的参与者的兴趣。进一步，只有潜在的参与者能够在文档材料与其他成员的帮助下共同完成价值创造，这样的正向激励才能让参与者留下来，成为项目共同体的一部分。
开源共同体的治理模型
随着越来越多新的要素进入开源领域，如何建立一个高效的开源共同体，如何维护一个富有价值的开源共同体，逐渐成为每个参与者或多或少关注的问题。
Apache 软件基金会为每个项目提供了基础的治理原则，并在项目孵化到顶级项目的过程中通过孵化器导师的帮助建立起开源项目的治理模型，但是这一模型对每个具体项目在特定时期未必是最优的。同时，其他不在 Apache 软件基金会治理的项目，虽然拥有灵活设计治理模型的自由，却也时常陷入不知道该如何开始的窘境。
本文从开源治理的目的出发，介绍一个开源共同体什么时候需要考虑设计治理模型，然后讨论开源治理的原则，结合实例分析如何设计开源共同体的治理模型。这里所说的开源共同体，主要指的是围绕单一项目或单一主题项目群形成的开源共同体。
《大教堂与集市》书评
历时五天，我总算把《大教堂与集市》这本经典的开源文化著作认真读了一遍，真是酣畅淋漓。
本书是作者 Eric S. Raymond 的文集，其中最著名的一篇就是《大教堂与集市》，其他几篇分别是《黑客圈简史》《开垦心智层》《魔法锅》和《黑客的反击》。最有价值的是《大教堂与集市》和《开垦心智层》两章，系统解释了开源软件是如何生产的，开源开发的优势在哪，开源软件的传承是如何做到的。《魔法锅》解答了一些常见的关于开源软件使用价值和销售价值的问题，但是受限于时代背景，对商业化的讨论局限在夸大使用价值的部分，不能很好的指导基于开源软件提供软件服务的商业模式。
在进入具体的内容讨论之前，必须着重提到译者卫剑钒对中译本创造的价值。翻译是对原内容的二次创作，软件开发领域外文著作众多，大部分译本都让原文表意有明显的损失。卫剑钒翻译的《大教堂与集市》，阮一峰翻译的《黑客与画家》，以及云风翻译的《程序员修炼之道（第二版）》是我近一年来读过的本领域最佳译作。