在题为“关于Interface21的废话”的文章中，一位SourceLabs的员工不同意我的观点，即提交权限对于提供可信赖的开源支持是必要的。

在我回复之前：我想再次把一件事情说得非常清楚，我在上一篇博客中已经说过，但似乎被一些人误解了：Interface21 无意阻止他人通过 Spring 赚钱。我们的过往记录证明了这一点。我们欢迎他人撰写关于 Spring 的文章，提供 Spring 服务。或者基于 Spring 构建产品，就像 Matt Raible 的 AppFuse。我们祝他们成功。Spring 之所以取得今天的成就，部分归功于其丰富生态系统的支持。作为技术人员和一家公司，我们一直以来都支持这一点，并且将来也会继续支持。

我的观点是评论某一家特定公司中的某一个特定个人，他声称开源是由无偿的业余爱好者编写的，并且在经济上奖励开源知识产权的开发是无关紧要的。

致博客

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

这当然是胡说八道。让我来转述一下

Rod 声称，可靠的汽车维修需要训练有素的机械师。这对世界上所有其他车库里非机械师的员工来说，肯定是个惊喜。有人必须负责销售、经营业务、修复建筑物、更新网站、寻找新客户等等。机械师并不能带来这些，谁能告诉我，这些对于一个成功的车库来说不是必需的呢？

当然，能够提供三级支持的提交者只是支持公司的一部分——没有人说过别的。但就像车库一样，如果你没有那些能处理棘手问题的人，其他一切都无济于事。例如：在我保养汽车的地方，接待员效率很高，很友好（而且很漂亮）。这很棒。等候区有舒适的沙发、咖啡和有趣的读物。但接待员和物理环境只是一个庞大机器的一部分，它从根本上向我保证，训练有素的机械师能够修理我的汽车，并且拥有所有必要的设备和零件。

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

尽管 Rod 会让你相信，但我（或其他人）可以提供顶级 Spring 支持，这要归功于 Spring 使用的 ASF 许可证。你不必成为 Spring 提交者才能修复其中的错误，你也不需要 Interface21 的许可或认可才能使用它。如果有一个影响你生产服务器的错误，我可以自己查看代码，与客户沟通，并找出最佳解决方案：补丁、变通方法、客户端代码更改等。我之所以能做到这一点，是因为我能够访问重要的源代码——即客户正在使用的那个——并且因为我通过仔细而繁琐的准备，理解了客户的需求。

胡说八道。我已经在业务模式的可持续性方面阐述了我的观点。让我们从纯粹的技术角度来考虑。关于开源的一些基本要点：

1. 非提交者无法保证任何内容能够进入项目代码库。
2. 提交权限是赢得的
3. 提交权限代表着一种承诺
4. 并非所有提交者都一样。提交者和赢得权限的努力将永远持续下去。
5. 要可靠且可持续地完成某项工作需要深度。

让我们更详细地看看。

1. 非提交者无法保证任何内容能够进入项目代码库。 这是不言而喻的。他们可以贡献补丁，但无法保证补丁会被接受。这可能会导致客户的解决方案打上了补丁，而在产品下一次发布时需要重新审视，这可能会阻碍客户充分享受软件进化的全部好处。即使错误报告是正确的，并且补丁确实有用，通常我们会看到，整天与软件打交道的提交者会选择一种不同的、更好的方法来修复错误。这对客户来说也是同样的问题。客户不想使用一个分叉版本的软件。
2. 提交权限是赢得的。 提交权限是通过与社区长期互动、展示技术技能、提交高质量补丁、持续投入的证据以及不只是为了经济利益而修补偶尔的错误，而是要为产品的进化做出贡献而赢得的。例如，我现在可以想象，你的销售副总裁会阅读这次交流，担心在销售场合会遇到棘手的问题，然后说“我们不能找个 Spring 提交者来吗？”但这并不能改变这样一个事实：你们公司已经有两年（或无论你们公司存在多久）的时间来表现出对推动 Spring 发展的兴趣，并且一直乐于让其他人做所有繁重的工作，只要你们试图坐享其成。
3. 提交权限代表着一种承诺。提交给一个开源项目就像养狗一样；一旦你选择了养狗，你就不能在 6 周后就厌倦它而抛弃它。否则，你就是要求别人为你收拾烂摊子。
4. 并非所有提交者都一样。 在每个开源项目中都会演变出一种提交者权威的等级制度。领导者经常会重写更初级提交者的提交；他们的更改不一定能得以保留。任何管理良好的软件项目都会发生同样的情况。
5. 要可靠且可持续地完成某项工作需要深度。 要提供任务关键型的 24x7 支持，你需要多人能够修复软件并协同工作。

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

