开源告急？！
作者 | 阿木
责编 | 仲培艺
开源，还能走多远？
现如今开源软件几乎可以说是软件开发过程中必不可少的一部分，且是比较特殊的一部分，实际工作中几乎每个项目都有开源软件的身影。
开源社区的存在使我们每个人都可以使用到世界级的开源工具。这一点现在看起来非常常规，但其实里面包含了很多社区开发人员的心血，比如每个 import、include 语句背后的开源软件包都会对应一个专家团队，都隐含了他们的贡献，由于他们共同为一些待解的问题投入精力，这样大家在使用这些功能时直接导入他们的成果即可，不需要再各自造一套轮子，极大提高了我们项目的进度。
开源项目的可持续性从不同角度看一般会有不同的定义：
(1) 软件开发者
从软件开发组织的角度来看，可持续开源项目一般是指有能力及时发布代码并可以及时修改产品中存在的各种问题的项目。
(2) 项目本身
从项目本身的角度看，可持续性一般要求项目本身可以负担自己的支出，这样项目才可持续发展。
开源处境
开源社区维护者和贡献者为我们所有人构建工具，为我们日常的开发提供了很大的帮助，但开源社区的贡献者自身却面临诸多问题，这些问题一定程度上影响了开源软件的可持续发展，开源项目的可持续性也一直存在矛盾。
这一矛盾导致很多开源软件在最初更新迭代比较快速，文档书写也比较及时，后面却可能出现一些人员离职等问题，导致该开源产品后续的更新不及时，甚至直接中断，这时使用该开源产品的的同学在反馈问题时往往需要很长时间才会得到答复，甚至得不到答复。
笔者曾经在使用一个开源的数据库迁移工具时遇到过此类问题，具体是文档中说明该开源工具有功能 A，但并未写明功能 A 需要如何配置才能使用，在项目讨论区给作者留言长时间没得到回复，于是自己花了接近 1 天的时间去调试该开源工具的代码，发现文档中写明的功能 A 实际并未提供，一周之后作者留言功能 A 目前确实没有提供，且由于公司内部新换的领导没有之前领导那么热衷开源，所以后续用在此开源项目的人力会逐渐减少，功能 A 的上线也没有具体的时间点。
其他类似的事例也比比皆是，如某些大公司在内部评级时需要有开源的贡献，评级中加入对开源社区的贡献，本身对开源的发展是很好的事情，这样一方面可以为开源社区带来新的成果，另一方面也可加深项目参与者对开源的认知，为推广开源助力。但问题是很多开源项目在公司评级完成之后会很快被丢掉，没有人再去更新、维护，只是把开源项目当做自己职业生涯上某个阶段中的一个上升工具。
上面我们仅仅只是列出了开源项目经常遇到的问题之一，下面罗列了一些影响开源可持续性的常见原因：
(1) 资源不足
我们可以做个假设，如果没有开源软件，我们所处的社会还会不会是当今的样子？
今天，不仅互联网产业需要建立在软件之上，传统行业也是深度依赖于软件，在这些软件中，开源软件所占的比例越来越高，尤其是一些构建成本低、容易发布、可灵活定制的开源软件。
开源软件可以类比为我们实体世界中的公路、桥梁等基础设施，每个人都可通行，类似开源代码人人皆可使用，这些开源软件已经是今天数字基础设施的一个很重要的部分。
免费的开源软件一定程度上使得很多创业公司的创业成本急剧下降，再加上云服务的爆发式发展，开源软件在使用上越来越便捷，直接促成了 21 世纪大量创业公司的兴起。
开源社区无处不在，但普遍缺乏经济资源和人力资源。人们重视实体基础设施的投资，但却忽视了数字基础设施的建设。
使用开源产品的企业或者个人开发者可以从充满活力的开源生态链中获益，但是目前缺乏比较普适的方式引导这些开源产品使用者来为开源产品贡献自己的时间或财力上的支持。虽然开源软件有很大的潜力，但这种情况很大程度上限制了开源软件的价值。
像实体基础设施一样，数字基础设施也需要不断的定期维护。很多比较有价值的开源软件无法得到商业模式的支持，也缺乏任何形式的机构支持。所以开源贡献者投入很大的精力换来的更多的是认可，并且后续还要保持项目的版本迭代，基本不求任何形式的回报。因为搭上了开源这个便车，众多的互联网巨头成开源软件的最大受益者，但巨头们并未将因此获得财富有效回馈给开源贡献者，甚至很多公司压根就没有意识到这一点。
(2) 隐性成本
在此我们所说的隐性成本是指因为忽视数字基础设施建设而带来的隐性成本,由于是隐性成本，所以这方面的关注度一直不高。
a. 开源软件漏洞
过去几年开源软件因为数字基础设施建设被忽视而导致的问题可谓实繁，如众多的严重代码错误、开源软件安全漏洞、服务中断等。
比如在 2014 年，一些用户在使用开源的 OpenSSL 库时发现其存在 Heartbleed 安全漏洞（也称心脏出血漏洞）但是在当时开源 OpenSSL 库已经被广泛使用，整个互联网行业中有接近 2/3 的 Web 服务器在使用存在 Heartbleed 漏洞的 OpenSSL 进行密码、信用卡等敏感信息的传输。我们可以看下 ZoomEye 当时专门针对 OpenSSL 漏洞制作的漏洞影响统计：
几乎影响了分布在世界各地的互联网公司：
可见开源 OpenSSL 在整个互联网行业的重要性，大家可能以为互联网行业如此重要的一个开源软件应该有自己的专业技术团队，应该人数众多、资源充足，但是事实上 OpenSSL 只有一位全职的工程师，所以在事件发生后不足以及时地修复漏洞。好在事情后续有了比较好的进展，随着各大媒体的报导，Heartbleed 得到了广泛关注，一些报导也关注到了 OpenSSL 本身面临的困境，OpenSSL 因此暂时获得了一些资助，这部分资助当时可以支持 4 位全职的工程师为 OpenSSL 服务 3 年。
b. 软件维护困境
据统计，很大一部分开源软件在开发出来之后得不到必要的维护。
2013 年，著名 Ruby 代码开发托管平台 RubyGems.org 被爆出一个非常严重的安全漏洞，但问题爆出后长时间未被修复，后发现开源平台 RubyGems.org 没有自己专职的技术人员，完全是由志愿者开发并维护的，因此出现问题后没人去及时处理。结果导致一些黑客发现了这个安全漏洞，并利用这个漏洞攻击了 RubyGem.org 的服务器。
RubyGem.org 服务器被攻击一段时间之后，之前开发此网站的一部分志愿者抽出自己的休假时间开始对网站漏洞进行修复。接触过 Ruby 生态的同学应该知道，RubyGem.rg 是 Ruby 生态中非常重要的一个组成部分，是 Ruby 基础架构中的一个关键部分，因此这个安全问题波及了许多开发者和公司。
这个事情也从侧面暴露出一个问题，对于没有全职技术人员且完全由志愿者开发维护的开源软件应该如何保证其安全性和可靠性。
c. 优秀人才流失
开源软件在开发过程中或开发完后的日常迭代中经常会遇到技术人员退出的问题。技术人员尤其是核心技术人员在中途退出，会严重影响开源项目的进度和项目的质量。
开源社区的志愿者和我们日常的一些社区志愿者一样，也会存在懈怠的情况，且此种情况也算是比较常见的，毕竟大家一般都是一面做着自己的专职工作，一面来参与社区的工作事务。
不管是个人开发者还是企业的开发者，大部分情况下大家都是在无偿处理来自用户的需求，有时也会心力交瘁。在此种情况下部分的开源开发者会选择停止自己手里维护的开源项目，或者希望别人可以接手自己的项目，因为自己没有时间专职去做开源的项目。与此同时，企业和个人继续依赖和使用这些开源产品，他们并不了解这些产品目前所包含的风险。
小结
开源软件大部分时候都是以代码的形式对外展现，由于代码并不像热门视频或热门音乐那样能够吸引人，这样就造成公众对开源工作的认知度很低。
在多数人的认知里，使用开源是理所应当的，我们在使用开源的产品时并不会去考虑维持我们正在使用的开源产品所需要的人力、物力、财力等资源。
OpenSSL 的事情并非特例，类似的开源产品的遭遇几乎每天都在上演，但并不是每个产品都得到了后续的资金支持，因此一定程度上来看 OpenSSL 又是幸运的。
无数的开源项目继续默默无闻，且得不到完善的支持，这些问题开源贡献者几乎每天都会面对，但是开源产品的使用者一般并不清楚这个情况，数字基础设施缺乏足够的制度支持。
(3) 沟通工具缺乏
这里提到的沟通工具不是开源项目开发成员之间的沟通，指的是开源社区和开源产品使用者之间的沟通互动。
现阶段来看，随着开源项目的发展，和用户之间沟通会变得越来越有挑战性，导致这种现象出现的原因主要还是社区管理工具的缺乏。为改变这种情况，很多开源项目会自己去构建项目和社区管理工具，但是这个过程往往会消耗比较多的时间和精力，这些时间和精力本来应该是需要用在开源产品本身的开发上的。
(4) 人身攻击
大家经常逛开源社区的话，应该不难发现评论区经常会出现一些不和谐的声音，比如“就这代码水平还来做开源…..balabala”等。
开源社区的维护人员一般是自愿为社区做事情的，没有人应该被骚扰，甚至辱骂。
(5) 缺乏分析工具
除了下载统计这些基本的统计信息，开源软件维护人员一般对自己软件的实际使用情况了解有限。
最常见的就是通过社区的留言信息来了解用户的实际需要，相比企业内做产品的沟通方式，这种沟通方式相对低效，需要提供更好的需求收集、反馈工具。
(6) 新人培养问题
企业内日常开发中一般都会有新人培养机制，典型的就是老司机带新人，培养模式一般相对较成熟。但放到开源软件开发中此种方式就有些水土不服，很难在开源的项目中找到老师傅带路，对于新加入的开发者存在一定的挑战，很容易产生挫折感。
(7) 项目管理待优化
随着项目的发展，开源项目的团队创建、任务分配和沟通决策的方式也要随之发展，这在企业内部正常的开发中也许问题不大，但环境挪到开源软件开发中时开源社区往往并不能够总是很好地应对这种变化。
(8) 反对商业利益
参与过开源项目的同学可能会很有体会，开源文化中一般并不鼓励谈论金钱，大家往往会认为涉及到金钱的话就会腐蚀和削弱开源工作的资源精神，违背很多人参与开源工作的初衷。
尽管这种态度使得开源领域拥有了今天的规模，但是随着时代的改变、社会形势的改变、周围环境的改变，开源参与者也会面对一些资源需求。开发者可能会出于内疚或者可能被质疑缺乏团队精神而羞于谈论此类话题，但当与现实需求产生碰撞时很多人可能会处于利益的考虑而选择退出手里的项目。
参与过开源项目的同学应该知道，整个过程除了需要做公司内自己的任务，还需要挤出时间去做社区的项目。这种状况往往导致开源开发者疲惫不堪，且整个参与过程中几乎无报酬或者报酬微薄。
开源软件并不一定是免费软件，开源软件和免费软件不是一个事情，更不能等同，在此我们有必要回顾下开源软件的定义，以维基百科对开源软件的定义为例：
开源软件（英语：open source software，缩写：OSS）又称开放源代码软件，是一种源代码可以任意获取的计算机软件，这种软件的著作权持有人在软件协议的规定之下保留一部分权利并允许用户学习、修改以及以任何目的向任何人分发该软件。开源协议通常匹配开放源代码的定义的要求。一些开源软件被发布到公有领域。开源软件常被公开和合作地开发。开源软件是开放源代码开发最常见的例子，也经常与用户生成内容做比较。开源软件的英文“open-source software”一词出自自由软件的营销活动中。
开源软件同时也是一种软件散布模式。一般的软件仅可获取已经过编译的二进制可执行档，通常只有软件的作者或著作权所有者等拥有程序的源代码。
有些软件的作者只将源代码公开，却不匹配“开放源代码”的定义及条件，因为作者可能设置公开源代码的条件限制，诸如限制可阅读源代码的对象、限制派生产品等，此称之为公开源代码的免费软件（Freeware，例如知名的网络论坛软件 Discuz!），因此公开源代码的软件并不一定可称之为开放源代码软件。
除此之外，开源开发者的高度分散和高度民主的特性，即使是有偿服务开源也是极具挑战的。
(9) 缺少可持续性的商业模式
当前开源领域常见的商业模式：
a. 专业服务
专业服务即专门做付费服务。这中模式中最著名就是红帽，红帽主要通过向使用他们产品的用户提供有偿服务进行收费，比如对于企业用户的 Linux 支持、技术培训等。
红帽成立于 1993 年，是一家上市公司，借助专业服务这种商业模式，全世界领先的开源服务提供商，红帽公司每年的营收可以超过 30 亿美金，2018 年 10 月被 IBM 以 340 亿美元收购。
b. 区分版本
采用此种商业模式的开源软件，一般就将产品的版本分为开源社区版和付费商业版。
社区版开源且可免费使用，一般也可使用到最新的功能（有的开源版本只会提供单机版，集群版包含在商业版中，如 InfluxDB），但不提供任何商业版本具有的服务保障。
商业版一般闭源且需要付费才可使用，并且还会提供质量测试、Bug 修复、性能优化、定制化服务以及众多售后技术支持。
此种模式下比较出名的如 Docker、MySQL 等。以 Docker 为例，Docker 分为三个版本：Moby、Docker CE 、Docker EE。Moby 是 2017 年初由 Docker 公司原先的 Docker 项目改名而来，Moby 继承了原先的 Docker 项目，由开源社区进行维护，每个人都可以在 Moby 的基础上再次开发属于自己的容器产品；Docker CE 也是免费开源的 Docker 产品，与 Moby 不同的是 Docker CE 是由 Docker 公司自己维护的开源项目，是一个基于 Moby 项目的免费开源容器产品；Docker EE 是 Docker 公司的 Docker 商业化产品，该版本闭源且需要付费才可使用。
c. 基金会
基金会这种商业模式大家可能会更加熟悉，这种模式中最为出名的莫过于 Apache 软件基金会，其他的比较出名的如 Linux 软件基金会、OpenStack 软件基金会。Apache 软件基金会成立于 1999 年，到目前为止 Apache 软件基金会已经孵化了超过 350 个项目，如 Dubbo、Apollo、CloudStack、Flink、Groovy、Hive、Mesos、Nutch、Pig、Spark、Storm、Python、Node.js、Django 等等。
基金会的资金来源一般是企业捐赠，业界的几大巨头捐赠较多，基金会本身为项目提供组织和法务等方面的支持，基金会本身不直接为项目提供资金支持。
如果项目本身足够大的话，可以创建独立的基金会进行管理和募资，此种情况比如：Python、Node.js、Django 等。
d. 企业赞助
如果项目本身价值较高，拥有大量的使用人群，此种情况企业可以专门招聘专职的技术人员为项目工作。此种商业模式的典型例子也有一些，如 jQuery——一个被广泛使用使用的 JS 库，接触前端开发的同学应该都不会陌生。
e. 赏金
部分公司或个人有时会对外发布悬赏，以此来获取诸如新需求、软件安全漏洞等信息。此种商业模式事例也是不胜枚举，以 IBM 为例，IBM 从 2013 年开始便借助网站 Bountysource 来为自己的多个项目收集新的需求。也有部分公司会为了发现开源软件的安全漏洞而对外发布悬赏。
f. 众筹
部分开源项目会通过众筹的方式对外寻求需求资金的支持，比如 Kickstart、Indiegogo、Django 等。我们以 Django 为例，Django 数据库模块的核心开发者曾从其 507 名的支持者中众筹了一部分资金，以此来资助 Django 框架中数据库模块的开发。
g. Open Core
此种模式通常会涉及一种功能强大的开源核心产品，然后围绕着这个核心产品来提供一些商业上的扩展，一般还会捆绑一些支持和服务。
目前也有一些采用这种商业模式的开源产品公司，如 Cloudera、Elastic、Confluent 等。
问题小结
上文列出了开源软件开发过程中面临的一些问题，从中我们可以看出开源软件的发展所面临的一些痛点：
(1) 开源软件的可持续性
开源软件的众多商业模式中，总结起来，目前仅仅只有专业服务、付费商业版和 Open Core 这少数几种模式可以获得持续且比较稳定的收入，其他几种方式存在不确定性，甚至可能并不能算作严格意义上的商业模式。
(2) 对开源的支持对象
现在看来，外界对开源的支持绝大部分是对项目的支持，而且是对特定的项目，对个人贡献者直接支持的情况相对比较少些。
(3) 时间消耗
如果一个开源项目有比较多的用户群体，且很多用户愿意付费，那么对于个人开发者或小团队来说专业服务这种模式不失为一种很好的选择，但是这种方式也会带来其他的一些问题，即可能会消耗开发者改进项目本身的时间和精力。
(4) 资源差距
从今天开源社区资源获取的情况来看，大部分资源被投入到少数几个热门的项目上，其他的一些项目受关注程度和获取的资源支持相对较少，这种现象也会导致一些问题的出现，例如一些基础软件和小众软件的生存空间可能逐渐被压缩掉。
(5) 开源社区中立性
企业如果为开源项目聘请专职的技术人员，可能会导致技术人员在参与开源项目发展的过程中倾向于自己所在的公司，进而可能影响到所在项目的中立性，甚至可能影响到项目原本的发展方向，此种情况的出现将不利于开源社区的发展。
可持续性建议
对于开源可持续发展，笔者结合社区给出的一些建议总结了以下几点：
(1) 鼓励个人开发者
可以通过改进众筹的方式增加项目收入，以此来回馈开源贡献者。
具体实施，可以从项目的用户或关注者中获取收入，并向开源项目的开发人员提供部分经常性的收入，以示对开源项目的支持。此种方式可以借助如下两个平台：
a. Patreon
Patreon 不仅关注开源贡献者而且也关注其他的内容创作者，该网站不仅可以提供开源项目的捐赠服务，还可提供商业贷款。
b. Liberapay
Liberapay 的前身是 Gratipay，是资助开源项目和开源开发人员的最大平台，遗憾的是 Gratipay 已经于 2017 年年底关闭，后续由其分支 Liberapay 继续提供功能。
(2) 支持双许可证
双许可证是指一种在商业付费和开源代码之间的一种平衡的方法，如：
a. License Zero
License Zero 是一种基于双条款的 BSD 许可，该条款允许用户在购买之前进行试用，商业用户可以有 90 天的产品试用期，使用期限达到 90 天后需要购买商业许可才可继续进行产品的使用。
b. Fair Source
Fair Source 是 Sourcegraph 推出的 Source Visible 许可，一般情况下对于个人和小型企业是免费的，但是对比较大的商业用例需要付费后才可使用。
(3) 支持小项目的商业化
此种模式类似红帽的商业模式，区别是该模式支持较小的项目。
比如开源软件 Tidelift，企业用户如果需要后续的技术支持服务，则需要向其支付一笔服务费用，此种模式的目的是为了让企业用户为开源软件贡献人员提供一种稳定的收入，这种模式如果可以推广将会吸引大量技术人员进入开源社区，为开源社区贡献力量。
(4) 降低成本
开源项目实现可持续性一般还需要开源项目自身能够负担自身的各项成本。成本包括多种，比较常见的如基础设施成本、开发成本、软件后续的更新和维护成本，另外还包括项目管理产生的治理成本、营销成本和沟通成本等。
很多项目的初始成本是由上级机构、或者初始的开发者自己投资支付的，问题是这笔钱用完了后续该怎么办？
开源项目的初期资金一般比较有限，到了项目的一定的阶段，就需要采取一些措施缩减开支，通常无非是开源或者节流。一个开源项目如果需要持续发展，则其收入必须超过其消耗成本，如开发和维护成本。
鉴于此，绝大部分的开源项目很难实现可持续性，这一点不仅仅适用于开源项目的开发，也同样适用于闭源项目的开发，实际上任何需要资金支持的项目都是如此，不论开源还是闭源。
开源项目无法实现可持续性的原因很多。某些情况下，可能是因为项目未能达到项目最初设置的目标，所以项目的很多参与者便期望可以取消项目。这是一种情况，另一方面，很多项目即使达到了最初的目标，却仍然无法实现持续性。使用公共资金的项目尤其如此，这类失败通常是由于开源项目开始的规划不当引起的。换句话说，项目开始的最初阶段项目管理者并未就项目初期资金的使用制定合理的规划，如到达什么阶段消耗多少资金，项目未完成资金消耗完时该如何应对等，因此也就没有为项目实现可持续性分配资源。
所以，结论很明显，要想实现可持续性，我们必须在项目的初始目标中包括可持续性计划。这意味着，我们需要在项目周期的最开始阶段就制定出可持续性计划，而要想制定出合理的计划需要真正清楚当前项目已经具备的资源和可以调动的资源，对于开源项目的负责人来说这些都需要整理清楚。
实现可持续性有很多的选择，在此我们无法一一列举，因为项目的模型和项目的创意几乎一样多，鉴于很少有项目可以严格归为某种模型，在此我们不再赘述，感兴趣的同学可以自己查阅下。
开源未来
借助 GitHub 这一平台，今天的开源社区仍在加速发展。Github 平台一定程度上充当了开源软件爆炸式增长的中心，据统计，目前使用 Github 平台托管的 repo 数量已经超过 1 亿个。
开源软件在蓬勃发展的同时，也吸引了众多 VC 的目光，越来越多的 VC 开始踊跃投资开源项目，但其投资会受到资产类别的限制，目前 VC 不能投资一个没有商业模式的开源项目。
红帽的模式很难复制，红帽商业模式的成功，一方面得益于其技术的先发优势，另一方面，服务的模式很难持续高速发展，尤其是云计算的兴起，开源项目的市场空间会逐步受到挤压，后续将会出现越来越多的并购案。
目前对开源项目可持续性的探索，可以说还处于一种低水平的阶段，一种早期阶段。上文中我们讲到的几种新的商业模式基本都需要开源项目有自己的全职技术人员，但实际情况是目前只有少量的项目达到这一标准。
此外 Pateron、License Zero 和 Tidelift 虽然可以提供可持续性的不同方法，但需要花费很多力量使这些基础设施真正地被使用起来，另一方面，Pateron、License Zero、Tidelift 和 Collective 等还相对较新，后续的发展还需要进一步的观察。
作者：王洪鹏，运营有个人公众号新新生活志。目前任职网易云计算技术部高级工程师，近3年云计算从业经验，爱读书、爱写作、爱技术。
声明：本文为CSDN原创投稿，未经允许请勿转载。
【完】
热 文 推 荐
☞没有新芯片，没有大核弹，黄教主这次给大家带来了个PRADA
☞曝光！月薪 5 万的程序员面试题：73% 人都做错，你敢试吗?
System.out.println("点个在看吧！");
console.log("点个在看吧！");
print("点个在看吧！");
printf("点个在看吧！\n");
cout << "点个在看吧！" << endl;
Console.WriteLine("点个在看吧！");
Response.Write("点个在看吧！");
alert("点个在看吧！")
echo "点个在看吧！"
相关内容
微信扫码咨询专知VIP会员