夜天之书

春节在家整理存书，发现了当时在拼多多做业务开发工作的时候，用来帮助理解互联网企业服务架构的若干书籍。这些书里的技术方案可能有一定的落后，但是对于帮助新入职场的互联网公司程序员，了解一个典型的互联网企业核心服务架构，以及治理服务和分化出数据团队的过程里会发生的技术服务体系变化，还是很有帮助的。这里做一个分享。

自由软件运动已经发展了近四十年。从最初的 GNU 工具集，到 Linux 操作系统，再到 OpenJDK 和 Telegram 等软件，使用 GNU GPL 系列许可证的自由软件在许多领域当中发挥了关键乃至不可提到的作用。

然而，GPL 系列许可证本身，尤其是 3.0 版本经由律师之手重新修订发布以后，其内容已经很难为开发者所理解。尤其是具体条款的拟定背景，GPL 系列许可证不同的版本的区别机器动机，单从条款本身去分析，很容易让人摸不清头脑。

其实，贯穿 GPL 系列许可证的理念，是每个版本都包含或隐式包含的讨论软件自由的序章。自由软件运动的发起人 Richard Stallman 正是出于对软件自由的追求，才撰写了 GNU 通用公共许可证（General Public License, GPL）。从软件自由的角度出发，我们才能更好地理解自由软件运动的目标，以及 GPL 系列许可证条款的意义。

前段时间，我出于兴趣试着做了一个需要登录鉴权才能访问的个人网站，最终以 Docusaurus 为内容框架，Next.js 做中间件，Vercel 托管网站，再加上 Auth0 作为鉴权解决方案，实现了一个基本免费的方案。这里做一个分享。

开源软件和自由软件的概念与其许可证紧密绑定。

通常，开源软件被定义为使用 OSI 认可的，即符合开源定义的许可证来分发的软件，而自由软件被定义成使用 GPL 或说 Copyleft 式许可证分发的软件。

尽管今天人们最关心的可能是软件的生产过程即如何进行开源协同，但是为软件选择什么样的许可证，仍然是一个项目启动时必须考虑和决定的问题。某种意义上说，软件可以被如何使用和分发，反过来约束了可能实现的协同模式。

GitHub 维护了 ChooseALicense.com 网站以准确、中立地提供常用开源许可证的介绍，并指引开发者为他们的项目选择合适的许可证。不过，这个页面并没有针对企业开源的情形做出针对性的讨论。

本文从企业开源的场景出发，讨论选择不同开源许可证或源码可得的软件许可证，对企业和项目的影响，并给出主观的建议。

本文成文于 2019 年。最近 Apache StreamPark (Incubating) 项目要做第一个 Apache 版本的发布，遇到了类似的发布多 Scala 支持版本时如何正确生成对应 POM 文件，又尽可能复用流水线的问题。由于过往发布记录都被删除，故重新发布。

近日在阅读 FLINK 代码时发现 FLINK 有一个 force-shading 模块，关于这个模块的作用注释在其使用点 maven-shade-plugin 的配置中是这样写的

现在这个模块已经移动到 flink-shaded 仓库下，详见 pom.xml 文件。

1
2
3
4
5
6
7
8
9
10
11

<artifactSet>
  <includes>
    <!-- Unfortunately, the next line is necessary for now to force the execution
         of the Shade plugin upon all sub modules. This will generate effective poms,
         i.e. poms which do not contain properties which are derived from this root pom.
         In particular, the Scala version properties are defined in the root pom and without
         shading, the root pom would have to be Scala suffixed and thereby all other modules.
         -->
    <include>org.apache.flink:force-shading</include>
  </includes>
</artifactSet>

从注释中我们可以看到 force-shading 的作用是强制触发 maven-shade-plugin 的执行，并且提到了这样会生成所谓的 effective pom 文件。这究竟是怎么一回事呢？我们先从一个实例中理解这个问题。

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

众所周知，开源软件许可证粗略分为 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) 也就是开发者体验的基础设施。