如何将开源项目提升到更高的水平

向软件即服务（SaaS）开放源代码不足以使其真正成为开源。

大多数支持“开源”的服务都是通过简单地用代码来实现的。 它总比没有好，但确实错过了开放源代码的意义：使用户能够更改所使用的软件。

由开源软件提供支持的其他一些流行服务的确包含用于操作/部署其服务的工具。

但这还不足以实际使用户有效地成为贡献者。

服务的价值大部分来自代码以外的东西。 它来自运行的基础架构，操作流程，监视，备份，指标，高可用性和可伸缩性。 它来自数据，来自网络的影响–与其他用户，与其他互连服务，集成工具，协议等。

推出服务的克隆以有效做出贡献是一个很大的障碍。 某些类型的贡献显然是可能的。 但是从本质上来说，要求提供者“分叉”服务的非代码方面，以根据实际使用情况迭代其更改。

更重要的是，如果没有真正的开源原则，我们就缺少一种以社区本身为重心发展社区的方法。 这导致公司以一种具有真正社区的典型开源项目能够抵御的方式提供服务。

我相信，如果我们能够服务而不只是为软件做出贡献，那么我们将获得真正开放源代码的优势。 这意味着使用户能够对正在运行的服务进行更改，并体验不断变化的自身。

这意味着针对正在运行的服务发送请求，并在合并之前经历更改。

实现这种功能所需的每种技术已在现代部署和运营方法中使用。 我们只需要连接点。

开发者为什么要在乎？

有一个非常简单的原理可以驱动开源：

开源在转换某些东西时会蓬勃发展
会使一小部分用户成为贡献者。

如果中断该原则，那么开源就不存在。 SaaS就是这样做的：当其他人运行你开发的软件时，无法使用直观的机制来更改该软件。

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

当然，可以更改某些组件中的代码。 但是，对于任何相当复杂的服务将无法在现实的工作流程上运行更改或体验更改，更不用说对其进行迭代，直到它们可以与他人共享为止。

实际上，服务的用户不能轻易更改服务中的某些内容，这不仅是因为流程是由其他人操作的，而且还因为他们明确选择不参与软件的操作。

如果使用Postgres的主要方式是“服务”，那么这个项目望而却步。 这是因为此类项目中的贡献者数量是决定决定进行更改的一小部分用户的函数。

随着这种使用SaaS的机制席卷全球，可以为开源做出贡献的用户数量急剧减少。

长期以来，无法调和SaaS与健康的开源生态系统。

但是最近，我确信，如果我们对服务启用有效的贡献模型，而该模型不需要用户成为该服务的运营者，那么开源将在服务上蓬勃发展。

需要做什么？

我们必须建立一个流程，使他们可以对正在运行的服务进行更改，并在其他服务之前体验到更改。

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

发现服务的哪个组成部分
进行无意义的更改（例如添加printf样式的日志语句）或更改单词的拼写
当他们使用服务或对数据进行操作时，会体验到变化

与其他人讨论之后，坚信我们拥有所需的所有技术，无论它们是部署，负载平衡，持续交付，以代码为基础的基础结构等等。 很难找到现有实践无法解决的单个问题。

事实证明，许多经验丰富的工程团队都得出了相同的结论。 快速将变更部署到服务是一项备受追捧的强大功能。 例如，GitHub会在合并之前部署更改。 而Facebook则将更改快速部署到一些机器上，并将每个更改扩展到生产。 每个人都有自己的持续交付版本。 如果工程团队尚未弄清楚他们的团队成员如何快速部署变更，就很难认真对待它们。

开源具有所有要素，可以在这里发挥决定性的优势。 与所有人类的贡献者一起在开源服务上进行有效的协作。

让我们尝试制作一个以实现驱动开放源代码软件并将其应用于开放源代码服务的基本功能：即更改代码并与更改进行交互的能力……当然是在服务上。

好了，本文到此结束。如果对编程、计算机、程序员方面感兴趣的话，欢迎私信联系我，随时交流！点个关注，是对我莫大的鼓励！