saas开源_如何决定是否开源您的SaaS解决方案

saas开源

如果您想正确地进行开源代码的决定，则需要做一些规划，尤其是在用户支持和文档方面。 就SaaS而言，所需的计划是不同的，尽管它与任何开源工作共享一些因素。 在我的系列文章“ 如何从开源平台赚钱”中 ，我重点介绍了仅可部署在计算机上的软件，无论是在本地计算机上，在数据中心还是在云平台上（是的，我都知道两个是多余的）。

有一个简单的理由来关注这一点：这就是我所知道的。 在我的职业生涯中，我一直使用安装于商业和社区的软件进行安装。 现在，我直接与工程师合作，他们所设计的软件只能在其网站上使用，并可以在其特定的基础架构，自动化和编排中使用。 他们能够使用该软件并将其以不仅可用的方式提供给他人的事实，而且实际上可以为其他企业提供动力，这证明了他们对开源世界的承诺。

本文试图总结他们的经验并指出可以借鉴的经验。 我还将尝试确定开放源代码工作与SaaS模型的业务和产品策略之间的关系。

软件工程也不尽相同

正如我多次提到的，源代码本质上是一文不值的。 当然，这是构建所有内容的基础，但是如果没有办法对其进行管理和自动化以将其转变为可行的解决方案，那么我就不能为此付费。 我可以从世界各地的项目和社区中免费获得数百万行代码，但是要将其中的任何代码变成可管理的解决方案都需要付出巨大的努力。

大多数开源项目都强调可用性。 无论该项目是由上游社区生产的，还是仅希望将其软件交到更多人手中的供应商，都是如此。 实际上，这就是这些软件社区的目的：制作可用的软件，使某人可以将其部署在他们选择的各种平台和操作系统上。

对于为SaaS解决方案而设计的软件，与其说是软件，不如说是。 在那种情况下，该软件仅在一种特定的环境下针对一种特定的用例进行设计：即针对其设计的SaaS解决方案。 在这种情况下，几乎没有什么想法专门用于其他用例，其他环境或平台，甚至确定所生产软件是否存在一般用例。

这也许是主要的原因，当软件打开由SaaS供应商采购的，它是不是软件制造商的主要业务特定的任务。 例如，Netflix可以为应用程序集群开源一个项目，该项目与其主要软件堆栈和操作相当谨慎。 Facebook可以开源React ，但不会开源模仿其网络体验的“ Facebook企业”解决方案。 这不仅可能削弱其主要价值主张，而且也难以支持，管理和维护。

这使我想到了一个显而易见的问题：SaaS提供程序是否应该开放其主要平台的源代码，如果是，那么最佳方法是什么？

这些年来，我的思想已经发展。 我以前认为，对SaaS业务而言，开源平台要容易得多，因为其主要价值在于其业务的高效运营，这很难复制。 这种想法是，没有人能像该技术的发起者一样高效地运行SaaS提供商的软件堆栈。 当您意识到这些解决方案的源代码只是该解决方案的操作和管理的一小部分时，尤其如此。 SaaS解决方案的其余部分涉及许多定制构建的配置管理模块，与各种管理和安全框架的集成，以及大量的数字保护索，这些都使可靠的SaaS体验成为可能。

我认为开放源代码对于SaaS可行的另一个原因是开放源代码软件可以很容易地与商业解决方案分离。 在传统的企业软件世界中，开源和商业解决方案都部署在软件运营商拥有的平台上。 这导致在“我们开源太多”和“我们开源不够”之间摇摆不定的循环。 由于这两者都是在用户选择的平台上部署的，因此，内部用户担心最终用户会从免费产品中获得大量价值而无需支付费用。

在SaaS世界中，只有开源解决方案才能部署在软件始发者之外的某人拥有的平台上。 根据定义，商业解决方案只能在单个网站上运行，只能定义为在软件始发者拥有的高度定制的平台上进行部署。 我认为这意味着一旦经济趋势向开源方向倾斜，就像企业软件一样，闸门打开只是时间问题。 但是在SaaS世界中，这些闸门尚未打开，现在我想我知道为什么。

SaaS应该开源吗？

这不是一个容易回答的问题。 答案虽然可能不尽如人意，但要取决于项目的最终目标。 这需要对您的特定软件平台和框架进行全面评估：

