选对开源软件,从做好「背景调查」开始
2023-7-12 18:44:5 Author: sspai.com(查看原文) 阅读量:29 收藏

除了个别霸道总裁,大概很少有人不喜欢开源软件。免费、透明、有参与感,如果挑选得当,能获得接近甚至超出收费商业软件的体验。

但难就难在「挑选得当」。

面对不断涌现的开源选项,很容易在浏览过程中挑花了眼。如果囫囵下载一堆试用,未免过于浪费精力。作为「免费」的代价,开源软件也有更高的概率在一段时间的维护后,被突然放弃或者面目大变,让之前投入的学习时间打了水漂,并带来更多的迁移成本。

其实,正如公司聘用员工之前要做背景调查一样,我们在「聘用」开源软件之前,也可以从多种维度对其项目质量和发展预期做出评估和预判,以便众中选优,减少试错成本。为此,本文希望基于个人经验,提供一些可以考虑的维度,供读者参考。

在具体讨论各个考察维度之前,先确定一些讨论前提:

  • 本文主要讨论「个人自用」场景下的选择,因此一些标准可能有所调整或简化,也未必适合服务器、商用等场景;
  • 本文侧重于在选择开源软件之前判断其尝试价值,至于软件本身质量的评价标准,不在本文的讨论范围内;
  • 文中对一些现象、做法和具体软件的批评是个人观点,旨在就事论事,并不意味着对相关开发者为开源工作所做无偿贡献的否认。

两大无用标准:「繁星点点」和「榜上有名」

俗话说,重要的事放在最后说,那在开头我们就先说些最没用的。

作为 GitHub 影响最深远的发明之一,星标最大的问题在于它可以表示任何含义——欣赏创意、佩服技术、留作收藏——结果最终无法表示任何含义。此外,作为一种只增不减的指标,星标的价值也严重受限于「通货膨胀」现象;更不要提畸形动机催生的「造星」黑产

一个典型的「造星」现场(来源:Dagster)

因此,虽然星星数在某些局部意义上仍有一定参考性(例如比较两个同类、同时代项目的人气),也可以通过一些工具和方法抑制上述那些噪音的影响(例如使用 star-history.com 等工具观察增长历史),但逐一「降噪」的成本过高,最简单的方式就是不看;大多时候,你因此错过的只是一些「败絮其中」的门面工程。

与此相关,另一项 GitHub 土特产——各种以 awesome 开头的列表,也随着时间推移越来越失去参考价值。(经历过手机测评早期时代的朋友应该都知道不要随便说 awesome 会变得不幸的道理。)

罗素哭泣的,专门收录 awesome 列表的 awesome 列表

与表面上的权威和全面不同,这种列表往往只能反映出少数维护者的主观判断、疏于剔除过时项目,有的还受商业利益驱动,从中找到理想选项的概率和效率都极低。翻阅这种列表,大多数时候能带来的无非是「错过焦虑」被暂时抚慰的虚幻满足感。

维护时长

在选择开源软件时,一个主要顾虑就是「这个软件还能活多久」;的确,有很多凭一时兴致启动的开发工作,都会在几个月或一两年之后随着兴趣消散、激励不足等原因放弃。

有没有什么可以帮助预测的标准呢?最简单的选择其实就在手边。

根据「林迪定律」(Lindy’s Law),一个东西已经存续的时间越长,可以合理预期的未来寿命就越长。这固然仅仅是一个经验法则,但在开源领域有一定道理:如果一个软件已经开发了十几年,可以合理相信其维护工作对于开发者是可持续的,突然弃坑跑路的可能性很低、或者至少更容易找到接棒人。

遗憾的是,GitHub 并没有明确展示项目存续时间的功能,甚至代码提交历史页面都没有「跳到最后一页」的选项。但天无绝人之路,除了用第三方工具,我目前找到的最简单方法是:

  1. 在项目主页切换到 Insights 标签页,然后选择 Network,打开项目的提交时间轴。
  2. 在这个界面,按 Shift + (左箭头),就能跳转到时间轴的最左端。

这样,项目何时诞生就一目了然了。

更新频率

另一个与时间相关的观察角度是更新频率。但可能与直觉不同的是,更新并不是越频繁越好。

为了说明这个问题,首先有必要区分提交(commit)和发布(release)两种「更新」:

  • 开发者将经过修改的代码写入存储库,为代码的这个状态形成一个「快照」,称为一次「提交」。
  • 将代码库某一时刻的快照冻结下来,打包(往往还伴随着编译)后分发给用户,才是一次「发布」。

