选对开源软件，从做好「背景调查」开始

A version of this article appears on Jul. 12, 2023 on SSPAI as a member-only post. Learn more or subscribe

The article is permitted to be self-archived in the version as originally submitted for publication on the author’s personal website under CC BY-NC 4.0 pursuant to § 5.2(b) of the SSPAI Fellowship Contributor Agreement.

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

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

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

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

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

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

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

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

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

因此，虽然星星数在某些局部意义上仍有一定参考性（例如比较两个同类、同时代项目的人气），也可以通过一些工具和方法抑制上述那些噪音的影响（例如使用 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 万美元）；因此，旗下软件不温不火的发展情况、以及越发密集的变现业务，引起很多批评也是不太冤枉的。

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

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

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

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

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

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

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

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

文档质量

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

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

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

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

如果软件功能比较复杂，最好就有更详尽完整的文档和参考，可以用 GitHub 的 Wiki 功能，也可以单独建一个文档站点。

这里还需要留意的是，判断文档质量的关键在于内容，而不是外观。如今，在各种现成模板和框架（例如 Docusarus 或 Material for MkDocs 等）的帮助下，制作出一个审美过关的文档页面已经越来越容易。但看看早期软件用纯文本做出的帮助文档，再看看当下很多项目空有一身漂亮皮肤的残缺文档，只能说是高下立判。

问题（issue）管理

看开源软件的 GitHub 页面时，README 并不是唯一重要的内容。如果要判断项目的「健康度」，隔壁的 Issues（问题）标签页可能更值得一看。

问题的追踪和管理是一件需要功力的事情。issue 是个比较宽泛的概念，可以指项目相关的任何讨论点或工作事项；从故障提报、功能新增和改进建议，到文档补全、疑问解答，都可能成为一个 issue。此外，用户在提报 issue 时一般不会想得那么多，发布的内容往往需要进一步筛选、整理和拆解，才能进入开发流程中予以处理。

因此，Issues 页面实际上就成了维护者对自己任务管理能力的一种公开展示。从 Issues 页面的利用率和整洁程度，就能在相当程度上看出这个项目的组织是否有序。一般来说，维护得当的 Issues 页面有这些特征：

• 大多数问题都被打上了适当标签；
• 新问题提交框中有适合项目情况的预置模板；
• 没有积压太久且未响应的未关闭问题（未关闭问题多本身不是问题，可能反而说明社区活跃，关键在于响应率）；
• 已关闭的问题有合理解决或答复，没有不由分说强行关闭问题的现象（当然，不看规则无事生非的问题除外）

举个例子，Android 平台名气较高的开源电子书阅读应用中，KOReader 的 issue 追踪流程明显比 LiberaReader 规范很多：绝大多数 issue 都有标签归类，标签的类型也做了高度定制，以涵盖适配的设备类型、涉及的功能模块等；每月更新的发布说明中，还会逐一将新增或修复的功能链接至原始的 issue。相比之下，LiberaReader 的 issue 维护就显得比较粗疏了。

此外，如果你对软件的特定功能有一些预期或疑问，也可以先通过搜索功能看看是否已经有人提出过，响应结果是否令你满意。如果有个想要的功能开发者明确表示不会做，那就可以再去找找别的选择，节约尝试的时间。

用户社区

开源软件本质上是一个「众人拾柴火焰高」的模式，社区的力量在这个模式中格外重要。如果能形成一个成熟的社区来提供的反馈、插件、文档和答疑等「公共服务」，将是一项突出的软实力，甚至能在很大程度上弥补其他方面的不足。

例如，纯粹从技术审美角度看，拖着 Electron 这个累赘外壳的 VS Code 肯定不是最优雅的编辑器，代码库中积累了多年包袱的 WordPress 也不是最优雅的博客框架。但是，如果你要寻找一个插件或主题，VS Code 和 WordPress 的市场就是更有可能给出合适的选项；如果你遇到技术问题或者想通过 API 接入第三方应用，就是更容易找到针对它们的现成解决方案。

这就是为什么尽管更新更酷的「挑战者」层出不穷，但它们仍然作为各自领域的首选项屹立不倒——在最初的新鲜劲过后，需求实现起来省事、出了问题能解决才是硬道理。

因此，在比较几种开源软件的时候，可以通过下面这些方面观察其社区的规模和质量，然后再做决定：

• 在 GitHub 页面，观察贡献者（Contributors）的人数、Issues 和 Discussions（如果有）页面的活跃程度；
• 如果提供扩展能力，例如支持插件、主题等，则可以关注第三方插件和主题的数量；如果官网有插件市场、案例展示等板块，还可以按时间倒序排列观察更新频率；
• 如果开设官方论坛，观察发帖频率和质量；
• 在 Hacker News、Reddit 等社区搜索项目名称，观察在讨论中被提及的频率。

值得提出，近年来，有一种用即时通讯软件充当用户社区和反馈渠道的「流行趋势」：很多「时髦」开源项目介绍中，除了标题以外最醒目的就是 Discord 链接或微信、QQ 群二维码。

这种做法是值得警惕的。从技术角度看，这么做使得信息隔绝于网络索引，既不利于开发团队追踪，也不利于新用户检索，而且受制于第三方平台的「生杀予夺」。从沟通效果看，任何参与过「水群」的人都知道，无主题、无规则的即时通讯很难产生什么有价值的讨论和有意义的关系，反而为噪音和争论提供了空间，维护和主持起来对于开发者是很大的精力分散。

当然，不能完全否认 Discord 和微信群「接地气」的优势，但我无法想出任何一个经典开源项目是把它们作为唯一社区渠道的。因此，如果下次看到一个项目上来就请你「进群」，同时 Issues 页面空空荡荡，那最好先想想这个局是否还是不入为妙。

发布渠道

GitHub 是目前最主流的代码托管平台，但并不是唯一的平台，常见的替代选择还包括 GitLab、Codeberg 和新兴的 sourcehut 等；有的项目还会选择自建 Git 托管服务。

开源软件选择替代平台的原因各不相同：有的是无法被 GitHub 较为严格的版权政策容纳、或者已经吃了 DMCA 通知；有的是因为不认同 GitHub 的控制权归属——微软在开源社区的恶名并不会因为做出拥抱开源的姿态而消除；还有的是因为不接受特定政策或做法，例如去年争议很大的用公开代码训练 Copilot AI。一言以蔽之，和 GitHub 的大平台病「八字犯冲」（少数确实明显违法侵权的除外）。

也正因此，选择替代平台的项目大多有些「傲骨」，并且普遍反映出对精简、隐私、自由的强烈偏好；如果你希望寻找满足这些条件的项目，不妨优先从替代平台寻找。

例如，suckless.org 上有一批上手门槛不低，但定制性极高的工具，包括在 Linux 美化（ricing）社区非常受欢迎的启动器 dmenu 和窗口管理器 dwm；之前介绍过的「替身前端」（alternative frontend）中，Teddit（代替 Reddit）、Rimgo（代替 Imgur）和 LibRedirect（自动跳转插件）等都托管在 Codeberg 上。

当然，凡事有两面，这类项目也有更高概率存在上面提到的刚愎自用、人手不足等问题，需要综合考察。

还有一些替代选择，几乎就是纯粹的红牌因素了。一是 SourceForge，留在上面的软件几乎都和这个平台一样处于过气和被遗忘的状态，需要谨慎考虑。二是国内的 Gitee，如果只是用它来做其他平台项目的国内镜像，倒也不失为一种贴心做法；但如果是当作主要的托管平台……可能真的只是为了行为艺术吧。