关于开源的无稽之谈是一个竞争激烈的领域。然而，我刚刚看到一篇文章，它提高了（或降低了？）门槛：一篇 OpenLogic 博客作者题为你的时间值多少钱？的帖子。

这篇文章不长，这很方便，因为它更容易逐段解构。我关注的是企业级 Java，这方面我可以凭经验发言。

博主开门见山，用一个简洁的陈述解释了她为何不理解企业中的开源

从事开源软件开发的开发者通常有份薪水不错的工作。所以他们免费为开源软件工作，而在白天为高薪写代码。

哇，我以为我们多年前就摆脱了这种“业余爱好者”的想法。让我引用一些关于 Linux 的统计数据，来自 2004 年的一篇题为Linux 现在是一个企业巨兽的文章。我的重点如下

驳斥 Linux 是由大量独自工作的孤立黑客拼凑而成的看法，负责管理 Linux 内核的人士表示，目前大多数 Linux 改进来自公司。“人们对典型 Linux 开发者的刻板印象是，一个男电脑极客在他的地下室利用业余时间写代码，纯粹出于对手艺的热爱。这样的人大约在五年前还是重要的力量，”负责维护稳定版 Linux 内核的 Andrew Morton 说。Morton 表示，这些爱好者做出的贡献“正在减弱”。相反，大多数代码是由按公司工时工作的程序员生成的。Morton 说，大约有 1000 名开发者定期为 Linux 贡献更改。在这 1000 名开发者中，约有 100 人由他们的雇主支付薪水来从事 Linux 工作。而这 100 人贡献了操作系统最近 38000 次更改中的约 37000 次。

这意味著 97% 的提交来自那些被支付报酬来从事 Linux 工作的人。这种转变与 Linux 在企业中日益增长的渗透率相对应。看看企业级 Java 中最成功的复杂项目，如 Spring、Hibernate 和 JBoss，也呈现出类似的景象。所有这些项目绝大部分是由为这些项目背后的公司工作的开发者编写的。志愿者活动只占很小的一部分。因此，这些产品展现出了快速的进展。

这篇文章现在转向了经济学——或者更确切地说，试图论证开源软件的开发与经济学是脱节的

所以这意味着如果我在工作中每小时赚 50 美元，我会宁愿免费帮助当地学校设置网络，而不是以每小时 10 美元的价格接受这项工作？听起来很奇怪，但我认为这是事实。作为免费的志愿者，我获得更多的控制权（我可以随时离开），更多的声望（我在帮忙！），更多的认可（我不是一个低微的下属，我是一个很酷的志愿者。）

这正是为什么博客中提出的模型没有意义的原因。如果企业开源依赖于志愿者活动，开发者就很容易随时离开。假设我是一家排名前 10 的银行。想象一下，我的关键任务软件的开发和维护与爱好者的热情挂钩，这会让我有什么感觉？至于声望和认可：当然，这很重要。大多数做出杰出成就的人在一定程度上受到认可的激励。员工除了薪水外也需要认可。但如果将这作为主要动机，从长远来看将是一场灾难。当某人做的事情令人失望并被重写时会发生什么？这个人会生气地离开吗？当工作不“酷”，比如写文档或在一种深奥的环境中重现一个难以理解的 bug 时会发生什么？当受个人自我驱动的开发者发生冲突时会发生什么——如果他们是由自我大小自行选择的，这种情况很可能发生？有许多项目因这种冲突而分崩离析的例子。如果一名开发者不得不熬夜帮助诊断并解决与有支持合同的客户的一级生产问题时会发生什么？如果没有对全天候支持能力的投入，24x7 服务水平协议（SLA）如何运作？

开发高质量的软件需要一个由敬业的个人组成的有效团队。这些人需要留下来，这需要一个可行的经济模式。开发者需要支付房贷、学费、燃油以及现代生活的所有其他费用，试图回避这个问题并将其留给提供“日间工作”的雇主是幼稚的（或更糟）。很少有人能够对支持一个项目做出无限期的个人时间承诺；他们会希望他们的工作能为他们带来经济利益。（为什么不呢：它也为用户提供了经济利益？）这件事如此重要的原因在于，开源在企业中的作用变得越来越重要，不能仅仅依赖纯粹的志愿者活动。正如 Entiva Group 分析师 Alex Fletcher 所写，“今年早些时候，Gartner DataQuest 报告称，2006 年至 2011 年间开源软件的复合年增长率（CAGR）为 43%，将是专有软件（8%）的五倍以上。该公司还预计 2007 年开源软件销售额将达到 42.3 亿美元，到 2010 年将增长三倍，达到 131.0 亿美元。”除非开源长期以来有可持续的模式，否则潜在的不可靠软件会非常多。

尽管 Gartner 可能分析数字，但博主声称从事开源工作本质上是经济活动之外的事情

作为廉价的熟练劳动力，我所做的就是降低了我每小时的价值。我现在说我只值每小时 10 美元——我为了微不足道的报酬工作，而不是帮助需要帮助的人。

所以理想情况下，开源开发者不应该获得报酬，因为那样会降低他们日间工作的时薪。我们稍后会谈到 OpenLogic 的支付模式，但这似乎与此观点一致。虽然开发者不应该考虑金钱，但 OpenLogic 自然不在经济活动的范畴之外。

