夜天之书

Git 版本管理系统由 Linux 的作者 Linus Torvalds 于 2005 年创造，至今不到二十年。

起初，Git 用于 Linux Kernel 的协同开发，用于替代不再提供免费许可的 BitKeeper 软件。随后，这一提供轻量级分支的分布式版本管理系统得到了开源开发者的广泛喜爱，在大量开源项目中投入使用。如今，Git 几乎是版本管理系统的同义词。

Git 最大的创新就是轻量级的分支实现，鼓励分布式的开发者群体创建自己的分支。每个分支都是平等的，只是原始作者的分支或者实现最好的分支会被社群公认为上游，其他分支被认为是下游。下游分支的修改通过邮件列表发送补丁或 GitHub 发起 Pull Request 的方式向上游申请合并，最后大部分用户从上游分支取得源代码使用。

在这个模型下，如何协同不同分支的开发，当上游发布了多个版本，尤其是并行维护多个发布版本时，如何管理分支，就是一个亟需解决的问题。Git 自身的设计不解决这个问题，也不对此做建模。它只提供分支创建和合并等基本功能，而把具体的分支管理策略留给开源软件的开发者。

上一篇文章《Web API 简介》的落脚点是 Web API 的体验。

Web API 作为许多软件的第一道门面，提升其体验的努力从来没有停止过。今天，围绕 Web API 的开发体验和使用体验，已经成长出一个庞大的软件生态。本文以常用的 Web API 开发工具和平台为切入点，介绍当前 Web API 的开发者基础设施。

Application Programming Interface (API) 即应用程序接口。顾名思义，它是开发者访问应用程序的接口。

例如，你可以通过以下命令查询 GitHub 上特定代码仓库的元数据信息：

1

curl https://api.github.com/repos/apache/pulsar

GitHub 会返回以下信息：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

{
  "id": 62117812,
  "name": "pulsar",
  "full_name": "apache/pulsar",
  "private": false,
  "size": 185304,
  "stargazers_count": 12577,
  "watchers_count": 12577,
  "language": "Java",
  "visibility": "public",
  "forks": 3269,
  "open_issues": 1197,
  "watchers": 12577,
  "default_branch": "master",
  // ...
}

本轮开源之风吹起迄今数年，最大的影响还是越来越多的商业公司开始探索开源方法能够如何改变自己的经营策略。

开源策略循序渐进分成使用、参与和发起。在发起开源项目实践一线的，一个是打着开源旗号的创业公司，另一个就是大型企业尤其互联网企业（大厂）。

前者我在过去的文章里已经详细讨论了他们的动机、面临的风险和应对策略。

本文将关注大厂发起的开源项目的共同特点，讨论围绕这样的开源项目聚拢起来的企业研发团队、市场运营团队、用户开发者之间常见的认知失配问题。值得说明的是，这些问题虽然是大厂开源常见的问题，却不是大厂开源独有的问题，对其他开源项目的建设也有参考意义。

本文从软件系统、学术论文和出版书籍三个方面介绍研究学习类似 Apache Flink 的流式系统的参考材料。

3 月 31 日，马斯克如约开源了一系列推特推荐算法代码。

前几天，一篇名为《开源商业模式是个伪命题》的文章横空出世，看似犀利的观点却没有引起激烈的反驳。无论是开发专有软件的企业，还是重度投入到开源软件开发的企业，都认同开源本身并不是企业作为软件及服务提供商的商业模式。

行业当中有这样的共识并不奇怪。如果你在国际互联网上搜索『开源商业模式』关键字，其结果从 2016 年起就几乎被『开源不是商业模式』所统治。本文老调重弹，从开源为什么不是商业模式，不是商业模式的开源在企业运作中扮演什么角色，以及围绕开源软件存在哪些商业模式做出讨论。

今天，在许多开源软件项目乃至任何稍带开放性的项目的宣传中，我们经常能看到营销内容包含“共建”的字样，似乎说了这个魔法的词汇，项目就能迎接纷至沓来的“共建者”，其乐融融地“一起做大蛋糕”。

然而，现实情况却是作为被营销对象的开发者日渐对这个词失去兴趣到产生反感。一眼看到某个项目营销言必称“共建”，心里就默默给它扣分拉黑甚至拉黑。共建的神话是如何产生的，为什么这个口号今天不能吸引和凝聚开发者呢？

Community of Peers 可以翻译成『同侪社群』，意即社群由地位相同的成员组成，这是 Apache 软件基金会（ASF）的开源理念之一。

ASF 强调个体组成社群，每个成员代表他们自己而不是其所属的组织。不管成员是否受雇参与贡献，社群视角下他们都是一视同仁的志愿者。尽管只有 Committer 才有合并代码的权限，只有项目管理委员会（PMC）成员才能对项目的关键决议投有效票，但是除此以外，成员内部是真正平等的。ASF 的开源项目不存在『仁慈的独裁者』，项目管理委员会主席（PMC Chair）也只是承担代表项目向董事会报告的职责，而不意味着其他独特的权限。

这样的理念非常符合传统文化所推崇的『和而不同』与『周而不比』。理解这一点，能够帮助我们在参与认同『同侪社群』理念的开源社群的时候如鱼得水；相反，如果一味追求『和光同尘』，或者把等级观念带到这些社群当中，则容易寸步难行。

上周末在给 Apache Ratis 的代码库上 Maven Wrapper 的时候，项目作者 @szetszwo 对 Pull Request (PR) 当中代码的合规问题和实现问题提出了一些问题。虽然这些问题并不难回答，但是我第一时间的反应却是“这么明显的答案，实在是懒得回复”。进而我又想到，如果是线下集中办公或者面对面 workshop 的情形，这些问题不到五分钟就能讨论清楚，而这两类不同环境当中开发者的表现差异，正好是接触和适应远程工作与开源协同的一个门槛。由此，我想讨论一下远程工作、开源协同与饱和沟通的问题。