OSS.fund 创建者：2021 年以后的开源需要更全面的视角

OSS.fund 创建者、《Kubernetes Patterns》的作者 Bilgin Ibryam 近日发表了一篇名以 2021 年之后开源的整体愿景为主题的文章。

文中，Bilgin Ibryam 提出了开源项目成功的三个关键要素，列举了开源项目的主要健康指标，并对开源缺少的基础架构进行了分析。

Bilgin Ibryam 已经从事开源事业十多年了，Bilgin Ibryam 是 Red Hat 的产品经理，也是 Apache Camel、 OFBiz 和 Isis 项目的提交者。从初创公司到世界上最大的开源公司，一路走来，他为副业项目 oss.fund 整理了100多个开源货币化和融资平台，如今他有了一些新的认识。

他意识到“开源”这个词并没有足够广泛的视角来捕捉所有感知到的开放式现代软件的价值。为了实现这一点，开源需要一个更广阔的视野，以及一个支持开放治理和开放资金的基础架构。

开源在 2021 年的意义

过去，开源的价值在于源代码中，我们可以从自由软件的基本自由和开放源码定义的发布标准中看到这一点。

但现在，情况已经不同了。开源项目的其他特征除了对有价值的源代码的访问之外还有其他一些有价值的特征。开源的价值在于采用，有时可以达到一个项目成为某种技术（例如用于消息传递的 Apache Kafka）事实上的标准的程度。其价值在于相互竞争的参与者之间松散的协调、开放的协作和伙伴关系，以实现共同的目标（比如 Kubernetes SIGs 贡献者）。还在于一个项目的长期可持续性，这个项目可以比公司并购或破产的寿命更长久（比如 Oracle 和 Jenkins 项目）。今天，成功的开源模式更多的是用户采用、健康的社区合作和长期可持续性的缩影。

成功的开源项目的关键要素

首先，是许可证。许可协议规定了源代码及其衍生物（二进制文件、服务）是否可以分发。对于许多用户来说，这是唯一一个不可讨价还价的因素。它决定了一个项目是否符合开放源码的标准。遗憾的是，仅仅使用许可证并不能保证一个项目能够提供开放源码项目的全部潜在好处。

其次，是项目管理。治理模型为制定重要的项目决策设置规则，并规定项目的“所有者”如何与社区交互。有些例子表明，管理是通过一个可信赖的软件基础来进行的，这个基础提供了中立性、稳定性和透明度，但同时，它也会导致缺乏灵活性，并导致社区停滞。还有一些由单一公司管理的项目的例子，这可能导致项目许可证的变更，甚至过渡到专有软件模型。

作为一个开源项目的用户，我们希望它是开源的，与此同时，还希望它被广泛采用。这样用户就可以找到问题和答案、博客文章和最佳实践、开发人员和支持提供者，甚至可以把软件当作服务来使用。一个没有社区的开源项目是一种变相的营销工具。尚未达到临界社区规模的开源项目无法带来全部价值。如今，开源和社区代码的价值一样，在社区中也是如此。项目的许可证和治理直接影响其社区健康。

第三个方面是长期可持续性的财务模型。为支持者提供持续的财政激励的开源项目可能在一夜之间变得难以维护。未维护的项目是充满安全漏洞的项目。一个有安全漏洞的开源项目是一个死气沉沉的开源项目... ... 没有人在乎一个死气沉沉的项目的自由。

我们已经看到过很多次，开源项目在可预测的财务稳定性下是如何得不到维护的，或者被迫改变它们的许可证，变成私有的。有时候，这样的项目是由一家公司运营的。单一公司手中的开放源码项目不会带来开放协作的好处。它成为一个与公司战略、路线图和公司财务健康相关的公司项目。这不是一件坏事，但也不是真正的开源。

项目维护者的长期财务健康往往是源代码与其社区之间缺失的环节。项目的筹资模式，或者缺乏这样的模式，可能会影响治理、许可证的选择，甚至破坏一个社区。

开放源码项目的主要健康指标

这就需要一个新的更广泛的开源愿景和基础架构。Github 的 Star 数就是一种可以展示参与度的指标。第二是该项目的许可证，它可以告诉我们可以用源代码做什么。那些准备在开源项目中投入大量时间、精力和专业声誉的人，也会检查治理模型。

如果这个项目属于一个基金会，那么由谁赞助这个基金会，谁是项目管理委员会的成员，他们是如何选出来的？如何更改任何现有的过程、项目特性以及谁是看门人等等。在某些情况下，这些规则是写在 Wiki 页面上的，但是对于较小的项目，它们是不写的，项目所有者可以做任何他们想做的事情，即使没有社区的参与或透明度。除非一个项目是软件基础的一部分，否则没有代表最佳实践的开源治理框架，没有办法通过添加单个文件（类似于许可证文件）将治理模型应用于项目。当存在治理模型时，没有自动的方法来保证这些治理规则得到遵守。

对于一个开源项目，最后要看的一件事就是其财务状况和可持续性指标。如前所述，财务上不健康的开源项目有可能带来意想不到的变化和令人头疼的事情。

