开源工程的可持续性之为什么大公司不投资 PHP

最近,Reddit PHP 社区提出了一个问题:"为什么大公司不投资 PHP?"

这个具体问题的答案可能过于复杂,细节也隐藏得太深,没有人能给出令人满意的回答。许多大公司过去曾使用,或者现在仍在使用 PHP,但具体程度没人能确定。我们唯一能确定的是,尽管 Yahoo、微软、Oracle、IBM 和 Facebook 在历史上的不同时期都有过不同程度的投入,但今天没有一家是主要投资者。

我们可以从更宏观的角度来看这个问题:"为什么(大)公司不投资开源软件?"

企业贪婪?

有些人会把企业投资的惰性解释为"企业贪婪"的直接结果——仿佛董事会正在开会讨论如何从开源生态系统中榨取价值并牟利。这种荒谬的场景过于牵强,不值得认真对待,更重要的是,它既不能提供有效的视角来审视问题,同类推论也做不到。

让我们假设每个人都是出于善意行事,因为很可能,他们确实如此。

场景设定

今天全球市值最高的五家公司都是计算机公司,与互联网本身直接或间接相关。这些公司的市值都超过 1 万亿美元——所以它们在潜在投资方面拥有难以想象的力量——它们都在某种程度上确实投资了开源,但我们都能看到,这些数字并不合理。

互联网并不古老,历史不长,但这段历史是理解实际发生了什么的关键。

开端

互联网主要建立在开源软件之上,但它并非在真空中发展成为重要基础设施;其扩散的背景是互联网股票泡沫。正是在这个泡沫中,开源软件作为基础设施成为常态。

在这个泡沫中,几乎没有人谈论资助开源软件——不可持续性还没有进入人们的视野,仅仅因为时间还不够长,问题还不可见。互联网也还没有转变为今天这样的必要基础设施,所以即使在讨论建立在开源软件之上的价值的可持续性的地方,他们可能也无法以必要的远见来审视这个问题,进行适当的评估(就像我们现在正在用后见之明进行的回顾性评估一样)。

认为没有任何人具备必要的远见进行评估是相当荒谬的,但他们不发声的原因很明显——"我们应该投资一个我们免费获得的东西,没有其他人投资,也从未要求投资"不是一个有利于职业发展的立场。

2000 年 3 月,互联网泡沫破裂,两年内纳斯达克总市值损失接近 5 万亿美元。

恢复期

泡沫破裂的影响极其广泛且持久:

  • 思科 损失了 80-89% 的市值,截至 2022 年仍未恢复
  • 亚马逊 股价从 107 美元跌至 7 美元,2010 年才恢复
  • 高通 2019 年恢复
  • 微软 2010 年恢复
  • 英特尔 损失了 80% 的市值
  • Oracle 损失了 80% 的市值

在所有情况下,这些公司都花了数年,有些甚至超过十年才证明自己的存在价值,恢复股东价值——即为那些在高点买入的投资者带来回报。

在这种情况下,我们可以假设每个人都在善意行事,因为我们只需要假设每个人都专注于度过风暴、为投资者带来回报、确保业务(或商业模式)的可持续性(或主导地位)——无论你是否鄙视这种资本主义都无关紧要,这就是我们所处的资本主义——他们只是在履行自己的信托责任。

开源的存活

在整个 2000-2015 年的恢复期,一件了不起的事情发生了:开源(互联网)软件栈——Linux、Apache、MySQL、PHP、Python 和无数其他项目——在志愿者的劳动下持续发展。

这些项目不需要企业资助就能:

  • 保持稳定
  • 持续改进
  • 添加新功能
  • 修复安全问题
  • 支持那些正在从崩溃中恢复的公司

一切建立其上的基础设施继续运转。继续演进。继续由志愿者维护,他们出于自己的原因这样做——技术兴趣、声誉建设、解决自己的问题,或者当他们的项目意外流行时的简单义务感。

幸存者偏差

这里列出的项目,对开源(互联网)软件栈至关重要的那些,它们的存活本身就阻碍了投资的动力:它们确实存活下来并变得更好,但这只证明了一件事——"给工程师机会,他们就会搞工程"。

