关于开源的废话生产是一个竞争激烈的领域。然而，我刚刚看到了一些东西，它提高了（降低了？）门槛：一篇由 OpenLogic 博客作者撰写的帖子，题为你的时间值多少钱？

它不长，这很方便，因为它更容易逐段解构。我专注于企业 Java，对此我可以根据经验发言。

博主立即切入正题，用简洁的声明表达了她不理解企业级开源的原因

从事开源软件开发的开发人员通常都有不错的日常工作收入。因此，他们免费从事开源软件开发，并在白天编写代码以获取高额报酬。

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

为了消除 Linux 是由大量孤立工作的独立黑客拼凑而成的看法，负责管理 Linux 内核的个人表示，大多数 Linux 改进现在都来自公司。“人们对（典型 Linux 开发人员的）刻板印象是一个男程序员宅在地下室，利用业余时间编写代码，纯粹出于对技艺的热爱。这类人直到大约五年前都是一股重要的力量，”Andrew Morton 说，他的职责是维护 Linux 内核的稳定版本。Morton 说，来自这类爱好者的贡献“正在减弱”。相反，大多数代码是由按公司考勤钟工作的程序员生成的。Morton 说，大约有 1000 名开发人员定期为 Linux 贡献更改。在这 1000 名开发人员中，大约有 100 人由他们的雇主付费为 Linux 工作。而这 100 人贡献了操作系统最后 38000 次更改中的大约 37000 次。

这意味着 97% 的提交来自受薪为 Linux 工作的人。这种转变与 Linux 在企业中日益普及相对应。查看企业 Java 中最成功的复杂项目，如 Spring、Hibernate 和 JBoss，也显示出类似的景象。所有这些项目绝大多数都是由为项目背后的公司工作的开发人员编写的。志愿工作所占比例很小。因此，这些产品表现出快速发展。

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

那么，这意味着如果我在工作时每小时赚 50 美元，我宁愿免费帮助当地学校搭建网络，也不愿以每小时 10 美元的价格去承担搭建网络的工作吗？虽然听起来很奇怪，但我认为这是真的。作为一个免费提供服务的志愿者，我拥有更多的控制权（我可以随时离开），更多的声望（我在做贡献！），以及更多的认可（我不是一个卑微的打工者，我是一个很酷的志愿者）。

这恰恰解释了博客中提出的模型为何不合理。如果企业开源依赖于志愿服务，那么开发者就会随时可能离开。让我们假设我是一家排名前十的银行。想象一下，我的关键任务软件的开发和维护竟然依赖于业余爱好者的热情，这会让我作何感想？至于声望和认可：当然，这很重要。大多数做出杰出事情的人在一定程度上都受到认可的驱动。员工也需要认可，而不仅仅是薪水。但如果将此作为主要动机，那将是长期的灾难。当某人的工作令人失望需要重写时会怎样？那个人会赌气离开吗？当工作不“酷”时又会怎样，比如写文档或在晦涩的环境中重现一个难以捉摸的 bug？当由个人自我驱动的开发者发生冲突时又会怎样——如果他们是根据自我大小自我挑选的，这种情况很可能发生。有许多项目因这种冲突而分崩离析的例子。如果一个开发者必须熬夜帮助诊断和解决签订了支持合同的客户遇到的 1 级生产问题，又会怎样？没有对“全天候支持”能力的投入，24x7 的 SLA 如何运作？

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

虽然 Gartner 可能会进行数字分析，但博主声称从事开源工作本质上就是经济活动之外的范畴。

作为廉价的熟练劳动力，我所做的就是降低我的时薪价值。我现在说我的价值只有 10 美元/小时——我在廉价工作，而不是帮助那些需要帮助的人。

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

我不是说这有道理，也不是说这是好事，但我认为这是现实。你怎么看？

我认为这并非现实是幸运的，因为它一点道理都没有，是一件非常糟糕的事情，并且有可能摧毁软件行业。

博客总结说

这也是我们努力确保 OpenLogic Expert Community 公平补偿的原因之一。

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

我能从加入专家社区中获得报酬吗？ 是的，OpenLogic Rewards 项目会根据成功解决的事件向专家社区成员支付积分（可兑换现金或奖励）。OpenLogic 向企业收费以提供支持。OpenLogic 的内部技术支持团队会解决基本问题。OpenLogic 反过来又会与社区成员签订合同，以解决更复杂的问题。

对，它是这样运作的。OpenLogic 希望企业客户预先支付支持合同的费用。OpenLogic 似乎不相信支付开发者薪水，所以他们预计自己无法处理复杂支持问题。在这种情况下，他们会联系“社区”，并且只在事件解决后才支付。它的运作方式是这样的：

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

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

与开发人员的薪水相比，25 美元的临时费率并不算高。然而，这也许不算太差，因为如果你是一个想出头的开源开发者，加入专家社区是有可能的。不像你需要为项目做出重大贡献。我的重点是

加入专家社区需要具备哪些资质？ 您需要填写一份简短的会员申请表。我们正在寻找我们支持的 200 多个开源项目的提交者或贡献者。如果您不是项目提交者，我们将要求您提供一位项目提交者的推荐信来赞助或担保您。OpenLogic 的专家社区计划是提升您经验和项目贡献的绝佳途径。

如果我是一名客户，这不会让我感到有信心。我的“支持”可能来自非提交者。所以 OpenLogic 无法保证战略性地解决问题。可靠的支持涉及提交到主干的能力——以及在某些情况下，为特定客户版本维护的分支。它还涉及团队，而不是可能非常初级的个人。我不太可能接触到实际编写与我事件相关的代码的人。

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

这个模式有很多缺陷，但有一个巨大的问题，你可以轻松地绕过它。开发者只有在解决事件时才能获得报酬。没有人得到报酬来编写软件。没有人得到报酬来创新。没有人得到报酬来记录。没有人得到报酬来重构和改进设计。所以 OpenLogic 对他们希望从中获利的项目的贡献是零。从 OpenLogic 的角度来看，这没关系：如果一个项目崩溃了，他们可以转向另一个项目，因为他们为所有项目提供类似的“支持”。但从企业客户的角度来看，这可能几乎是灾难性的，因为他们可能需要运行他们今天引入的软件多年。

常见问题解答中的关键答案是：

我能赚到足够全职工作的钱吗？ 目前，我们不建议任何人辞职成为专家社区成员。

没错。我们谈论的是软件行业中一个快速增长且至关重要的领域。而这种模式并没有给任何人带来从开发出色软件中谋生的能力。如果开源的后果是人们无法从开发出色软件中谋生，那么每个人都将遭受损失。你无法将维护软件的过程与创建软件的过程分离开来。

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

事实证明，开源软件（不考虑商业附加组件）最具可扩展性的收入来自支持。OpenLogic 的模式将这一点完全与最初的软件创建过程分离开来。这并非企业开源的未来——除非开源没有未来。