本文演绎自 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）。
《ClickHouse 社群指标模型》一文里提到了 ClickHouse 社群基于自己的软件 ClickHouse 制作社群指标的探索。由于遇到了公开数据集表模式缺列，查询执行内存限制，以及数据库只读模式限制等问题，我在过去一周里试着按照 ClickHouse 官方博客的介绍，搭建起了一个属于自有的基于 ClickHouse 的 GitHub 事件数据库。
简单介绍下结果，自建数据集确实解决了上面列举的三个问题。然而，我选择的 16 核 64 GB 内存版本实例在查询性能上还不如 Playground 的性能，只是内存占用大的聚合查询 Playground 可能由于 Quota 限制无法执行。另外，我选择的阿里云上的 ClickHouse 数据库在追上游版本和一些使用体验上还是有所欠缺。最后，日常数据同步的脚本可以在 korandoru/github-adventurer 取用。
当然，我会去做这件事，还有一个不可忽视的原因是我所在的公司本身商业模式就是云上售卖数据处理服务，我希望能够基于云上的服务搭建自己的业务，体验这个流程可能遇到的各种问题。因此，本文不是一个指导手册或者技术指南，而是实现过程中每个环节的杂谈。
随着信息化和数字化的发展，传统企业的业务发展在软件的帮助下突飞猛进。软件技术日新月异，几乎每隔几年就会有全新的技术和产品颠覆过往业务开展的方式。然而，掌握前沿软件技术的人相对于全行业的需求可谓是凤毛麟角。为了规模化前沿技术的价值，越来越多的软件服务公司如同雨后春笋一样不断出现。
顾名思义，软件服务公司主要以提供高质量的软件或软件服务来提高其他企业开展业务的效率。随着软件技术日益复杂，采用何种软件服务逐渐从以往的 CTO/CIO 决策转变为不同领域的一线开发者根据自身的能力和喜好选择。因此，软件服务公司需要专门制定开发者关系的策略，以在新形势下继续赢得客户订单。
本文将以 What is Developer Relations? 网站的介绍和 Ubuntu 前任社群经理 Jono Bacon 的视频 Developer Relations: A Complete Guide to what it is, how it works, and whether you need it 为基础，讨论开发者关系将为企业带来什么价值，开发者关系的从业者到底在做什么工作，以及从事开发者关系工作需要具备什么样的能力。