如今，还没有一个项目财务状况的单一指标。如果项目是软件基础的一部分，我们可以看到该项目从这种成员资格中获得了什么好处，但是通常，这些好处是为了维持基础而不是项目。如果一个项目由单个公司运营，则无法知道该项目对公司财务的贡献。如果项目维护者使用 Github Sponsors，我们可以看到当前的赞助商，或者我们可以检查 Patreon 是否有捐款，或者搜索数十个其他地方的类似指标。这些开源融资平台没有一个是功能完整的，也没有一个受到开源支持者的足够欢迎，以确保所支持项目的可持续性。今天，没有任何广泛采用的开源用户的长期财务承诺平台。对于开源项目，也没有任何可信的财务健康指标。

缺失的开源基础架构

想象一下未来的世界，开放源码不仅仅是一种开发方法或市场机会。相反，它是一种开放的技术平衡，在这种平衡中，知识和金融价值得以交换。在这样一个开源主导的未来，应该做到:

1.通过选择许可证、治理模型、资金模型启动开放源码项目，单击“创建”按钮，以开放和不可信的方式在一个地方获得所有需要的基础设施。

2.希望我们选择的治理模型基于现有的最佳实践，以其名称命名，并向社区提供某些保证（如许可证）。

3.希望治理模型能够自动地执行、执行和审计（通过智能合约等开放源码技术）。

4.希望不仅能看到一个项目的对一个项目的承诺数量，而且还希望看到有关累积（财务）资金和未来货币承诺的指标。

5.不仅想看到用于克隆项目源代码的 git URL，还想看到用于验证其资金存在的智能合约地址。

6.不仅要看发行计划和路线图，还要看基金的发行时间表和打算如何使用它们。

7.不仅要看编程语言的分类，还要看货币分配的分类。

8.不仅希望看到专注于开源项目的技术优势的软件基金会，还希望看到负责开源财务成功的基金会。

9.希望看到新的财务软件基础，这些基础专注于对开源项目的教育、增长、维持、货币化和资助。

10.希望看到这些基金会相互竞争以加入新的成功开源项目，希望基金会从成功的项目中获得财政支持。

11.希望看到项目支持者在财务上受到鼓励，承担风险，尽早支持项目并帮助项目的启动。

12.希望看到项目从孵化阶段毕业，不仅是当他们有足够的捐助者时，而且是当有足够的资金可以维持几个月或几年的时候。

13.不仅要查看社区活动的度量标准，还希望看到金融活动的度量标准，指出资金不足的项目可以激励用户筹集资金，防止维护者转移到其他项目。

14.希望看到开发者加入一个项目社区，不仅仅是因为有趣的技术，还因为一个项目有一个慷慨的资助模式。

15.希望看到公司将目标和结果驱动的资金分配给特定的开源项目，而不是仅仅为了营销目的而赞助基金会。

16，不仅希望看到偶尔的捐赠，而且希望看到为目标项目的需求（如文档、测试、培训、社区发展）而锁定的资金。

17.希望看到公司不仅将他们的名字添加到项目用户名单中，而且在支持财务交易的名单中找到他们的名字。

18.不仅希望看到员工保留计划，还希望看到投资于开源保留计划的公司。
19.希望能根据他们为项目所做的工作来了解不同社区成员的声誉。

20.希望看到一种基于此的自动衡量优点和资金分配以及治理权的方法。

21.希望看到控制项目资金的治理规则，并且只有那些被证明有价值的人才能执行这些规则。

22.希望看到公司能够安全和透明地支持开源项目，这也是项目指标的一部分，这样当我们决定是否加入一个开源项目时，可以做出更明智的决定。

想象一下，当我们查看一个软件项目，可以看到它具有开放源码许可、透明的治理模型和财务支持。这是一个基本的开源项目，可以长期提供可持续的自由。这种未来的愿景有些是抱负，有些是区块链项目探索和应用的。

例如，sourcered 是一个社区衡量和奖励价值创造的平台。这是一种透明和公开的方式，根据在开放社区开展的工作来追踪业绩。开发协议是另一个允许 OSS 创建者标记他们的项目并将奖励分发给令牌持有者的协议。它还提供了一个独特的融资模式，使维护者和支持者都能获得收益。

Gitcoin 是区块链领域的领导者，更有趣的是，Gitcoin 还提供了游戏化的学习和获得奖励的方式，以及由二次基金方法支持的增加捐赠的赠款等等。

---

开源这个术语从来不包括软件的治理、社区和融资方面。但是今天，这些都是开源项目的关键特征，从长远来看，这些特征可以间接地限制用户的自由和利益。

一个完全开源的项目需要一个更全面的视角，它不仅仅是开放的源代码，不仅仅是一种开放的开发方法，也不仅仅是一个消费者营销的机会，更不仅仅是一个销量增长的路线图。所有这些力量都是在公开的情况下进行管理的，在这一点上，也许它不再仅仅是开放源码了。到那时，也许它不再是开源的了。它成为具有开放治理和开放资金的去中心化开源软件（DOSS）。