因此,提交不一定意味着发布,发布所基于的也不一定是最新提交的代码。

如果一个项目提交记录比较多,至少能说明维护者还在积极关注这个项目;但另一方面,如果看到很多提交没有实质内容、或者没有清晰的提交信息,可能反而说明项目维护缺少组织和章法,是一个减分项。(GitHub 的「贡献热力图」功能可能为滥发提交提供了一些不当激励。)

至于版本发布,其频率需求也要视项目特点而定。

  • 对于那些依赖或辅助外部服务发挥功能的软件,例如 yt-dlp 这样的视频下载工具,或者 n8n 这样的自动化平台工具,那确实需要经常更新,否则就意味着过时。
  • 但对于功能集比较明确、不需要太多「新意」的专一用途软件(例如编辑器、shell),以及支撑用户工作流程关键环节的软件(例如服务器软件、办公套件),太多的「惊喜」反而可能是一种「惊吓」。对于这种软件,相比于提供频繁的更新,制定并履行严格的支持周期政策才是更重要的标准。

知人论世

开源软件并不只是仓库里的代码构成的,更是由这些代码背后的人和组织搭建的。通过研究开发者的背景,很多时候就足以对项目的质量和前景建立一个合理的预期。

如果正在考察的软件是个人开发的,不妨顺手看看开发者在网上的活动轨迹。例如:

  • 点进 GitHub 个人页,看看作者是否参与过其他项目,以及那些项目的维护情况和受欢迎程度。
  • 尝试查找作者的个人网站,发现作者如果有写博客的习惯并且发过不错的内容,那就是一个很大的加分项(如果你是 RSS 用户,这个习惯也能帮你积累很多有意思的订阅源);如果文章能在 Hacker News 等技术社区搜到(搜索入口),并且引起过积极讨论,那恭喜你发现了宝藏。
  • 通过用户名、邮箱域名等线索,看看作者在其他平台的资料和活动。例如 LinkedIn 上的履历信息,Reddit、推特上的发言等。

如果这些信息能描绘出一个资历丰富、谦逊友善的开发者形象,出自其手的软件用起来自然也会更令人放心。

例如,我前段时间偶然发现一个小众 Firefox 分叉版 Floorp。简单检索,发现是日本的一个学生开发者从 2021 年开始维护的项目。再翻找开发者的其他账号,发现他在 Reddit 上比较活跃:对于项目为何默默无闻的疑问,他承认自己英语不好,没能顾及多在本国社区之外宣传;谈及项目与其他大量 Firefox 分叉版之间的异同,他反复表示开发重点在于可定制性,如果是为追求隐私保护,建议选择其他擅长加固的项目。

尽管这是第一次听说这个作品和作者,但这种诚恳的沟通方式已经能建立起不少信任。

而如果正在考察的软件是由组织维护的,除了像考察个人作者那样查询组织的背景和作品,还可以思考它参与贡献这个项目的「动机」是什么、这种动机是否能够持续。

如果发现是基金会、非盈利组织在维护,则可以进一步看看其治理结构和资金来源,从而判断运营理念和经济前景。由于很多开源组织在美国注册为 501(c)(3) 组织(名称来源于获得免税资格所依据的条文 26 U.S.C. § 501(c)(3)),需要接受公众监督,大多都会在网站的 Transparency 或类似板块披露运营报告,或者可以直接在 IRS 网站查询到它们申报的税务表格。

例如,Mozilla 基金会的信息表明他们并不是一个「草根」组织(2021 年收入 6 亿美元,CEO 薪酬 560 万美元);因此,旗下软件不温不火的发展情况、以及越发密集的变现业务,引起很多批评也是不太冤枉的。

Mozilla Foundation 和 Free Software Foundation 的财务情况

如果维护者是商业公司,则要考虑其是否可能由于自身的利益驱动和短视决策,与用户的利益发生冲突。这一般又分两种情况。

  • 一是这个开源项目就是公司的核心业务,其商业模式是通过「多重许可」模式,基于开源核心提供增值功能或服务并收费。这种项目一般比较稳定,但风险在于公司日后可能为了盈利而收紧免费功能的范围,就像去年的 Docker Desktop 收费和今年的 RHEL 停止公开提供代码所印证那样。
  • 另一种情况是这个开源项目并非公司的核心业务,甚至只是少数员工主导项目,其参与维护的动机主要是促进在开源社区的商誉,或者出于内部团队的业余兴趣。对于这种项目,就要考虑因人事和政策变动导致不能继续维护,或者服从于商业利益而「变味」的可能。至于风险高低,就取决于公司的历史口碑了;谷歌和微软在这方面都有「优秀」的记录。

