众所周知，开源软件许可证粗略分为 Copyleft 类和 Permissive 类。
这两者常被提及的不同之处，是前者要求对软件的修改和派生仍需以相同条款发布，而后者允许修改软件和派生软件不再发布源代码。
不过，如果我们从两者相同的要求出发，重新看待开源共同体的成员对作为契约的开源许可证的认识，就会有崭新的发现：无论是 Copyleft 类的许可证，还是 Permissive 类的许可证，都没有授予接收方使用软件商标的权利。
特别地，BSD 3-Clause 和 Apache License 2.0 明确限制了接收方使用软件商标（名称）为自己站台的权利，GPLv3 则在附加条款中允许许可方补充限制接收方使用商标的权利。
简言之，商标是被保留的，与发布软件和上游作者绑定的，而不是公共的，任何人可以随意使用的。
那么，为什么开源许可证在允许接受方任意使用、修改、复制和重分发软件的情况下，对商标却采取截然不同的保留态度呢？
本文演绎自 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 上项目协作的常见形式入手，回答这两个问题。
分布式系统的开发者知道，不同于本地方法调用总是被执行，要么成功要么失败，分布式系统之间各个组件的远程调用还存在第三种可能，那就是超时。
从消息发送者的角度看来，超时意味着没有确认信息返回。但是当前调用对应的一系列操作到底是已经成功，只是回复丢失，还是其中某些失败某些成功，或者全部失败，甚至是请求本身没发出去，这些情况一概无法断言。
大部分开源社群是分布式组织，社群成员分布在不同的地域乃至不同的时区。相比于线下集中办公的组织而言，分布式组织与分布式系统一样存在着“超时”的挑战。
线下集中办公时，负责同一个工作项目的人经常会坐在一起，有什么事情转过头、走几步也就当面说清楚了。工作关系紧密的几个人往往会共享午餐时间，休息娱乐时间。这种面对面的合作带来的信任感和大小事情都能当面沟通的效率，是分布式组织很难直接做到的。
不过，无法效仿线下集中办公的方式直接面对面沟通，并不意味着开源社群这样的分布式组织的沟通效率就总是低下的。从我在开源社群数年的观察和实践来看，要想做到在开源社群这样的分布式组织当中高效地协同，确保事情在异步沟通和分布式合作的情形下仍然能够稳步前进，一个不可缺少的点就是饱和沟通（Overcommunicate）。