开源你的SaaS业务会面临的挑战

在我之前的文章中，我讨论了各种场景，以帮助你确定是否应该开源你的SaaS解决方案，并讨论了与此决定相关的成本效益分析。从开源的角度来看，仅仅把代码扔过墙，贴上一个开源许可证，然后就此结束毫无意义。 你需要创建一个吸引人的社区，让人们愿意与你合作、共度时光——甚至进行社交！

把代码扔过墙什么都实现不了，除了让别人洞察你的做事方式。 尽管这对他们来说可能很有趣且有益，但除非你创建促进蓬勃发展的社区的协作和沟通渠道，否则你不会获得太多好处。因此，你对以正确的方式™这样做有着内在的兴趣。

我这里有好消息和坏消息要告诉你

• 首先，坏消息：这真的很难！你应该从一开始就这么做。
• 现在，好消息：这确实有回报，而且你得到的回报远大于你的付出（我有数据证明这一点）。

开源为SaaS设计的整个软件堆栈的最大问题之一是，开发团队习惯于从单个代码仓库工作。 事实上，他们经常嘲笑我们的企业软件同事，他们有多个分支分散在各处。 我对DevOps哲学家的一个最大的问题是，他们通常认为这个单一的分支或仓库是你所需要的全部。 如果你正在使用来自父仓库的分层分支，那么这被认为是敏捷开发的反面。

建议你可以简单地依靠单个代码仓库或分支听起来很吸引人，但这对于协作开发的软件来说本质上是有问题的。 以下是一个典型的SaaS项目的供应链

以上图表有两个主要问题

1. 来自上游开源项目的核心代码被Fork后就被遗忘，然后被带入并与其余代码一起维护，直到将来需要痛苦的重新合并为止。 它被Fork的原因是...
2. SaaS项目永远不需要担心管理来自第三方来源的传入代码。 整个过程旨在从外部获取，在内部自动化，永远不会向上游合并。 它被设计成使用后丢弃，而不是针对持续管理和维护进行优化。 因此，当开发团队意识到协作项目需要管理传入的想法和代码时，他们会感到震惊。

你的核心团队和不一定具有相同用例的传入贡献者之间的内在冲突可能是痛苦的。 这些第三方希望拥有共享的所有权和管理权，但这并不总是与项目发起者的用例保持一致。 核心团队只想让他们的解决方案工作，宁愿不理会传入的贡献，即使为了克服我之前提出的资源约束问题，这是必要的。 允许SaaS项目超越其原始团队的唯一真正解决方案是这样的

这是一个为开源协作而设计的更健康的工程流程示例。 为了缓解开发者之间的冲突，主要源代码仓库被分为上游版本和下游版本。 上游是每个人贡献他们的代码和想法的地方。 这是基础创新发生的地方。 下游代码是你的团队优化他们从上游拉下来的代码（前面提到的80-90%）的地方，然后添加任何特定于你的特定用例或实现的东西（10-20%）。 因为现在这是一个功能性社区，所以有额外的资源来帮助保持你左侧传入的上游组件的更新。 达到这一点需要时间，但如果你愿意付出努力，就会有回报。

预期的投资回报率是多少？

考虑到将SaaS转换为开源所需的大量努力，不应轻易做出开源的决定。 这引出了一个问题，即你可以期望从这种生产力牺牲中获得什么回报。 回到上面的供应链图，这意味着你的团队将能够与外部团队协作开发核心代码，从而大大提高效率。 这不仅仅是一个学术或理论练习； 我们有数据支持它。 正如我在OSEN博客上描述的，世界银行对其在Geonode项目中的投资进行了一项研究，确定其工程投资的投资回报率为200%，这非常显着。

这意味着领导SaaS工程团队的任何人将需要进行以下计算：效率的提高需要花费多少时间才能超过重新架构给定项目或一组项目的成本？

该计算的一部分必须包括执行此工作的可用资源。 例如，如果你能够大规模雇用工程师并拥有Google，Facebook或Amazon的资源，那么你可能不太注重成本，并且在工程方面提高效率的想法可能并不那么引人注目。 另一方面，如果你面临工程资源的减少或停滞，并且你的竞争对手拥有更多随时可用的资源，那么采用开源路线可以让你更具创新性，并专注于在竞争激烈的市场中增加更高的价值。

蚕食和失去竞争优势

最后，我们谈到讨论这个想法时最常被问到的问题：我是否为我的竞争对手提供了将我赶出市场的弹药？ 答案通常是否定的，尽管说它从未发生过是错误的。 但是，如果你是一家SaaS企业，那么你的主要竞争对手很可能没有使用你的解决方案，即使他们有机会，也很不可能转向你的解决方案。 你的竞争对手，像你一样，已在其解决方案中构建了一系列旨在专门用于运营其业务的决策，自定义配置和工作流程。 你的软件可以无缝地融入他们的解决方案的机会接近于零。 重新设计解决方案以适应竞争对手的软件平台的想法太渺茫了，以至于我想不出曾经发生过的任何实例，无论我们谈论的是专有的本地软件还是SaaS解决方案。 这种风险对于本地软件来说已经很低，对于SaaS来说则更低。

虽然这种风险非零，但必须与不开源软件的风险进行权衡。 不开源你的软件组件的风险包括永远无法实现添加足够的价值以实现你的目标所需的创新速度。 哪个风险更可能发生？ 如果你有几乎无限的资源，那么你的风险概况会朝着不为竞争对手提供潜在弹药的方向倾斜。 但是，如果你未来面临资源有限的情况，请考虑不开源你的软件的风险大于开源的风险的可能性。

结论

尽管付出的努力是巨大的，并且不应轻易做出决定，但花时间和精力开源你的SaaS解决方案很可能会为你带来可观的投资回报。 在你看到投资回报率之前经过的时间取决于多种因素

1. 你的软件基础有多么单片
2. 需要多少代码重构才能使其普遍可重用
3. 可以用多少上游代码来代替你当前的代码库
4. 你的团队对开放治理模型的适应程度如何
5. 你能够以多快的速度通过开源工作获得吸引力
6. 有多少工程师参与上游社区

最终，收益超过成本。 关键是要耐心等待你的工程师学习如何在开源社区中进行协作，以产生大于其各部分总和的价值。

你会发现大多数SaaS商店还没有这样做。 尽管事实上大多数SaaS代码都平淡无奇。 造成这种情况的原因有很多，但我认为最大的原因是这些企业的投资者被这样一种观念所迷惑：基于SaaS的企业是保留所有知识产权而不分享的好方法，即使他们在过程中使用了大量开源代码。

不幸的是，这使许多商店处于劣势：随着时间的推移，除非他们拥有Google，Facebook或Amazon的收入，否则他们的业务增长将很快超过他们的工程师跟上的能力。 在这一点上，许多SaaS企业撞到了墙壁，并以微薄的价格出售或干脆消失了。

除非你拥有Facebook或Google的资源，否则请设计你的工程工作流程以进行协作并获得回报。 如果你一开始就那样做，你将不必面对重新架构工程过程的麻烦任务。