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

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

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

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

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

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

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

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

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

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

与此相关，另一项 GitHub 土特产——各种以 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，掉头跑吧 🏃‍♀️，现在还来得及❗️