为了对抗这种偏差,相关的问题是:

  • 什么没有存活下来?
  • 什么从未出现?
  • 什么被显著延迟了(即创新与该创新的先决技术基础之间的差距很大)?

市场本质上显著延迟了,甚至优化掉了那些依赖需要资金但从未获得资金的创新的整个基础设施类别;这就是投资不足的机会成本。

虽然这个成本很难量化,但我们可以命名它。我们也可以通过观察随后出现的创新来推断价值,并假设如果有投资支持创新,这些创新会更早到来。

时代精神的转变

这里的时间线至关重要。关于开源可持续性的严肃公开讨论直到大多数公司从崩溃中恢复之后才出现。

以下是一些相关的数据点:

  • 在 2014 年 4 月 Heartbleed 漏洞事件之前,OpenSSL 每年收到的捐款约为 2000 美元
  • 核心基础设施倡议(Core Infrastructure Initiative)是在 2014 年 Heartbleed 事件后被动成立的
  • Nadia Eghbal 有影响力的《Roads and Bridges》于 2016 年 7 月由福特基金会出版(被认为是广泛可持续性对话的催化剂)
  • GitHub Sponsors 于 2019 年推出
  • PHP 基金会于 2021 年成立

当开源资助进入更广泛的技术时代精神(大约 2014-2016 年)时,公司已经见证了一个 14 年的自然实验,传递了一个明确的信息。

14 年的自然实验

从 2000 年到 2014 年,科技行业经历了可以想象的最重大的压力测试。

在技术行业历史上最严重的灾难及随后十多年艰难恢复期间,由志愿者维护的开源基础设施:

  • 从未失败
  • 从未要求付款
  • 从未停止改进
  • 从未造成需要干预的危机
  • 支持了数十亿美元的商业活动
  • 不需要企业支持就能存活

与此同时,拥有巨额收入、专业管理和资本市场准入的数十亿美元公司:

  • 惨烈崩溃
  • 损失了 80-90% 的价值
  • 花了 10-20 年才恢复(或根本没有恢复)
  • 需要剧烈干预才能存活

经验教训是残酷的:开源基础设施比建立在它之上的公司更具韧性。

保险模式

当开源资助最终成为讨论话题时(大约 2014-2016 年,由 Heartbleed 和《Roads and Bridges》等报告催化),公司已经积累了两个关键数据点:

  • 他们在不投资开源的情况下实现了财务恢复
  • 开源在整个时期持续繁荣

这巩固了我们今天看到的最小姿态模式。这些投资不是为了防范开源崩溃——经验证据使这种风险看起来可以忽略不计。相反,它们是为了避免在下一个漏洞出现时显得失职。

这种投资提供了:

  • 企业意识的文件证据
  • 在法律或监管环境中可辩护的立场
  • 关于"支持开源"的公关谈资
  • 对实际项目可持续性的最小影响

这就像企业版本的在你每天用餐的餐厅小费罐里留下零钱。足够让你不觉得完全是寄生虫,但不足以真正改变任何事情。

投资差距

比较一下公司在内部工程上的支出与开源贡献:

一个典型的大型科技公司可能有:

  • 5000+ 名工程师在专有功能上工作:每年 10-20 亿美元
  • 主要开源基金会会员费:每年 10-100 万美元
  • 可能 5-10 名工程师贡献上游:每年 200-500 万美元
  • 开源总投资:可能占工程预算的 0.1-0.5%

这个比例揭示了真相:公司不相信开源需要他们的投资。而且他们有 15 年以上的证据支持这一信念。

例外情况

在漫步历史、从远处观察试图发现模式的过程中,我们可能会错过一些重要的例外细节。

在 Heartbleed 和今天之间的这段时间里,许多大公司包括微软、Meta 和 Google 确实在开源软件领域部署了大量资源。

这些资源都没有直接流向 PHP,也不一定表明他们认识到了这个问题:我们仍然可以质疑这些投资是否与他们从更广泛生态系统中提取的价值成比例,或者是否只是相对于他们的直接商业利益或工程需求。

新世界

