《开源之迷》是“开源之道”主创适兕所著“开源之道三部曲”的第一部。本书的“迷”是着迷的“迷”，旨在向读者介绍什么是开源，以及开源令人欲罢不能的优势。适兕在《适兕是如何生存的？》提到，自己从 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 语言项目的某些惯例碰到了使用上的问题，这里记录一下我在这个玩具项目当中的用例。
如何吸引开源开发人员参与项目？如何让他们留下来，成为项目共同体的一部分？这是两个做开源运营必须回答的问题。
我对这两个问题的回答，简而言之是和开源参与者共同创造价值，使得开源项目和开源共同体能够回答潜在参与者的两个事关去留的灵魂提问。
从共同创造价值的角度出发，通过开源运营回答参与者可以做什么的问题，只有可做的事情是令人兴奋的价值创造，才有可能触发潜在的参与者的兴趣。进一步，只有潜在的参与者能够在文档材料与其他成员的帮助下共同完成价值创造，这样的正向激励才能让参与者留下来，成为项目共同体的一部分。
随着越来越多新的要素进入开源领域，如何建立一个高效的开源共同体，如何维护一个富有价值的开源共同体，逐渐成为每个参与者或多或少关注的问题。
Apache 软件基金会为每个项目提供了基础的治理原则，并在项目孵化到顶级项目的过程中通过孵化器导师的帮助建立起开源项目的治理模型，但是这一模型对每个具体项目在特定时期未必是最优的。同时，其他不在 Apache 软件基金会治理的项目，虽然拥有灵活设计治理模型的自由，却也时常陷入不知道该如何开始的窘境。
本文从开源治理的目的出发，介绍一个开源共同体什么时候需要考虑设计治理模型，然后讨论开源治理的原则，结合实例分析如何设计开源共同体的治理模型。这里所说的开源共同体，主要指的是围绕单一项目或单一主题项目群形成的开源共同体。
历时五天，我总算把《大教堂与集市》这本经典的开源文化著作认真读了一遍，真是酣畅淋漓。
本书是作者 Eric S. Raymond 的文集，其中最著名的一篇就是《大教堂与集市》，其他几篇分别是《黑客圈简史》《开垦心智层》《魔法锅》和《黑客的反击》。最有价值的是《大教堂与集市》和《开垦心智层》两章，系统解释了开源软件是如何生产的，开源开发的优势在哪，开源软件的传承是如何做到的。《魔法锅》解答了一些常见的关于开源软件使用价值和销售价值的问题，但是受限于时代背景，对商业化的讨论局限在夸大使用价值的部分，不能很好的指导基于开源软件提供软件服务的商业模式。
在进入具体的内容讨论之前，必须着重提到译者卫剑钒对中译本创造的价值。翻译是对原内容的二次创作，软件开发领域外文著作众多，大部分译本都让原文表意有明显的损失。卫剑钒翻译的《大教堂与集市》，阮一峰翻译的《黑客与画家》，以及云风翻译的《程序员修炼之道（第二版）》是我近一年来读过的本领域最佳译作。