在标题恰当的《关于 Interface21 的胡言乱语》一文中，一位 SourceLabs 员工不同意我的观点，即提交权限对于提供可信的开源支持是必需的。

在我回复之前：我想再次完全澄清我在上一篇博客中已经说过但似乎被某些人误解的一点：Interface21 无意阻止他人从 Spring 盈利。我们的记录证明了这一点。我们欢迎其他人撰写关于 Spring 的文章并提供 Spring 服务。或者像 Matt Raible 的 AppFuse 那样，将产品基于 Spring。我们祝他们成功。Spring 之所以能取得今天的成就，部分原因在于其丰富的生态系统。作为技术人员和一家公司，我们一直并将永远培育这种生态。

我的观点是针对一家特定公司的一位特定个人的评论，该个人声称开源是由无偿的业余爱好者编写的，并且从经济上奖励开源 IP 的开发是无关紧要的。

到博客文章

Rod 声称可靠的支持需要对源代码的提交者权限。这对于世界上所有其他支持公司雇佣的非工程师来说一定是个惊喜。总得有人负责销售、经营业务、修复服务器、更新网站、寻找新客户等等。提交者权限并不能帮你做这些，谁会告诉我这些对于一家成功的支持公司来说不是必需的？

这当然是胡言乱语。让我来打个比方

Rod 声称可靠的汽车维修需要训练有素的技工。这对于世界上所有其他修车厂雇佣的非技工来说一定是个惊喜。总得有人负责销售、经营业务、修理厂房、更新网站、寻找新客户等等。技工并不能帮你做这些，谁会告诉我这些对于一家成功的修车厂来说不是必需的？

当然，能做三级支持的提交者只是支持公司的一部分——没人说过有什么不同。但就像修车厂一样，如果你没有能处理棘手问题的人，其他一切都不重要。例如：我修车的地方，接待员效率高、友好（而且很火辣）。这很棒。等候区有舒适的沙发、咖啡和有趣的读物。但接待员和物理环境只是整个体系的一部分，这个体系从根本上向我保证，训练有素的技工能够修理我的车，并且拥有所有必要的设备和获取所需所有零件的途径。

再说说销售人员。如果你没有销售人员，你就无法发展软件业务。但如果你有销售人员却没有人能提供真正的客户价值，你的业务就不可持续。(尽管从短期商业角度来看这很有吸引力——考虑到我们每年数百万美元的工程预算，我能理解拥有一家不需要进行如此规模投资的公司为何具有吸引力。)

尽管 Rod 想让你相信，但我（或任何人）都可以提供高质量的 Spring 支持，这得益于 Spring 使用的 ASF 许可证。你不需要成为 Spring 的提交者来修复其中的 Bug，你也不需要 Interface21 的许可或背书来使用它。如果存在影响你生产服务器的 Bug，我可以在代码中自行找到，与客户交流，并找出最佳解决方案：补丁、变通方法、客户端代码修改等。我能做到这一点是因为我能访问关键的源代码——客户正在使用的源代码——并且因为我通过仔细而繁琐的准备，了解客户的需求。

胡言乱语。我已经阐述了围绕商业模式可持续性的论点。让我们从纯技术的角度考虑问题。关于开源的一些基本点

1. 非提交者无法保证任何东西进入项目代码库。
2. 提交权限是赚来的
3. 提交权限代表着承诺
4. 并非所有提交者都平等。承诺和赚取是持续不断的。
5. 可靠且可持续地完成某事需要深度。

让我们更详细地看看。

1. 非提交者无法保证任何东西进入项目代码库。 这不言自明。他们可以贡献补丁，但无法保证补丁会被接受。这可能会使你的客户使用一个打了补丁的解决方案，该解决方案需要在产品下一次发布时重新检查，这可能阻碍客户从软件的演进中获得全部好处。即使 Bug 报告是正确的并且补丁确实有用，通常我们看到整天处理软件的提交者会选择一种不同且更好的修复方法。这对客户来说是同样的问题。客户不希望使用软件的分支版本。
2. 提交权限是赚来的。 提交权限是通过长期参与社区；展示出技术技能；提交高质量的补丁；证明持续的承诺；不仅仅是为了经济利益偶尔修复 Bug，而是渴望为产品的演进做出贡献而赚取的。例如，现在我想你的销售副总裁会读到这段对话，担心在销售场合遇到棘手的问题，然后说“我们不能直接找一个 Spring 提交者吗？” 这不会改变你已经有两年（或者你的公司成立了多久）来表现出推动 Spring 向前的兴趣，而一直满足于让其他人承担所有繁重工作，只要你试图坐在收银台前收钱这一事实。
3. 提交权限代表着承诺。为一个开源项目提交就像养狗一样；一旦你选择养狗，就不能在六周后就厌倦并遗弃它。否则你就是让别人来为你收拾烂摊子。
4. 并非所有提交者都平等。 在每个开源项目中都会演变出提交者权限的层级。领导者通常会重写来自更初级提交者的提交；无法保证他们的更改会保持不变。在任何运行良好的软件项目中都会发生完全相同的情况。
5. 可靠且可持续地完成某事需要深度。 要提供关键任务的 24x7 支持，你需要多人能够修复软件并协同工作。

