如何将你的开源项目提升到新的水平

将你的软件即服务 (SaaS) 代码开源并不足以使其真正成为开源。 听起来是否矛盾？ 让我解释一下。

大多数标榜“开源”的服务只是简单地将代码抛到墙外。 这比什么都不做要好，但真正错过了开源的力量所在：使用户能够更改他们正在使用的软件。

一些其他由开源软件驱动的流行服务确实包括用于操作/部署其服务的工具。 暂停一下，为他们鼓掌。

但这也不足以真正使用户能够有效地成为贡献者。

服务的许多价值来自代码以外的东西。 它来自其运行的基础设施、运营流程、监控、备份、指标、高可用性和可扩展性。 它来自数据，来自网络效应——与其他用户、与其他互连服务、与集成工具、来自法律协议等等。

任何非玩具服务都是不可复制的。

启动该服务的克隆以进行有效贡献是一个很高的门槛。 某些类型的贡献显然是可能的。 但是，贡献者基本上被要求“fork”该服务的非代码方面，以便针对他们的真实用例迭代他们的更改。

更重要的是，如果没有真正的开源原则，我们就无法拥有一个以服务本身为重心的社区。 这导致公司以一种典型的开源项目拥有一个真正的社区所具有的弹性方式 fork 该服务。

我相信，如果我们能够为服务做出贡献而不仅仅是软件，我们就能获得真正开源的优势。 这意味着使用户能够更改正在运行的服务并亲自体验该更改。

你还在听吗？

是的，这意味着针对正在运行的服务打开一个拉取请求，并在合并之前体验该更改。

这并不像听起来那么疯狂。

似乎我们启用这种能力所需的每项技术都已在现代部署和运营方法中使用。 我们只需要连接各个点。

我为什么要关心？

我参与开源已经 20 多年了。 虽然我只是一个贡献者，但我们共同改变了世界的一些基本面。 我们的生命太短暂，软件太复杂，无法让一家公司或一个人从头开始发明一切。 因此，我们全人类共同努力完成没有一个团队可以完成的事情。 这是我们的遗产，它已变得司空见惯。

然而，有一个非常简单的原则驱动着开源

开源在以下情况下蓬勃发展

将一小部分用户转化为贡献者。

如果你打断了那个原则，你就会扼杀开源。 SaaS 就是这样做的：当其他人为你运行你的软件时，你更改该软件的直观机制不可用。

图片来自

^{（来源：Stef Walter）}

你可能会说，“但是，如果正在运行的服务的源代码是开放的，那么我仍然可以更改它。”

当然，你可以更改某些组件中的代码。 然而，对于任何合理复杂的服务，你将无法运行你的更改或针对真实世界的工作流程体验你的更改，更不用说迭代它们，直到它们足够好可以与他人分享。

实际上，这里的威胁更为根本：服务用户无法轻易更改服务中的某些内容，这不仅是因为流程由其他人操作，还因为他们明确选择不参与软件的运行。

如果使用 Postgres 的主要方式是“作为服务”，那么（非常棒的）项目将缺乏贡献者。 这是因为此类项目中贡献者的数量是决定尝试进行更改的一小部分用户的函数。

随着这种使用 SaaS 的机制占据世界，可以为开源做出贡献的用户池急剧缩小。

长期以来，我将此视为会扼杀开源的根本威胁。 我无法将 SaaS 与健康的开源生态系统协调起来。

但最近，我确信，如果我们能够为服务启用有效的贡献模型，该模型不需要用户成为服务的运营商，那么我们可以协调这种威胁，并且开源将在服务上蓬勃发展，而不是被它们扼杀。

你想让我做什么？！

为了让服务用户（他们已明确选择不自己运行软件）做出贡献，我们必须建立一个流程，使他们能够更改正在运行的服务并在其他人之前体验该更改。

例如，这种假设服务的用户应该能够

1. 发现要贡献的服务中的哪个组件
2. 进行无意义的更改（例如添加 printf 样式的日志语句）或更改单词的拼写
3. 在使用服务时或服务对其数据执行操作时体验该更改

在与其他人讨论之后，我坚信我们拥有所需的所有技术，无论是金丝雀部署、负载平衡、持续交付、基础设施即代码等等。 很难找到一个现有实践无法解决的单一问题。

事实证明，许多经验丰富的工程团队也得出了同样的结论。 快速部署对服务的更改是一种强大的能力，备受追捧。 例如，GitHub 在合并之前部署更改。 而 Facebook 将更改快速部署到少数金丝雀机器，并将每个更改扩展到生产环境。 每个人都有自己版本的持续交付。 如果一个工程团队还没有弄清楚他们的团队成员如何快速部署更改，就很难认真对待他们。

开源拥有所有要素，可以在这里取得决定性的优势。 为了有效地协作开源服务，贡献者遍布全人类。

让我们尝试制定一个剧本，以实现驱动开源软件的基本能力，并将其应用于开源服务：也就是说，更改代码并与服务上的更改进行交互的能力。

注意：感谢本文的审稿人！

这最初出现在 stef.thewalter.net 上，并经作者许可转载。