你不必成为 Spring 提交者才能修复其中的错误，你也不需要 Interface21 的许可或认可才能使用它。

这是帖子里几个稻草人论证中的又一个。我什么时候说过你需要我们的许可或认可才能使用 Spring？

查看你们的网站，SourceLabs 对开源项目的贡献似乎比 OpenLogic 更多（尽管肯定不是对 Spring）。这使得你不同意我的帖子显得有些令人惊讶。

但同样，这又回到了我的主要观点：即使这种试图通过支持来赚钱，而又没有对项目做出深度承诺的模式能够奏效（实际上是无法可靠奏效的），除了在出现问题时（并且你有付费客户）之外，你对项目没有任何贡献。你对推动软件前进没有任何贡献；你依赖其他人来做这件事，以便你有东西可以变现。你希望那些人足够天真，可以免费为你做这些，而你则完全放弃了推动项目蓬勃发展以创新并满足用户不断变化的需求的必要性。同样，如果其他人能做到这一点，那也很棒。

良好的支持意味着你与客户建立了个人关系。你知道他们的需求，他们正在使用哪些其他软件，他们最关心什么，并且你与他们建立了信任的纽带，让他们知道你会一直在那里支持他们。这远远超出了给他们一个寻呼机号码并说：“如果出了问题就给我打电话”。

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

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

Interface21 所做的就是诚实地告知客户它提供什么和不提供什么，它可以在哪里提供坚如磐石的支持，又在哪里不能。我还应该指出，我们在企业 Java 领域拥有无与伦比的技术人才深度（可以看看我们的人员页面），并且正日益深入地参与到更多的项目中。据我从你们的网站上了解，SourceLabs 仅在 Apache Commons 项目中做出了显著贡献：这 hardly 是企业核心，而且是通过一个人完成的。所以基本上你在抱怨我过于谦虚的声明。

我希望 Interface21 并不是害怕来自那些明白做好支持比拥有一个 SVN 账户复杂得多的公司的激烈竞争。

我们有很多满意的客户，我们正经历着创纪录的支持销售季度，并且拥有非常强大的企业交易渠道，所以我们 hardly 害怕竞争。我之前的博客解释了为什么我们真的能做好支持，通过“天涯比邻”模式。据我所知，Interface21 的规模是 SourceLabs 的数倍，并且增长得更快，所以你 hardly 有资格教训我们。哦，而且鉴于你个人能够提供一流的 Spring 支持，我认为你本应知道 Spring Framework 的代码库是 CVS，而不是 SVN。

当然，Rod。你想销售 Spring 支持，请便。在市场上玩弄你所有的优势，但这是一个市场。如果你想争辩说控制提交者使你成为最佳支持选项，尽管去做吧，但如我上面所说，这是一个相当薄弱的论点。

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

你想销售 Spring 支持，请便。 作为 Spring 的创始人兼联合负责人，我很感激你的允许。这非常慷慨。

但这与我的主要观点无关，我的主要观点是，要可信地支持开源，并使其足够可持续，以确保长期生产企业级开源产品，你不能只是试图从支持收入中获利：你必须投入大量的精力和投资。

我认为大家的立场都已反复陈述，而且我认为延长讨论的价值不大。

我欢迎人们围绕 Spring 或任何其他东西赚钱。我只是认为任何企业都应该对其能提供的范围和质量保持开放。