几个月前，我关于开源商业模式的博客似乎引起了共鸣。我收到了许多积极的回应，并因此收到了一个名为“软件是如何构建的”网站的采访请求。我的采访在这里。

终于，OpenLogic 的一个人发表了一个有趣的回复。Bryan Noll 在我博客的回复中留下了一些评论，值得认真回应。

首先，我认为您认为，当对某个特定项目没有真正投入的人提供支持时，这对项目或开源整体而言是不健康的，这是一个有趣的观点……我以前从未听过。我认为这个观点有足够的有效性，足以让像我们这样的公司认真考虑并真正审视我们对所支持的开源项目的责任。在我看来，这项审查的结果将是一项可证明的政策，OpenLogic 将以此来减轻您提出的潜在担忧。我当然不知道具体会是什么，所以请允许我此刻保持模糊。不过，这恰好又引出了我与您观点中的一些问题。

我认为要找到这样一项“可证明的政策”应该很简单。OpenLogic 需要理解，Stormy 的帖子中的开场白“开发人员从事开源软件工作通常有报酬丰厚的工作……所以他们免费从事开源软件工作，白天为巨额报酬编写代码”在很大程度上是错误的。它需要理解他们希望从中获利的开源软件来自何处，进行适当的合作，并设定一个允许真正支持的价格。另一种选择是停止声称提供企业支持，并明确表示所提供的是一种随叫随到的开发协助，但不能保证能够解决关键问题。这就回到了我为什么对 Stormy 的帖子有如此强烈的感受并对其进行解构。

我将聚合模型视为一种超市式业务。我在超市购物时，期望他们从我购买的所有商品中抽取（少量）利润，以换取他们处理许多供应商，将我想要的所有商品集中到一处，并提供停车场和购物车。我期望大部分经济价值能够回流到生产产品的公司。

OpenLogic 和他们的一些竞争对手拥有一个有效的超市式业务机会。只是他们似乎希望，开源作为一个新市场，允许存在一种超市的概念，这种超市几乎独占所有利润，而不向供应商支付报酬。这是一个破坏性的模式，无法长期生存。

聚合还有更可持续的途径。许多全球性的 SI 向客户提供包含聚合服务的支持合同，为了提供企业客户所需的质量支持，他们会将合同分包给各种开源公司。换句话说，他们不打算将超市商品的所有利润都装进自己的腰包，而是将*真正*的支持纳入定价。OpenLogic 也应该这样做。或许他们不这样做的原因在于，承认聚合者实际上是中间商，这让他们在大型 SI 和创建开源 IP 的专业公司之间处于一个尴尬的境地。尽管如此，那里存在一个可持续的商业机会。

Brian 继续说

你不能鱼与熊掌兼得。你说

我的“支持”可能来自非贡献者。所以 OpenLogic 无法保证战略性地解决问题。可靠的支持涉及到能够提交到主干——并且，在某些情况下，还要为客户的特定版本维护分支。

有趣的是，在 Spring 的案例中，Interface 21 将是能够实现你所提出的唯一实体。（如果我在这里说错了，请纠正我。）这对 Interface 21 来说似乎是一笔非常划算的交易。

是的，没错。这可能让你觉得奇怪，但个人和公司希望从数百万美元的投资、激情、汗水和泪水中获得回报，这是很正常的。Interface21 维持并开发 Spring，而且我们做得很好。我认为，期望我们能够利用这项投资在支持市场中获得优势，这是完全合理的。我们的财富 500 强客户也同意这一点。

所以，你似乎在争辩说，OpenLogic 不能从他人辛勤工作和投资创造的代码和社区中获利，这是不公平的。我不能通过支持 PHP、WebLogic 或 Oracle 来赚钱，这公平吗？BEA 在 WebLogic Server 维护收入市场占据主导地位，这难道不是一个“不合理地有利可图的交易”吗？

关于“公平”的这个有缺陷的论点忽略了 OpenLogic 是否能够“战略性地解决问题”的实际问题。而它不能，原因我已阐述。