需要指出,「知人论世」并不意味着要参与「站队」或者「吃瓜」。

从某种程度上说,开源软件领域的「吃瓜」氛围可能仅次于娱乐圈。一方面,这个领域卧虎藏龙,而「能人相轻」,相互之间很容易产生一些理念不合——所以开源领域总有那么外人看来一头雾水的「圣战」。

另一方面,参与开源讨论的渠道很广而门槛很低,很多新手仅凭看了几篇似是而非的帖子,未经实际尝试和严谨对比,就开始「站队」发表一些言之凿凿、非黑即白的片面判断,以显自己的高深。在线、异步、匿名的沟通方式也放大了对抗性而不是建设性的交流。

因此,对于任何有一定讨论度的开源软件或其开发者,只要想找,几乎总能找出一些负面评价:或是针对软件的某种设计或功能取舍,或是针对项目的「文化」或开发者的言行。但这对于判断软件的质量都没有实际帮助。众口批评的软件你用着正合适,「刺头」开发者的作品难以匹敌,都是完全有可能的。

总之,技术的归技术,社交的归社交。除非真的涉及一些公序良俗不容的原则问题(这种情况很少见),否则没有什么坊间评价能取代你自己的体验,也没有必要浪费时间去「吃瓜」。

例如,编辑器 Vim 和电子书管理器 Calibre 的开发者在很多讨论中都是有点「刚愎自用」的形象,一个曾强硬拒绝用户贡献的多线程功能(直接引致了 Neovim 的分叉)、一个曾豪言要自己接盘 Python 2 并在项目中接着用,结果日后都被打脸;但这并不影响 Vim 和 Calibre 仍然是各自领域具有标杆地位的软件。如果你因为这种非技术因素而选择直接跳过不用,那么可能会错过不少好东西。

“I am perfectly capable of maintaining python 2 myself.”

文档质量

文档质量可能是近年来软件行业退步最明显的方面之一。传统上,文档对于软件项目是如此重要,以至于版权法对「软件」的定义不仅包括「计算机程序」本身,还延伸到程序设计说明书、流程图、用户手册等「文字资料和图表」。早年,一本详尽的用户手册几乎是任何软件的必备。但如今,很多软件的「帮助」菜单空空如也,甚至连 README 都不愿意多花笔墨了。

当然,一种解释是如今用户的计算机素养普遍提高了,很多操作也是相通的,不需要反复解释;好的软件甚至本就应该是用法「不言自明」(self-explanatory)的。但这都不是不提供文档的借口。如果你有过对着怎么填都不对的配置框抓耳挠腮、无处求告的经历,你就曾经是文档缺失问题的受害者。

因此,即使是比较简单的项目,也至少应该有一个完善的 README,也就是你在项目主页看到的内容。其中,「完善」指的是这些基本内容和要求:

  • 简洁易懂的功能概述。这方面请相信你自己的第一印象:如果你读了几遍都不知所云,那就是写的有问题。
  • 清晰、详略得当、考虑不同平台特点的技术信息:安装方式(installation)或部署方式(deployment)、基本用法(usage)和示例(examples)。
  • 和技术无关,但很能体现开源素养和礼仪的内容:贡献指引(contributing,包括接受哪些类型的社区贡献,以及对提交渠道和格式的要求),清晰、完整、准确的许可信息(license),以及致谢(acknowledgements)信息。
  • 一些加分项:技术栈(tech stack)、常见问答(FAQ)、开发路线图(roadmap)等。对于服务端软件,还宜有演示服务器(demo instance)和 API 参考;对于命令行工具,还宜有遵循规范手册页(manpage)。
  • 整洁的排版和格式。专有名词的拼写规范,斜体、粗体、链接、行内代码和代码片段的用法,图片的格式和标注,都是容易被忽视、但很能说明基本审美是否过关的细节。至于 emoji……我对 emoji 没什么偏见,但如果你见到一个 🚨 恨不得在每句话之前 👏 加一个 emoji 的 👀 README,掉头跑吧 🏃‍♀️,现在还来得及❗️
优秀「作业」展示:Lima 和 fzf

文章来源: https://sspai.com/prime/story/foss-how-to-select
如有侵权请联系:admin#unsafe.sh