声称你能提供与实际编写代码的人员相同质量的支持是荒谬的。你能在多快的时间内找到修复 Bug 的最佳方法？那些人整天都在研究它，并且做了最初的设计。让我们考虑一个具体的支持问题。一位 SourceLabs 员工甚至附和了一位 Spring 用户报告的问题。这个问题最终由 Spring（和 Interface21）的联合创始人 Juergen Hoeller 解决。

你不需要成为 Spring 的提交者来修复其中的 Bug，你也不需要 Interface21 的许可或背书来使用它。

这是这篇文章中的几个稻草人论点之一。我哪里说过你需要我们的许可或背书才能使用 Spring？

查看你的网站，SourceLabs 似乎比 OpenLogic 对开源项目贡献更多（尽管对 Spring 没有任何贡献）。这使得你不同意我的文章显得很意外。

但话又说回来，我的主要观点是：即使这种在不对项目做出深度承诺的情况下试图从支持中获利的模型能起作用（这并不可靠），你对项目零贡献，除了当出现问题（并且你有一个付费客户）时。 你对推动软件向前发展没有任何贡献；你依赖其他人来做这件事，以便你能从中盈利。你希望这些人足够天真，会免费去做，而你完全忽视了需要大力推动项目向前发展以创新并满足用户基础不断变化的需求。再说一遍，如果其他人做这些事情，那是件好事。

好的支持意味着你与客户建立了个人关系。你知道他们需要什么，他们正在使用什么其他软件，他们最担心什么，并且你与他们建立了信任关系，让他们相信你会一直在他们身边。这远远超出了给他们一个寻呼机号码然后说“如果坏了就给我打电话”。

显然。所有这些都很重要，并且是完整图景的一部分。这与当前的讨论无关，因为没有人说过不是这样。我们的客户对我们所有的服务都给予高度评价：支持、培训和咨询。

Interface21 的任何人都不能认真声称自己积极参与完整的 Java 企业堆栈的其他部分；Spring 尽管很棒，但它是一个框架，而不是一个堆栈。它不能提供企业客户所需的一切，只支持 Spring 对于那些还需要 Hibernate 或 Struts 帮助的公司来说是不够的。事实上，Rod 不得不说，如果你确实需要 Java 解决方案其他部分的帮助，Interface21 无法帮助你，因为他们不控制这些项目的源代码。

Interface21 所做的是对客户诚实地说明它提供什么和不提供什么，在哪里可以提供坚实的支持，在哪里不能。我还应该指出，我们在企业 Java 领域拥有无与伦比的技术深度（看看我们的团队页面），并且正在越来越深入地参与越来越多的项目。据我从你的网站上了解，SourceLabs 对 Apache Commons 做出了显著贡献：这几乎不是企业的核心，而且只通过一个人。所以本质上你是在抱怨我对自己的主张非常谦虚这个事实。

我希望 Interface21 不仅仅是害怕来自那些理解做好支持比拥有一个 SVN 账户复杂得多的小公司的竞争。

我们有很多满意的客户，我们的支持销售创下了季度记录，并且有一系列非常强大的企业交易待处理，所以我们根本不害怕竞争。我之前的博客解释了为什么我们确实能够做好支持，采用“跟随太阳”模式。据我所知，Interface21 比 SourceLabs 大好几倍，而且增长速度快得多，所以你根本没资格对我们摆出高高在上的姿态。哦，考虑到你个人能够提供一流的 Spring 支持，我以为你应该知道 Spring Framework 的代码库是 CVS，而不是 SVN。

当然，Rod。你想卖 Spring 的支持服务，请便。在市场上尽情发挥你的所有优势，但这是一个市场。如果你想争辩说对提交者的控制使你成为最好的支持选择，尽管说，但就像我上面说的，这是一个相当站不住脚的论点。

当然这是个市场。我从未说过不是。我只是在解释为什么我们的 Spring 支持是无与伦比的。

你想卖 Spring 的支持服务，请便。 作为 Spring 的创始人兼联合负责人，我很感谢你的许可。真是太慷慨了。

但那只是附带的，我的主要观点是，要以可持续的方式可信地支持开源，确保长期生成企业级开源，你不能只想着从支持收入中获利：你必须投入大量的精力和投资。

我认为到目前为止，每个人的立场都已反复阐述，延长讨论没有多大价值。

我欢迎人们围绕 Spring 或其他任何事物赚钱。我只是认为任何企业都应该公开说明其能提供的服务范围和质量。