如果你开源你的代码，并且它是一个伟大的产品，像你的一样大受欢迎，你真的期望市场上没有人会试图围绕它开展业务吗？肯定不会……再举一个例子，想想那些关于 Spring Framework 的书籍，它们不是由 Interface 21 的人写的，或者那些因为学习了你开源的框架而具备高市场价值的开发者。他们应该对项目的健康状况感到内疚吗？Interface 21 能够获得如此巨大的收益，是因为产品 A) 很棒，而且也是因为产品 B) 通过开源并免费提供给市场，得以大规模交付。虽然不完全相同，但这个论点有“我发明了汽车，所以别人就不应该能够制造和销售汽车”的感觉。

其他公司和个人不可避免地会围绕产品开展业务，这很好。然而，检查他们所做的任何声明都是公平的。

让我们看看事实：Interface21 的 Spring 团队一直支持外部人士编写的书籍，比如 Craig Walls。我们鼓励人们写关于 Spring 的书。像 Craig 这样的人具备编写这类书籍的经验，我们祝愿他们取得巨大成功。（顺便说一句，Craig 的《Spring in Action》有第二版即将出版。买它，我保证你不会因此生气。）

至于那些因为学习了 Spring 而具备更高市场价值的开发者，这很好。我为自己创立了一个项目，帮助我的开发者同仁创造了市场（也让他们工作更愉快）感到自豪；我很高兴我的公司对我们产品的持续投入能够不断壮大这个市场。现在每天都有*数千份*招聘信息明确要求 Spring 技能，并且它们正在迅速呈上升趋势；祝愿申请这些职位的求职者在回答 Spring 相关问题时好运。

作者和这数千名开发者通过他们的宣传为项目的成功和社区做出了贡献。这是做出贡献的重要方式。OpenLogic 则没有；它仅仅是为了从他人已经构建、宣传并方便地维护和增强的项目中获利。这才是真正的“血汗钱”。

我的帖子 concerned 了一般性的企业级支持问题。这是一个不同的问题。OpenLogic 不仅仅声称它能够以这种方式提供 Spring 方面的知识，或帮助交付 Spring 项目；它声称它能够为许多项目的企业支持提供同等的支持水平。我已经详细论证了为什么它不能。

请注意，我的博客讨论的是企业开源软件支持质量的更普遍问题。虽然我现在直接处理您关于 Spring 的问题，但这个模型的缺陷适用于许多项目。

您段落的第一句话值得再次回应

如果你开源你的代码，并且它是一个伟大的产品，像你的一样大受欢迎，你真的期望市场上没有人会试图围绕它开展业务吗？

现在我想知道，它为什么是一个伟大的产品？为什么它如此受欢迎？是偶然发生的，还是大量持续投资的结果？

其次，虽然我再次承认我认为你关于潜在项目健康影响的观点很有道理，但驱动市场聚合支持的另一个事实仍然存在。如今，企业为了获得他们正在开发和部署到生产环境的软件的支持，必须经历一个极其繁琐的过程……在我看来，管理跨多个孤立部门的 X 个项目的支持合同，就像一场低效的噩梦。从企业的角度来看，聚合这些服务是有意义的，无论你如何声称它目光短浅。如果市场上存在商业机会，你不能责怪某人乘虚而入并利用这个机会。

我并不是说聚合没有价值。只是说低质量服务的聚合没有什么价值。链条的强度取决于它最薄弱的环节。

“管理跨 X 个项目的 Y 个孤立部门的支持合同”的想法又引出了另一个问题。聚合商需要夸大开源生态系统的复杂性。实际上，少数产品比其他产品更重要。为“大象”获取真正的企业级支持；然后担心“狗和猫”。客户不能通过想象与聚合商的“支持”合同意味着他们可以为所欲为来逃避管理开源使用的责任。这个问题与商业软件的情况大不相同，尽管开源软件是免费获取的，这在当前情况下造成了危险。

让我引用我原帖的结论

也许在某些领域，这种模式是合理的。有些产品（主要在企业领域之外，或在更简单的技术中）大部分工作是由志愿者完成的。但在企业 Java 领域，这完全没有意义。问题不在于聚合的概念——如果一个公司拥有投资和维持项目的资源，或者与拥有这些资源的公司合作——而是一个行业可以在无视经济规律的情况下得以维持，并且用游戏机而不是收入保障来激励人们将为企业级支持提供基础的想法。

事实证明，开源软件（不包括商业附加产品）中最具可扩展性的收入是支持。OpenLogic 的模式将这种支持完全与软件的创建本身分开了。这并非企业开源的未来——除非开源没有未来。

我坚持我的评论。