我几个月前关于开源商业模式的博客似乎引起了共鸣。我收到了许多积极的回应，并引来了来自一个名为“How Software is Built”的网站的采访请求。我的采访内容在此。

最终，OpenLogic 的某人发表了一篇有趣的回应。Bryan Noll 在我的博客回复中留下了一些值得正式回应的评论。

首先，我认为您关于那些对某个特定项目没有真正投入的人为其提供支持，对该项目或整个开源生态来说是不健康的说法很有趣……是我以前从未听过的观点。我认为这个观点有足够的说服力，足以让我们这样的公司考虑并认真审视我们对所支持的开源项目的责任。在我看来，这种审视的结果将是 OpenLogic 为了缓解您提出的潜在担忧而制定的一项可证明的政策。我确定我不知道具体会是怎样的政策，所以请允许我在此处保持模糊。不过，这恰好与您所说的一些我存在异议的问题不谋而合。

我认为找到这样一项“可证明的政策”会非常简单。OpenLogic 需要明白，Stormy 的文章中的开篇评论“从事开源软件开发的开发者通常有报酬不错的工作……所以他们免费从事开源软件工作，白天为高薪编写代码”在很大程度上是错误的，需要理解他们希望从中获利的开源软件来自何处，建立适当的合作伙伴关系，并设定一个能够提供真正支持的价格点。另一种选择是停止声称提供企业级支持，明确说明所提供的只是某种随叫随到的开发协助，不保证能够解决关键问题。这让我回到了为何我觉得 Stormy 的文章如此重要，需要进行剖析的原因。

我认为这种聚合模式就像超市生意。当我在超市购物时，我期望他们会从我购买的所有商品中收取（很小的一部分）提成，作为回报，他们与许多供应商打交道，将我想要的所有商品都集中到一处，并提供停车场和购物车。我期望大部分经济价值会回流到生产产品的公司。

OpenLogic 和他们的几个竞争对手有机会开展超市式的业务。只是他们似乎希望，作为一个新市场的开源，允许一种超市模式，即几乎保留所有收入，而不向供应商支付报酬。这是一种破坏性的模式，长期来看无法生存。

有更可持续的聚合途径。许多全球性的系统集成商（SI）向客户提供包含聚合服务的支持合同，并且为了提供企业客户所需的支持质量，他们会将部分工作分包给各种开源公司。换句话说，他们的目标不是保留超市里商品的所有收入，而是将提供真正的支持计入价格。OpenLogic 也应该这样做。他们不这样做，也许是因为承认聚合商实际上是经纪人，会让他们在大系统集成商和创建开源知识产权的专业公司之间处于尴尬境地。尽管如此，那里存在一个可持续的商业机会。

Bryan 继续说道

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

我的“支持”可能来自非提交者。因此 OpenLogic 无法保证策略性地解决问题。可靠的支持包括提交到主分支的能力——以及在某些情况下，维护针对特定客户版本的独立分支的能力。

值得注意的是，对于 Spring 而言，Interface 21 将是唯一能够做到您所提出事情的实体。（如果我错了，请纠正我。）这对 Interface 21 来说似乎是一笔不错的交易。

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

所以您似乎在争辩说，OpenLogic 不能从他人的辛勤工作和投入创造的代码和社区中赚钱，这 somehow 是不公平的。我无法通过支持，比如 PhP、WebLogic 或 Oracle 来赚钱，这公平吗？BEA 主导 WebLogic Server 维护收入市场，这对于 BEA 来说是否是一笔不合理的“甜蜜交易”？

这种围绕“公平”的站不住脚的论点忽略了 OpenLogic 是否能够“策略性地解决问题”这个实际问题。出于我所描述的原因，OpenLogic 无法做到这一点。

如果你开源了你的东西，而且它是一个像你的产品一样大受欢迎的优秀产品，你真的期望市场上没有人会试图围绕它开展业务吗？当然不是……再举个例子，看看那些不是由 Interface 21 员工撰写的关于 Spring Framework 的书籍，或者市场上无数的开发者，他们因为学会了你开源的框架而变得非常有市场价值。他们也应该为项目的健康状况感到内疚吗？Interface 21 之所以能够获得如此巨大的利益，是因为该产品 A) 很棒，而且因为该产品 B) 被大规模地推向市场，因为你已经将它开源并使其免费。虽然不完全相同，但这个论点带有“因为我发明了汽车，所以其他人都不应该制造和销售汽车”的感觉。

其他公司和个人不可避免地会围绕产品开展业务，这很好。然而，审查他们提出的任何主张也是公平的。

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

至于那些因为学习了 Spring 而更具市场价值的开发者，这太棒了。我为创建了一个帮助为我的同行开发者创造市场的项目（也让他们的工作更愉快）感到自豪；我很高兴我的公司持续投入到我们的产品中，继续壮大这个市场。现在每天都有成千上万的招聘信息将 Spring 列为必需技能，并且它们正在迅速呈上升趋势；祝愿所有申请这些职位的应聘者，在他们回答 Spring 相关问题时一切顺利。

作者和成千上万的这些开发者通过他们的推广布道为项目的成功和社区做出了贡献。这是一种重要的贡献方式。OpenLogic 则不然；它仅仅旨在从他人已经构建、推广并维护和增强的项目中赚钱。现在，那才是一笔“轻松的交易”。

我的文章关注的是企业级支持的提供。这是另一回事。OpenLogic 不仅仅是声称他们可以以这种方式提供关于 Spring 的知识，或者帮助交付基于 Spring 的项目；它声称可以为许多项目提供企业所需的支持水平。我详细阐述了为什么它做不到这一点。

请注意，我的博客关注的是一个更普遍的问题，即开源的企业级支持质量。虽然我现在直接回应您关于 Spring 的问题，但这种模式的缺陷适用于许多项目。

你段落的第一句话值得再回复一次

如果你开源了你的东西，而且它是一个像你的产品一样大受欢迎的优秀产品，你真的期望市场上没有人会试图围绕它开展业务吗？

现在我想知道它为什么是一个优秀产品？为什么会大受欢迎？这是偶然发生的，还是大量持续投入的结果？

其次，虽然我再次承认您关于潜在的项目健康影响的观点很有道理，但推动市场聚合支持的另一个事实依然存在。如今企业为了获得他们正在开发和部署到生产环境中的软件支持，需要经历一个艰辛的过程……在我看来，在 y 个各自为政的部门管理 x 个项目的支持合同就像一场低效的噩梦。从企业的角度来看，聚合这些服务是有意义的，无论您认为它多么目光短浅。如果市场上存在商机，您就不能责怪别人抓住并利用这个机会。

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

“在 y 个各自为政的部门管理 x 个项目的支持合同”这个想法引出了另一个问题。聚合商需要夸大开源生态系统的复杂性。实际上，少数产品比其他产品更重要。为“大象”产品（指重要的、广泛使用的产品）获取真正的企业级支持；然后再去担心那些“猫猫狗狗”（指不那么重要或小众的产品）。客户不能指望通过与聚合商签订“支持”合同来逃避管理其开源使用的责任，以为这样就可以随意使用。这个问题与商业软件没有太大区别，尽管开源软件免费获取的事实在此情况下带来了一定的风险。

让我引用我原文的结论

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

事实证明，围绕开源软件（不包括商业附加组件）最具可扩展性的收入来自支持服务。OpenLogic 的模式完全将支持服务与软件的创建本身割裂开来。这不是企业级开源的未来——除非开源没有未来。

我坚持我的观点。