开源软件不是凭空出现的，开发开源软件是一项艰苦卓绝的工作。每个开源软件的背后少则有原作者一人的投入，多则协同了成千上万人组成的开源社群的共同努力。然而，开源软件的源代码总是免费可得，并且开源软件协议总是不限制用户的使用形式。
基于开源软件完成工作乃至搭建业务盈利的用户，并不总是参与软件开发的人，这种形似经济学中“搭便车”的行为，在国内被提及的时候总会被称为“白嫖”，以至于后者称为圈内的一个热词。那么，开源世界当中到底存不存在“白嫖”，不同角色眼中的“搭便车”行为到底是怎么样的？本文将对此做些讨论。
《程序员修炼之道》讲了一个有趣的“石头汤”寓言。这个寓言里，饿着肚子的外来人在村子里烧了一锅水，放了三块石头，开始煮“石头汤”。这样的行为引来好奇的村民围观，外来人顺势在“石头汤”的基础上引导村民们添加食材以改善这锅料理。最后，村民和外来人一起煮出了一锅靓汤，外来人于是把石头从汤里扔掉，所有人分享了这顿美餐。
开源协同的工作方式与制作“石头汤”的方式有些相似。开源社群的核心成员与寓言中的外来人一样，充当了催化剂的角色，将这些各自拥有不同背景的人群组织起来。这样，社群成员才能聚在一起做出他们单独无法做到的事情。最后，所有人都是赢家。
当然，在这个版本的“石头汤”寓言里，村民被外来人骗了，石头并没有为最终的美味产生直接价值。《开放式组织》指出这种行为是一次性的，并且价值仅仅单向地从村民一方流向外来人一方，以至于它被冠以“汤姆·索亚合作模式”的恶名。
开源协同的模式保留了“石头汤”寓言当中催化剂的内核，但是这一次，外来人提供的不是水煮石头，而是初具规模的汤底和食材。《大教堂与集市》在揭示集市模式的必要条件时阐述了这一点，这个隐喻意味着一个能运行的软件，并且让潜在的合作开发者相信，这个软件在可以预见的未来，能够演变成一个非常棒的东西。
Apache 开源社群由三百多个项目组成，其中不乏开源版本“石头汤”的现实案例。
从本世纪初谷歌的三篇论文发布以来，数据处理领域在大数据的方向上探索了将近二十年的时间。从三篇论文的开源实现 Apache Hadoop 和 Apache HBase 开始，到打破传统关系型数据库的分布式数据处理系统如雨后春笋般接连诞生，NoSQL 系统回应了移动互联时代的数据爆发式增长的挑战。
诚然，传统的数据库专家对 NoSQL 也有像 MapReduce: A major step backwards 这样的批评，不过 NoSQL 系统本身也在向传统数据处理领域当中被证明有效的特性靠拢，向 Not Only SQL 系统转变。
本文首先从移动互联时代数据增长和数据模型演进带来的实际问题出发，讨论 NoSQL 系统在现在企业数据处理生态当中的定位和价值，然后介绍 NoSQL 系统靠近 Not Only SQL 定位的过程中遇到的硬核诉求，最后分析新时代 NoSQL 的发展方向。
近日在《大教堂与集市》的译者卫剑钒的推荐下阅读了这本被评价为新时代《穷查理宝典》的《纳瓦尔宝典》，其中有部分观点确实很有启发。卫 Sir 给这本《纳瓦尔宝典》专门写了两篇书评，已经把书中的精华几乎都介绍完全了。我在这里出于自己的理解和感悟，做一点微小的补充。
随着开源软件全面占据软件供应链的各个阶段，商业公司开发基础软件或业务逻辑的时候，已经避不开对软件的使用了。经过一段时间对开源软件的使用，以及开源吞噬软件的趋势影响，研发能力突出的公司或团队，也会加入到开发开源软件的行列中来。
商业模型当中开源软件位置的不同，体现出企业实践开源动机的不同，并且会很大程度影响企业实践开源的行为。本文将讨论不同商业模型下，企业实践开源的动机和行为的差异。
《大教堂与集市》中有一个著名的 Linus 定律，“只要眼睛多，bug 容易捉”。在这本书里面，作者讨论了开源社群的集市开发模式，以其开放的特征，以及提供源码从而支持参与者基于相同的真实的源码进行高效交流，驯服了大型软件开发的复杂性。诚然，在其论述中，基于源码的，快速发布反馈缺陷报告和补丁修补的开源协同方式，能够制造出 Linux 这样的大型开源软件。然而，这一论述却有一个隐含的前提假设，那就是开源软件得到了足够多的关注。
Linux 无疑得到了全世界开发者的海量关注，并且一直如此。开源运动的启蒙阶段，大量的软件都被开创式的制造出来，彼时少有其他开源竞争者的存在，因此眼球或者叫注意力能够投放到的目标是相对有限的。另一方面，开源社群彼时仍是小众圈子，天然地对进入其中的注意力有一个质量筛选的机制，除非货真价实的黑客，否则很难在当时的开源社群当中生存。
然而，如今的开源软件从覆盖面到数量上已经彻底超出了所有人的预期，在软件渗透到社会生活的方方面面的前提下，形成了几乎任何软件都包含开源组件的“软件吞噬世界，开源吞噬软件”的格局。越来越多的开源参与者，已经观察到“眼球不够用”的情况了。换句话说，整个开源共同体的注意力供给总量，不足以应对所有开源软件高效发展的需求。
在这样的前提下，开源社群的参与者，应该考虑如何分配自己宝贵的注意力，以促进自身利益与开源社群发展需要的双赢；开源社群的维护者或说开源软件的作者，还需要额外考虑如何吸引开源参与者乃至整个社会可能提供的注意力，从而维系开源软件的高质量，并放大高质量开源软件的影响力。本文将从开源共同体具体的案例出发，讨论这两个问题。
开源社群虽然是围绕开源软件建立起来的，但是建设繁荣的开源生态，依靠只读的源代码是不够的。建设繁荣的开源生态需要开源协同，而协同的基础是沟通。沟通不仅有论坛和聊天室的交互式形式，还有主动的内容生产和发布，包括不同受众的文档的撰写和翻译，以及技术文章的传播等等。这些内容创造都可以归类为技术写作，也就是说，围绕开源软件的技术写作，是建设繁荣的开源生态的重要一环。
本文尝试讨论这些不同类型的技术写作在现实当中被采纳和运用的情况，以及它们相应的价值。
《开源之迷》是“开源之道”主创适兕所著“开源之道三部曲”的第一部。本书的“迷”是着迷的“迷”，旨在向读者介绍什么是开源，以及开源令人欲罢不能的优势。适兕在《适兕是如何生存的？》提到，自己从 2015 开始运行“开源之道”，2018 年辞去全职工作，一心发展开源之道。开源之迷，一至于此。
本书发售前，我曾经应邀写了一小段推荐词，不过最后因为出版的原因没有随书印刷。这里附上原文内容，也可以对比只读样章跟读完全书以后体感的差别。
适兕老师将他多年关注、学习和参与开源世界的理解灌注在开源之道三部曲当中。这本《开源之谜》里，我最期待的内容莫过于“在所有人看见的地方工作”。这一章的名字取自适兕老师推荐的三十多本开源之书其中一本，开源运动之所以冠上这个名字，就有强调源代码及其研发协作活动的公开性的原因。如果你想知道开源协同为什么是软件开发模式的必然方向，开源协同的价值和做法，阅读这本《开源之谜》一定不会错。
关于开源软件的发布相关的内容还在构思当中，先摆烂重发部分以前讨论过的关于构建系统的文章。构建和发布密不可分，可以认为都是持续交付流水线的一环。
我会分多篇文章讨论软件发布和开源软件发布的各个方面，文章内容再加以提炼放到编撰当中的《开源指南》里。
构建系统是软件开发的重要组成部分，生产环境中的绝大多数软件都由多个组件所组成，由一系列依赖和分散的编译单元聚合而成，而自动化这些组件的集成的系统，就是构建系统。
笼统地说，构建系统负责除了应用代码编写以外的，所有从代码到可执行文件的步骤的自动化。其中，查找、编译和链接等具体执行由其他工具支持。构建系统本身处理的内容分为两大部分，第一部分是构建过程各个步骤的编排，第二部分是包管理或说第三方依赖管理。这两者的区别可以参考 Java 生态中 Ant 和 Ivy 的区别和联系。狭义的构建系统仅包括第一部分，因为狭义的构建过程只关心有某种方法可以取得依赖并将其引入构建，而不关心依赖本身是怎么管理和获取的。
那么，本文主角 CMake 是哪一种或者两者都是呢？