我不是说这完全有道理或者这是一件好事，但我认为这是一个现实。你觉得呢？

我认为幸运的是这并非现实，因为它根本毫无意义，是一件非常糟糕的事情，并可能摧毁软件产业。

博客总结道

这是我们努力确保 OpenLogic 专家社区得到公平补偿的原因之一。

所以我点击了他们“专家社区”的常见问题链接，想了解这在实践中是如何运作的。有趣的答案是

成为专家社区成员是否有报酬？ 是的，OpenLogic 奖励计划会根据成功解决事件，以积分（可兑换现金或奖励）的形式支付专家社区成员报酬。OpenLogic 向企业收取支持费用。OpenLogic 内部技术支持团队解决基本问题。OpenLogic 转而与社区成员签约解决更复杂的问题。

对了，它是这样运作的。OpenLogic 希望企业客户预先支付支持合同费用。OpenLogic 似乎不相信支付开发者薪水，所以他们预计自己无法内部处理复杂的支持问题。在这种情况下，他们就会寻求“社区”的帮助，只有在事件得到解决后才支付报酬。这就像这样运作

作为专家社区成员我需要做什么？ 作为成员，您将可以访问我们需要帮助解决的客户事件列表。您可以通过在专家社区成员门户中“获取”这些事件来选择要处理的事件。一旦您注册了一个事件，我们会要求您尽快处理直到解决。大多数事件将在 4 小时内解决...通过 OpenLogic 奖励计划，您解决的每个事件将获得 100 分。如果一个事件花费了异常长的时间来解决，您可以申请更多积分。积分可以兑换现金（100 积分 = 100 美元）或商品（例如 Xbox 360）。您也可以选择将积分作为现金捐赠给您最喜爱的开源项目或我们名单上的慈善机构之一。

所以开发者只有在发生事件时才能获得报酬。尽管注册了，除非 OpenLogic 自己解决问题遇到困难，否则他们什么也得不到。然后他们会以每小时 25 美元的名义费率获得报酬。开发者被激励尽快修复问题，因为他们不会因为优化或重构而获得报酬。（通常一个事件可能需要大量的返工才能妥善修复。这种模式下不太可能发生这种情况。）开发者自然会争夺事件，因为报酬是针对个人而不是团队的，这可能会扭曲优先级。伟大的软件需要团队合作来构建和维护，而这种模式对此没有任何奖励。也没有真正的支持团队概念。在一个真正的支持团队中，管理者不仅考虑地理分布和轮班模式以确保始终有覆盖，还要确保技能的平衡。例如，如果某个特定领域只有 2 名开发者具备专业知识，很可能会有一个计划来培养其他人，同时在这段时间内他们不太可能被批准同时休假。你不能对一个志愿者说：“抱歉，在我们找到替补之前你不能去度假——但当然，除非我们接到电话，否则我们不会支付你报酬。”

相对于开发者的薪水，每小时 25 美元的临时工资不算多。然而，这可能也没那么糟，因为如果你是一个正在崭露头角的开源开发者，你可以加入专家社区。你不需要对项目做出很大的贡献。我的重点是

加入专家社区需要什么资格？ 您需要填写一份简短的会员申请。我们正在寻找我们支持的 200 多个开源项目的提交者或贡献者。如果您不是项目提交者，我们会要求您提供一名项目提交者的推荐信或担保。OpenLogic 的专家社区计划是提升您对项目的经验和贡献的好途径。

如果我是客户，这不会让我感到信心十足。我的“支持”可能来自非提交者。因此 OpenLogic 无法保证以战略方式解决问题。可靠的支持涉及能够向主分支提交——有时也包括为特定客户版本维护的分支。它还涉及团队，而不是可能非常初级的个人。我不太可能接触到实际编写我的事件可能涉及的代码的人。

那么这里缺少了什么？让我们抛开明显的公平性问题：OpenLogic 乐于从客户那里预收固定费用，却不给做大部分工作的人带来收入保障。（他们把这留给了日间工作的雇主。）

这个模式有很多缺陷，但有一个巨大的问题足以让一辆 SUV 穿过。开发者只因解决事件而获得报酬。没有人因编写软件而获得报酬。没有人因创新而获得报酬。没有人因文档而获得报酬。没有人因重构和改进设计而获得报酬。因此 OpenLogic 对维持他们希望从中获利的项目没有任何贡献。从 OpenLogic 的角度来看，这没问题：如果一个项目崩溃了，他们可以转移到另一个项目，因为他们为所有项目提供类似的“支持”。但这对于企业客户来说可能几乎是灾难性的，他们可能需要运行今天引入的软件多年。

常见问题中的关键答案是

我是否能通过这个全职工作？ 目前，我们不建议任何人辞掉工作成为专家社区成员。

正是如此。我们正在谈论的是一个快速发展的、关键任务的软件产业的一部分。而这种模式并没有让任何人能够通过开发优秀的软件来谋生。如果开源的影响是人们无法通过开发优秀的软件来谋生，最终每个人都会受苦。你不能将软件的维护过程与软件的创建过程割裂开来。

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

事实证明，开源软件（不考虑商业附加组件）最可扩展的收入来源在于支持。OpenLogic 的模式将这一点与软件最初的创建完全割裂开来。这绝不是企业开源的未来——除非开源根本就没有未来。