基于 Java 的日志记录工具 Apache Log4j2 近日出现了一个高危漏洞,攻击者可以利用其 JNDI 注入漏洞远程执行代码,此漏洞牵涉面非常广,以至于国内外的个人或公司用户都对此高度关注,而 Log4j2 开发组在漏洞曝光后及时发布了 Apache Log4j 2.16.0 维护版本,默认禁用 JNDI,使此漏洞得到控制。
但小编在学(mo)习(yu)的时候,发现 Log4j2 的维护者之一 @Volkan Yazıcı 在推特上吐槽:Log4j2 维护者只有几个人,他们无偿、自愿地工作,没有人发工资,也没人提交代码修复问题,出了问题还要被一堆人在仓库里留言痛骂。
这是一个非常现实的问题,我们姑且将这个问题称之为“开源可持续性问题”。通常来说,一个开源项目,要不就是反响平平无法形成生态,导致开发者热情逐渐降低、慢慢停掉;或者项目是大热门,很多个人和公司都在用,但 —— 除了出问题的时候问一下,几乎没有人会为开发者提供财务支持或贡献代码修复。
而那些使用免费资源而从不回馈社区的公司,他们对开源软件的利用一直是开源项目维护者的痛处。他们使用开源项目达到企业成本最小化和利润最大化,然而这些利润跟开发者一毛钱关系没有,甚至还有公司出了问题赶紧甩锅给开源作者,比如前段时间 curl 作者吐槽苹果把他当做免费工具人:
“想象一下,一家市值万亿美元的公司将各种开源组件应用到自己的产品中,每年赚取数十亿美元的利润。当这家公司的一个用户向它提供的产品寻求帮助时,公司却把用户推给开源项目。这个开源项目是由志愿者运营和维护的,这家公司从未赞助过一分钱。”
这样的情况已经持续了相当一段时间,不过现在已经有人在思考这个问题,并给出了一些权衡的建议。上周六,谷歌密码学家和 Go 语言安全负责人 Filippo Valsorda 在个人博客呼吁:开源项目维护者应当和那些使用软件的公司进行更专业的交流,以获得付费支持,使开源更具可持续性。
Filippo 指出一个问题:目前大多数开源项目维护者属于以下两类之一:志愿者或大公司员工,有时两者兼而有之,但这两种模式其实都不健康。一个成功项目的普通维护者其实有资格成为高级软件工程师,这些人每年可以轻松赚取 15W-300W+ 美元的年薪,但现在他们的开源项目经济来源只有 GitHub Sponsors 和 Patreon(一个募捐网站),这是两种不严肃且不稳定的薪资来源。
而被聘为大厂的全职开源员工也并非上策,踏入公司的第一步你就成为了资本的一部分,随着主管和绩效组的“如何证明你的工作和工资相匹配?”开发者开始背上各种 KPI ,主动或被动地卷,将越来越多的时间花在努力证明自己的工作和价值都非常重要 —— 在这种压力之下,大部分开发者将逐渐丧失对开源项目的热情,这种情况在多个公司和生态系统中一遍又一遍地上演。
综合目前的情况,Filippo 提出了一个新的观点:既然大公司需要项目供应链安全和质量达到标准,那么他们就有必要为使用的开源项目付费 —— 公司可以跟开源软件开发者建立合同关系,按照市场价的薪资支付,然后要求开发者保证项目的质量和漏洞问题。反过来,项目的维护者仍然可以自由地持续关注项目,优先考虑项目的长期健康状况,并满足公司对项目的要求。
这种流程和生态的建立需要一些时间,重点在于如何转变公司的态度 —— 公司,尤其是资本控制的上市企业,完全没有为大型产品、项目和服务核心的开源组件付费的热情,它们只会在开源许可证和法律底线的条件下做利益最大化的事情,而不是“公平交易”。而目前流行的一些许可证,像 Apache 、MIT,都是提供所有内容但要求的东西很少,更进一步满足了企业白嫖的需求。
目前世界 500 强企业所使用的许多重要的开源项目都由志愿者在下班后的业余时间维护,这些企业甚至连代码安全性都懒得审查和测试。开源维护者创造了大量价值,但几乎一无所获,这种开源文化是无法长久持续的,是时候做出一些改变了 —— 开源维护者这个角色应当成为一个真正的、有适当报酬的职业,而不是依赖寥寥无几的捐款的业余爱好者或者企业的免费劳动力。
题外话:
Log4j2 的开发者和维护者 Ralph Goers 在 GitHub 上仅有 3 名赞助者。
我是 Apache 软件基金会的成员,也是 Apache Commons、Apache Flume、Apache Logging Services 和 Apache Maven 的 PMC 成员。我创建了 Apache Log4j 2的初始版本,并继续将我的大部分精力放在提供支持和改进上,以使 Apache Log4j 2 成为目前从事软件架构师全职工作的 Java 开发人员的最佳日志记录框架。我在业余时间从事 Log4j 和其他开源项目,我通常从事我最感兴趣的那些问题。我一直梦想着全职从事开源工作,希望您的支持能实现这一梦想。