去年十一月，我成为了 Apache Pulsar 社群 Committers 的一员。
成为 Committer 之前和之后，我都积极参与了代码仓库上 Issue 和 Pull Request (PR) 的处理回应和评审。去年十二月期间，我把未解决的 Issue 和 PR 数量分别从接近 2000 个和 400 个，在动态增长的情况下缩小到了小于 1000 个和接近 200 个。
关于如何高效地、分门别类地处理社群积压的议题和补丁，我可能会用另一篇文章来讨论。本文想讲的是在这个过程里我产生的另一个想法，那就是如何分析在这类过程中产生的活动，从而判断社群的健康情况呢？
我在《企业开源该选什么软件许可证？》一文当中，已经从软件许可证的角度讨论过不同协议对企业开源的意义。
不过，那篇文章主要是从许可证内容出发的，即先给定了协议，分析完协议细节，再判断是否符合企业和计划公开的软件的情形。本文从企业开源的不同诉求和风险出发，结合现存的企业组织实践，重新讨论源码公开第一步就要面临的选择软件协议问题应该如何决策。
首先说一下结论：最终我选择了基于 Arch Linux 的 Garuda Linux 发行版作为基础来搭建自己的 Linux 开发机。
燃烧了过去一周的空闲时间，我终于定制好了自己的 Linux Desktop 环境。
虽然 Linux 经常被拿来跟 Windows 和 Mac OS X 相比较，但是 Linux 本身只是一个操作系统内核，为了满足用户能作为日常桌面系统使用的需求，还需要添加很多额外的功能。例如，作为内核的 Linux 只提供了识别网卡与其通信的能力，具体如何建立和维护网络链接，如何在开机时自动连接，如何设置网络代理，不同于 Windows 和 Mac OS X 有成熟友好的图形管理界面，Linux 的用户是需要自己搭配定制的。同样，硬盘分区、格式化文件系统、设置引导程序、安装显卡驱动和配置输入法也是如此，需要 Linux 用户自行定制。
这种定制，还不是简单的只有一种办法实现，所有人都有一致的体验。由于 UNIX 哲学里的机制与策略分离，以及 Linux 生态中大量软件是自由软件的缘故，用户经常会发现“解决问题的办法不止一种”。甚至极端一些，“解决问题的框架”也不止一种。以输入法为例，Linux 生态的输入法框架至少包括 IBus 和 Fcitx5 两种。只有框架显然是不足以完整使用输入功能的，因此还需要有对应的输入法实现，输入法在不同的图形化界面（框架）下的集成，以及补充输入法能力的词库和其他支持。
这样的环境催生了 Linux 生态的两大特点。
其一是 Linux 生态中的软件往往是开放源码的。这不仅仅是 GNU/Linux 的出生带来的号召力，也是面对种类繁多的生态的最佳选择。例如，在其他桌面系统和手机系统上都广为人喜爱的搜狗输入法，在 Linux 生态当中只支持有信创动力加持的 Ubuntu 系列系统，且仅提供 deb 安装包和仅兼容 Fcitx 输入法框架。在 Ubuntu 上游试图把默认输入法框架从 Fcitx 改成 Fcitx5 的时候，搜狗一家公司没有人力支持，也未开源代码允许社群支持，最终一再拖延上游的更新计划。反观开放源码的 Rime 输入法，则在第一时间得到社群爱好者的支持，社群共建完成了对新框架的集成。
其二是 Linux 存在数量巨大的发行版提供商。前面提到，要想基于 Linux 内核搭建一个完整的桌面环境或服务器，需要做一系列的定制化。虽然这种定制化给予了用户极大的自由，以至于近乎每个问题都不只有一种解决方案，但是很多时候，用户只是想要一个能够满足桌面环境下个人需求，或服务器环境下生产需求的，类似 Windows 或 Mac OS X 的集成系统。Linux 发行版主要的工作，就是打包一系列应用软件和工具链，提供给用户一个开箱即用的“操作系统”。
在所有 Linux 发行版当中，占据主要份额的是 Arch Linux 系和 Ubuntu 系。
Ubuntu 发行版由 Canonical 公司提供商业支持，提供了用户友好的图形化安装界面，并且针对尝鲜用户、个人桌面用户和企业服务器用户设计了专门的开箱即用路线。由于 Ubuntu 已经定制了相当部分的应用框架和应用软件，Ubuntu 系的其他发行版更像是不同品牌商在预装 Windows 操作系统之后提供一些自己的捆绑软件。
相较之下，完全由社群维护的 Arch Linux 发行版奉行极简之道。它只提供最基础的安装程序和 AUR 中央软件库，并辅以完善的 Wiki 文档帮助用户自行定制 Linux 系统。Arch Linux 系的发行版除了都使用 AUR 软件库以外（甚至 Manjoro Linux 都选择了自建软件库），从图形界面到每个功能软件的选择，都可以是大相径庭的。
从上面的例子当中，我们可以看到，开源软件的用户群体明显的分成两类：一类是使用 Arch Linux 发行版的，追求自由使用和修改软件，也有意愿和能力做定制化的，我们可以称之为黑客（Hackers）；另一类是使用 Ubuntu 发行版的，期望提供商直接交付一揽子解决方案的，或者在商用层面需要乙方兜底的，我们可以称之为顾客（Customers）。
开源软件的商业化，主要瞄准的是顾客的需求，通过满足顾客的需求收费。黑客群体往往只在生态繁荣上做贡献，并不直接参与商业化的进程。
春节在家整理存书，发现了当时在拼多多做业务开发工作的时候，用来帮助理解互联网企业服务架构的若干书籍。这些书里的技术方案可能有一定的落后，但是对于帮助新入职场的互联网公司程序员，了解一个典型的互联网企业核心服务架构，以及治理服务和分化出数据团队的过程里会发生的技术服务体系变化，还是很有帮助的。这里做一个分享。
自由软件运动已经发展了近四十年。从最初的 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 | <artifactSet> |
从注释中我们可以看到 force-shading 的作用是强制触发 maven-shade-plugin 的执行，并且提到了这样会生成所谓的 effective pom 文件。这究竟是怎么一回事呢？我们先从一个实例中理解这个问题。
本文整理自第七届中国开源年会开源码力圆桌：十字路口，代码是我们永恒的信仰上我的发言。