我们现在生活在一个软件工程师不再是唯一软件工程师的世界。我们正在迅速走向一个人类甚至可能不再保持代码生成首席地位的世界。

最明显的解读是:现在更没有理由投资开源了。如果 AI 可以生成和维护代码,为什么要资助人类维护者?投资应该完全流向 AI 能力。

这似乎极其天真:未来的联合首席——AI——并不是从新颖架构中涌现的创造力产物。没有人能证明这种创造力在原则上用今天或可预见的 AI 架构是可能的。AI 从根本上是一个聚合器。它从现有工作中提取模式,重新组合它们,并将它们应用于类似问题。

软件工程领域仍然需要投资才能繁荣。不是投资于聚合现有模式的工具,而是投资于创造新模式的人类实践。AI 不会生成它所依赖的训练语料库——它消费它。此外,随着生成的内容扩散并成为训练语料库的一部分,该语料库显然会停滞,导致不可避免的退化。

如果我们试图预测退化率,我们很可能会错;该预测所需的数据是专有的或不存在的。反作用力——"给工程师机会,他们就会搞工程"等等——也很难量化,尽管如此,它们将被压倒是不可避免的。

我们可能正在接近一个拐点,25 年的经验证据(开源不需要企业投资就能存活)与新现实相碰撞:

开源需要企业投资来创造,因为 AI 已经将创造性工作的提取工业化到了不可持续的程度。

合乎逻辑的结论

投资于创造开源软件的人类的理由从未如此强烈,也从未有过如此广泛的适用性:这个由电子同事居住的新世界仍然由开源软件支撑——正是这些开源软件从一开始就支撑着互联网作为基础设施的扩散。

受到企业投资惰性威胁的不仅是现状,还有那个新世界。

未解决的问题

即使依赖开源软件的公司接受了他们需要按比例投资该软件以维持未来的前提,仍然存在一个严重的归因问题。

一家依赖 100 多个开源软件的公司——这不是一个荒谬的高数字——面临着决定需要投资多少的问题,以及找到实际执行投资的途径——虽然 GitHub Sponsors、Open Collective、Patreon 和其他类似解决方案存在,但并不存在一种简单的方式在所有情况下分配资金。

可持续性工程

简单的答案是不可得的,然而,如果我们要认真对待可持续性问题,我们应该指派一名工程师来完成这项任务。

解决方案不是一个答案,而是一个过程,由可持续性工程师执行,他的工作是确保雇用他们的企业的可持续性。

这不太可能是一个全职角色,更可能是由一名能够评估业务在多大程度上依赖于任何软件的高级工程师执行的职责,以及授予他们的投资权力是否足以实现可持续性,如果不够,则确定可能可行的替代技术路线来替换其技术栈中的该依赖项。

我们应该明确,这对任何高级工程师来说都不是一项微不足道的工作,它需要他们的专业知识来做出技术决策,除此之外,它可能需要培养关系、参与社区、潜在的大量研究(可能涉及他们自己技术栈中不熟悉的部分,可能使用不熟悉的语言)。一个好的候选人真正有动力解决与他们工作相关的可持续性问题,一个尽职尽责的候选人会超越他们的直接依赖,关注支持业务的更广泛生态系统。

指定、补偿和财务授权一名可持续性工程师并不能解决所有问题,它建立了一个能够解决问题的过程,并指定了一个负责通过资源分配确保问题得到解决的人。

开源工程可持续性

一个资金充足的可持续性工程师走出去向世界讲述他们正在做的工作,是一根有力的棍棒,可以说服其他所有人建立自己的可持续性倡议,任命自己的可持续性工程师,从而使先行者摆脱作为先行者固有的负担。

同样重要的是,数据流是公开可访问的,以便其他可持续性工程师能够完成他们的工作。虽然硅谷可能会退缩于与公众分享这类财务信息的想法,但这不是产生可被视为专有信息的活动——软件依赖软件不是秘密,地球上使用的大多数软件是开源的也不是秘密。

生成的信息不过是对可持续性问题的认识,以及你致力于解决它的程度的衡量。

本作品采用《CC 协议》,转载必须注明作者和本文链接