夜天之书

本文整理自第七届中国开源年会开源码力圆桌：十字路口，代码是我们永恒的信仰上我的发言。

众所周知，开源软件许可证粗略分为 Copyleft 类和 Permissive 类。

这两者常被提及的不同之处，是前者要求对软件的修改和派生仍需以相同条款发布，而后者允许修改软件和派生软件不再发布源代码。

不过，如果我们从两者相同的要求出发，重新看待开源共同体的成员对作为契约的开源许可证的认识，就会有崭新的发现：无论是 Copyleft 类的许可证，还是 Permissive 类的许可证，都没有授予接收方使用软件商标的权利。

特别地，BSD 3-Clause 和 Apache License 2.0 明确限制了接收方使用软件商标（名称）为自己站台的权利，GPLv3 则在附加条款中允许许可方补充限制接收方使用商标的权利。

简言之，商标是被保留的，与发布软件和上游作者绑定的，而不是公共的，任何人可以随意使用的。

那么，为什么开源许可证在允许接受方任意使用、修改、复制和重分发软件的情况下，对商标却采取截然不同的保留态度呢？

过去两年间，我全职参与了多个开源项目的社群建设工作，逐渐形成了自己开展社群建设工作的知识体系，并将其发布在开源小镇网站上。

这个过程里，阅读开源主题的书籍对我借鉴成功经验、警惕历史教训和形成分析问题的框架起到了至关重要的作用。这几天频繁切换工作地点，总有几本开源之书不管到哪我都要随身携带，这里做一个推荐。

开源社群可以通过开展广泛的开源协同来规模化开发软件的生产力。为了实现提升生产力的目标，一般而言需要解决两个阶段的问题：第一个阶段是如何找到适合的潜在开发者人群，吸引他们参与软件开发和社群建设；第二个阶段是社群的原始生产力上来以后，应对项目复杂度和沟通成本随人员规模平方级别增长的难题。

第一阶段的解决方案在《共同创造价值》当中有过相关讨论，第二阶段的问题可以通过工作的模块化和 Review 质量的提升来解决。本文即聚焦在开源协同当中的 Code Review 应该秉承什么原则，做到什么程度，如何避免常见问题来展开。

本文演绎自 Kenneth Auchenberg 的 Developer Experience Infrastructure (DXI) 博客。

原文提到，现在大部分号称以开发者优先为理念建设基础设施的公司，对开发者体验的定义和落地都不是最佳实践。原文作者认为，随着业界对开发者体验的重视和发展，将会出现一个新的领域 Developer Experience Infrastructure (DXI) 也就是开发者体验的基础设施。

上周开发报表的时候实现了一个 Spring Boot + Next.js 前后端代码分离，但是端口唯一的 WebApp 方案。这个方案既能利用好各自的生态，也能避免要起两个 server 占用两个端口的繁琐构建部署逻辑。

本文从选型到实现做一个分享，主要面向熟悉 Spring Boot 技术栈，又想跟进 React 系前端组件化方案的开发者。

开源软件的用户在使用过程中遇到问题时，几乎总是先在自己的环境上打补丁绕过或快速修复问题。开源协同的语境下，开源软件以及维护开源软件的社群统称为该软件的上游，用户依赖上游软件的应用或基于上游软件复刻（fork）的版本统称为下游。上游优先（Upstream First），指的就是用户将下游发现的问题、做出的修改反馈到上游社群的策略。

网络上已经有不少文章讨论上游优先的定义、意义和通用的做法。例如，小马哥为极狐 GitLab 撰写了《Upstream First: 参与贡献开源项目的正确方式》。不过，这些文章往往是站在社群、平台或布道师的层面做笼统的介绍。本文希望从一个开发者的角度出发，由几个具体的上游优先的故事，讨论开发者角度实践上游优先策略的动机和方法。

本文已整理到【开源小镇】网站【企业沙盘】文档，最新更新请前往对应页面阅读。

本文是我继《企业实践开源的动机》、《开源世界当中到底存不存在“白嫖”？》和《免费增值的商业模式》之后再一次讨论免费增值相关的软件商业模式。主要受到 Percona 发布的 Open Source Bait and Switch: Licensing and Beyond 一文的启发，让我意识到 MongoDB Inc. 在很长一段时间里采用 AGPL 的免费增值战略仍然在开源的范畴之内，直到这些公司陆续切换到专有软件许可证，才真正走上了伪开源战略的道路。

开源社群存在的目的，主要是制造高质量的开源软件，并促进该软件的使用。为了达到这两个目标，开源社群需要调动参与者的积极性，并且协同背景多样的参与者的贡献，共同修复软件缺陷、改善软件体验、增加软件功能、组织社群活动和发展软件生态。大多数开源社群的环境里，实际进行组织协调工作的成员，就是社群的维护者（Maintainer）。

不同开源社群对角色的定位和命名有着各自的风格。Vim 社群生态丰富，但是 Bram Moolenaar 是唯一的“仁慈的独裁者”。Kubernetes 制作了一套基于 SIG 划分的从 Reviewer 到 Appover 再到 Owner 的体系。Apache 基金会的每个项目都使用 Committer + Project Management Committee 的治理结构。Rust 和如今的 Linux 采用分模块的 Team Maintainer 模式。PostgreSQL 则由整个项目级别的 Core Team + Committer 来治理。

对于刚起步的开源项目而言，这些眼花缭乱的标准背后，其实是一个大致相同的对项目维护者的标准。对于想要深入参与开源社群的人来说，理解了项目维护者的标准，也就明白该做些什么以成为一名维护者了。本文主要对这个标准的不同层面进行讨论，顺带对比上面这些经过演变的不同版本。

越来越多的开源软件占领了各个领域依赖链条的关键环节，越来越多的程序员也以参与知名开源软件的开发为荣，将开源贡献和在开源社群当中获得的头衔作为简历当中浓墨重彩的一部分。

在这样的背景下，技术驱动型公司的 HR 也随之需要掌握从开源社群当中找到组织需要的人才的方法。如果企业的业务依托于开源软件的发展，甚至公司直接投入人力参与开源社群，那么 HR 还需要了解开源项目运作的基本流程。

我在最近三年间陆续遇到人力资源相关的从业者询问如何解决这两个问题。目前，大部分的开源项目代码都托管在 GitHub 平台上。本文从我接触到的问题出发，从 GitHub 提供的能力和 GitHub 上项目协作的常见形式入手，回答这两个问题。