在开源领域，制造胡言乱语是一个竞争非常激烈的领域。然而，我刚刚看到了一些东西，提高了（降低了？）标准：一篇由 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 美元的价格接手建立网络的工作？尽管听起来很奇怪，但我认为这是真的。作为一名志愿者免费去做，我拥有更多控制权（我可以随时离开），更多声望（我在帮助别人！），以及更多认可（我不是一个卑微的小角色，我是一个很酷的志愿者）。

这完全解释了为什么博客中提出的模型毫无意义。如果企业开源依赖于志愿者，开发人员**确实**会倾向于随时离开。假设我是一家十大银行。如果我想到我的关键任务软件的开发和维护与爱好者的热情挂钩，我会有什么感觉？至于声望和认可：当然，这很重要。大多数做出杰出成就的人在某种程度上都受到认可的驱使。员工也需要认可和薪水。但是，如果将其作为**主要**动力，从长远来看，这将是一场灾难。当某人做的事情令人失望并被重写时会发生什么？那个人会一气之下离开吗？当工作不“酷”时，例如编写文档或在奇特的环境中重现一个模糊的错误时会发生什么？当以个人自负为动力的开发人员发生冲突时会发生什么——如果他们自己选择以自负的大小来进行，这种情况很可能发生？有许多项目因这种冲突而崩溃的例子。如果开发人员必须彻夜工作以帮助诊断和解决具有支持合同的客户的 1 级生产问题会发生什么？如果没有投资于全球支持能力，24x7 服务水平协议 (SLA) 如何运作？

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

虽然 Gartner 可能在计算数字，但这位博主声称从事开源工作本质上超出了经济活动的范围。

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

因此，理想情况下，开源开发人员不应该获得报酬，因为这会降低他们日常工作的时薪。我们很快就会谈到 OpenLogic 的支付模式，但这似乎与这种观点一致。虽然开发人员不应该考虑金钱，但很自然地，OpenLogic 并没有超出经济活动的范围。

我并不是说这完全有道理，或者说这是一件好事，但我认为这是现实。你怎么看？

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

这篇博客的结论是：

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

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

**我是否因成为专家社区的一员而获得报酬？**是的，OpenLogic 奖励计划在成功解决事件后，以积分（可兑换成您选择的现金或奖励）的形式向专家社区成员支付报酬。OpenLogic 向企业收取支持费用。OpenLogic 的内部技术支持团队解决基本问题。然后，OpenLogic 与社区成员签订合同，以解决更复杂的问题。

正确，它是这样运作的。OpenLogic 希望企业客户预先支付支持合同费用。OpenLogic 似乎不相信支付开发人员的工资，因此他们预计自己将无法在内部处理复杂的支持问题。因此，在这种情况下，他们会联系“社区”，并且只有在事件得到解决时才会支付报酬。它是这样运作的

**作为专家社区的成员，我需要做什么？**作为成员，您可以访问我们需要帮助解决的客户事件列表。您可以从专家社区成员门户中“获取”这些事件，从而选择要处理的事件。一旦您签署了某个事件，我们要求您快速处理它，直到解决为止。大多数事件需要不到 4 个小时才能解决……通过 OpenLogic 奖励计划，您将获得 100 个积分作为解决事件的奖励。如果某个事件需要异常长的时间才能解决，您可以申请更多积分。积分可以兑换现金（100 个积分 = 100 美元）或商品（如 Xbox 360）。您也可以选择将您的积分作为现金捐赠给您最喜欢的开源项目或我们列表中的慈善机构之一。

因此，开发者只有在发生事件时才能获得报酬。尽管注册了，但除非OpenLogic自身在解决问题时遇到困难，否则他们什么也拿不到。然后，他们将以每小时25美元的象征性价格获得报酬。开发者有动机尽快解决问题，因为他们没有得到报酬去完善或重构代码。（通常，一个事件可能需要大量的返工才能正确修复。在这种模式下，这种情况不太可能发生。）开发者会自然地争夺事件，因为报酬针对个人而不是团队，这可能会扭曲优先级。这种模式没有奖励那种锻造和维护优秀软件的团队合作精神。也没有真正意义上的支持团队的概念。在一个真正的支持团队中，管理者不仅会考虑地理分布和轮班模式以确保始终有覆盖，还会确保技能平衡。例如，如果只有两名开发者精通某个特定领域，那么很可能会有一个培养其他人的计划，同时，他们不太可能被批准在同一时间休假。你不能对志愿者说“对不起，在你找到替代者之前，你不能休假——但当然，除非我们接到电话，否则我们不会付钱给你”。

25美元/小时的临时费率与开发人员薪资相比并不多。然而，这可能还不错，因为当你是一个正在发展的开源开发者时，你可能加入专家社区。这不像你需要对项目做出重大贡献。我的强调

加入专家社区需要具备哪些资格？你需要填写一份简短的会员申请表。我们正在寻找超过200个我们支持的开源项目的提交者或贡献者。如果你不是项目提交者，我们会要求项目提交者之一推荐或担保你。OpenLogic的专家社区计划是提升你在项目中的经验和贡献的一个好方法。

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

那么这里缺少什么？让我们先撇开公平性的明显问题：OpenLogic很乐意从客户那里预先收取固定的费用，而没有给那些做大部分工作的人提供收入保障。（他们把这留给了日常工作中的雇主。）

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

FAQ中的关键答案是

我能够靠这个全职工作吗？目前，我们不建议任何人辞去工作成为专家社区的成员。

就是这样。我们正在谈论的是软件行业一个快速增长的部分，它是任务关键型的。而这种模式并没有赋予任何人通过开发优秀的软件来谋生的能力。如果开源的影响是人们无法通过开发优秀的软件来谋生，那么最终每个人都会受到影响。你不能将维护软件的过程与创建软件的过程分开。

也许在某些方面这种模式是有道理的。有些产品（主要在企业领域之外，或在更简单的技术中），志愿者完成了大部分工作。但在企业Java中，这种模式毫无意义。问题不在于聚合的概念——如果一家公司拥有投资和维持项目的资源，或者与其他公司合作，那么聚合的概念可能是合理的——而在于认为一个行业可以在无视经济规律的情况下维持下去，以及认为用游戏机而不是收入保障来激励人们将为企业级质量支持提供基础。

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