如果想做好开源代码，需要进行相当多的计划，尤其是在用户支持和文档方面。对于 SaaS 而言，所需的计划有所不同，尽管它与任何开源工作都有一些共同之处。在我的系列文章如何从开源平台赚钱中，我专注于仅用于部署在计算机上的软件，无论是在本地机器上、数据中心中还是在云平台中（是的，我知道最后两个是冗余的）。
之所以如此关注，原因很简单：这是我所了解的。在我的职业生涯中，我一直致力于商业和社区来源的软件，这些软件需要安装在某个地方。现在，我直接与工程师合作，他们使用专门设计用于在其网站上以及其特定基础设施、自动化和编排环境中运行的软件。他们能够采用该软件并以不仅可用，而且实际上可以为其他企业提供支持的方式提供给其他人，这证明了他们对开源世界的承诺。
本文试图总结他们的经验，并指出从中可以汲取的教训。我还将尝试确定开源工作如何与 SaaS 模型的业务和产品策略相关联。
软件工程并非都相同
正如我多次提到的，源代码本质上毫无价值。当然，它是构建一切的基础，但是如果没有一种方法来管理它并自动化将其转化为可工作的解决方案的过程，我就无法从中收取费用。我可以从世界各地的项目和社区免费获得数百万行代码，但是将其中任何一个转化为可管理的解决方案都需要大量的努力。
大多数开源项目都强调可用性。无论项目是由上游社区还是仅仅希望将其软件交付给更多用户的供应商生产的，都是如此。实际上，这就是这些软件社区的目的：生产可用的软件，供人们部署在他们选择的各种平台和操作系统上。
对于为 SaaS 解决方案设计的软件而言，情况并非如此。在这种情况下，该软件仅针对一种特定用例，在一种特定环境中进行设计：即它所设计的 SaaS 解决方案。在这种情况下，很少考虑其他用例、其他环境或平台，甚至没有确定所生产软件是否存在通用用例。
这也许是为什么 SaaS 提供商开源软件时，通常是针对非软件制造商主要业务的特定任务。例如，Netflix 可以开源一个应用程序集群项目，该项目与其主要软件堆栈和操作相当独立。 Facebook 可以开源 React，但它不会开源模仿其 Web 体验的“Facebook 企业版”解决方案。这不仅会潜在地削弱其主要价值主张，而且还难以支持、管理和维护。
这让我想到一个显而易见的问题：SaaS 提供商是否应该开源其主要平台？如果是，最好的方法是什么？
多年来，我的想法一直在发展。我以前认为，对于 SaaS 企业而言，开源平台会更容易，因为其主要价值在于其业务的有效运营，而这很难复制。我的想法是，没有人能够像该技术的发起者那样高效地运行来自 SaaS 提供商的软件堆栈。当您意识到这些解决方案的源代码只是该解决方案的运营和管理的一小部分时，尤其如此。SaaS 解决方案的其余部分涉及许多定制的配置管理模块、与各种管理和安全框架的集成，以及使可靠的 SaaS 体验成为可能的丰富的数字绑定线。
我认为开源对于 SaaS 可行的另一个原因是，开源软件可以很容易地与商业解决方案分离。在传统的企业软件世界中，开源和商业解决方案都部署在软件运营商拥有的平台上。这导致在“我们开源太多了”和“我们开源不够”之间无休止地摇摆。由于这两者都部署在用户选择的平台上，因此人们非常担心最终用户会从免费的东西中获得足够的价值，而没有必要为此付费。
在 SaaS 世界中，只有开源解决方案会部署在软件发起者之外的其他人拥有的平台上。商业解决方案，即仅在一个网站上运行的解决方案，根据定义，只能部署在软件发起者拥有的高度定制的平台上。我假设这意味着，正如经济趋势向开源方向倾斜时企业软件所做的那样，打开闸门只是时间问题。但是在 SaaS 世界中，那些闸门尚未打开，现在我想我知道原因了。
SaaS 是否应该开源？
这个问题不容易回答。答案虽然令人不满意，但取决于您项目的最终目标。这需要对您的特定软件平台和框架进行彻底评估。
- 您的解决方案中，哪些适用于外部人员？
- 是整个解决方案，还是解决方案的一部分？
- 支持真正的开源工作需要多少努力？
- 最后，将其作为开源发布是否会危及您核心业务的某些部分？
我之所以提出最后一个问题，只是因为我知道这是每个人都会问的问题，但坦率地说，这是三个问题中最不有趣的。
为了充分解决这个问题，让我们回到我最喜欢的可视化工具：软件供应链。
如上图所示，软件供应链漏斗的基础知识是从左到右流动的。从构成您的软件解决方案的原始位开始，然后随着您向右流动，添加自定义、集成和其他配置和管理步骤。最终，您将在漏斗的右侧得到一个“完成”的产品。当然，众所周知，在 SaaS 世界中，您永远不会完成。尽管这可能并不完美，但是只要您了解这是一个连续的过程，该图就可以帮助您了解如何优化流程以提高效率。
在上图中，我叠加了构成供应链的各个部分的代表性形状。左侧是用于构建解决方案的原始位，例如 Linux 内核、Kubernetes 等。很多集成工作都是为您完成的，因为我怀疑您会从头开始构建 Linux 发行版（尽管您可能会）。在这种情况下，您可以替换您构建在其上的平台之一，例如 Ubuntu、Debian、CentOS、Fedora、OpenSUSE、Alpine 或其他一些风格。当您从左向右移动时，在中间部分（我稍后会介绍）和左侧的成品之间绘制一条假想的虚线。
虚线左侧的所有内容都应该是社区管理的代码。虚线右侧的所有内容都应该是您的内部团队维护的代码。右侧的所有内容都是技术债务。左侧的所有内容都不归您所有。理想情况下，左侧的东西将占您用于构建解决方案的代码的 80-90%。右侧的东西应包含剩余的 10-20%。请注意，即使箭头指向一个方向，这并不意味着您的团队从不修复错误或在行左侧贡献代码。实际上，当他们这样做时，上述场景效果最佳。此外，仅仅因为软件是社区管理的，并不意味着您的团队没有为其做出重大贡献。同样，通常最好的是他们这样做。
有趣的部分开始了，一个简单的问题：您可以合法地将当前解决方案的多少推到行左侧，以便您的团队仅维护 20% 或更少的代码库？
答案并不总是那么简单。也许您最初的想法是，只有不到 50% 的代码具有足够的通用适用性，可以由外部社区维护。在实践中，我发现如果您将整个 SaaS 解决方案分解为单独的组件，您将能够更轻松地将更高的百分比专门用于社区维护。答案通常是以下两种情况之一：要么您没有将解决方案分解为足够的组件，要么您的解决方案过于专业和独特，以至于与外界无关。在绝大多数情况下，是前者。
这需要很多工作
在大多数情况下，构成 SaaS 解决方案的软件从未打算在创建它的环境之外使用甚至查看。相反，开源项目源于创建者的思想，目的是与原始项目之外的人员共享和使用。这意味着 SaaS 中的开发工作流程完全不同，不适合构建开源社区的任务。
在许多方面，我描述的困境类似于开发人员试图将其转变为开源项目的传统专有解决方案。除非您从一开始就作为一个开源项目开始，否则将其从专有转换为开源的任务需要主要开发团队进行大量的工作流程更改，从而导致开发人员感到非常沮丧，并且至少暂时降低了开发速度。人们认为这种过渡期负担过重，回报太少，这就是为什么许多此类努力失败或仅部分成功的原因。
还有一个问题是，你的团队构建的组件是否是你应该使用的组件。它们是否可以被你组织之外的开源社区生产的其他组件所取代？ 也许你的团队使用了一些软件项目作为解决方案的基础，但随后他们决定对其进行分支并在此基础上进行构建，从而使你承担了永久维护它们的技术债务。 你将不得不把这些分支重新建立在上游代码库之上，然后向上游社区添加代码。 这并非易事，特别是如果这些项目的核心贡献者都没有在你的工资单上，并且你的团队在这些社区中没有信誉。
将任何 SaaS 解决方案分解为一组可行的组件所需的架构变更，以及围绕这些组件构建社区以减少技术债务所需的总体工作量，你可以很容易地看出为什么这条路鲜有人走。 将分支重新建立到各自上游代码库的复杂性增加，会增加你的团队在短期内生产力降低的可能性。
在第二部分中，我将向你展示如何使用你的 SaaS 代码创造开源魔法。
1 条评论