• 从您的解决方案中，什么适用于外部解决方案？
• 是整个解决方案还是解决方案的一部分？
• 支持诚实的开源工作需要付出多少努力？
• 最后，将其作为开放源代码发布是否会危害您的核心业务？

我之所以包括最后一个问题，只是因为我知道这是每个人都会问的一个问题，但是坦率地说，这是三个问题中最不有趣的一个。

为了充分解决这个问题，让我们回到我最喜欢的可视化工具：软件供应链。

上图中，软件供应链渠道的基础是从左到右。 从构成软件解决方案的原始内容开始，然后在向右流动时添加自定义，集成以及其他配置和管理步骤。 最终，您将获得“成品”产品，位于漏斗的右侧。 当然，众所周知，您在SaaS领域永远都不会完蛋。 尽管这可能是不完美的，但是只要您了解这是一个连续的过程，此图就可以帮助您了解如何优化过程以提高效率。

在上图中，我叠加了组成供应链的各个零件的代表性形状。 左侧是用于构建解决方案的原始位，例如Linux内核， Kubernetes等。许多集成工作已为您完成，因为我怀疑您会从头开始构建Linux发行版（尽管您可能会）。 在这种情况下，您可以替代您构建的平台之一，例如Ubuntu ， Debian ， CentOS ， Fedora ， OpenSUSE ， Alpine或其他某种风格。 当您从左向右移动时，在中间的部分（我将很快讲到）和左侧的成品之间画一条虚线。

虚线左侧的所有内容均应为社区管理的代码。 右边的所有内容都应该由内部团队维护。 右边的一切都是技术债务。 左侧的所有内容都不归您所有。 理想情况下，左侧的内容将构成您用于构建解决方案的代码的80-90％。 右边的东西应由剩余的10-20％组成。 请注意，即使箭头指向一个方向，也并不意味着您的团队永远都不会在行的左侧修复错误或提供代码。 实际上，以上情形在它们起作用时效果最佳。 而且，仅因为软件是社区管理的，并不意味着您的团队对此没有做出重大贡献。 同样，通常最好在他们这样做的时候。

答案并不总是那么简单。 也许您最初的想法是，不到50％的代码具有足够的通用性，可以由外部社区维护。 在实践中，我发现，如果将整个SaaS解决方案分解为单独的组件，则可以更轻松地将更高的百分比专用于社区维护。 答案通常是以下两件事之一：您尚未将解决方案分解为足够多的组件，或者您的解决方案是如此专业和独特，以至于根本与外界无关。 绝大多数时间是前者。

有很多工作

在大多数情况下，组成SaaS解决方案的软件绝不会在创建它的环境之外使用或查看。 相反，一个开源项目源于创建者的思想，其意图是由原始项目之外的人共享和使用。 这意味着SaaS中的开发工作流程完全不同，不适合构建开源社区的任务。

在许多方面，我所描述的困境与开发人员试图转变为开源项目的传统专有解决方案的困境类似。 除非您从一个开源项目开始就开始，否则将其从专有项目转变为开源项目的任务需要主要开发团队进行大量工作流更改，这会给开发人员带来极大的挫败感，至少是暂时的，较慢的开发速度。 人们认为，这个过渡时期实在太多了，而获得的回报却太少了，这就是为什么这些努力中有许多失败或仅部分成功的原因。

还有一个问题是您的团队构建的组件是否是您应该使用的组件。 可以用组织外部的开源社区生产的其他软件替代它们吗？ 也许您的团队使用了一些软件项目作为您解决方案的基础，但是后来他们决定分叉它并在这些分叉上进行构建，从而使您永远保持其技术负担。 您将不得不将这些派生基于上游代码库，然后将代码添加到那些上游社区。 这是一项不小的努力，尤其是如果这些项目的核心贡献者都不在您的工资单上并且您的团队在那些社区中没有信誉。

在将任何SaaS解决方案分解为一组可行的组件所需的体系结构更改与围绕这些组件构建社区以减少技术债务所需的总体工作之间，您可以轻松地了解为什么这是一条少走的路。 将派生分支的复杂性添加到它们各自的上游代码库中会增加您的团队在短期内生产力降低的机会。

在第2部分中 ，我将向您展示如何使用SaaS代码创建开源魔术。

翻译自: https://opensource.com/article/18/5/open-source-saas-y-world

saas开源