维护一个大型开源项目是怎样的体验?

(我认为)大型开源项目包含以下任意一个或多个特征: GitHub star 数量 1000 +每周都可以接收到多个 issues 或 PR有一些公司或其他项目在生产环境中使用任意一个或多个包管理系统中下载量巨大在项目所在领域中拥有较大关注度 可以从以下几个方面进行回答。 先介绍你的项目,用来干什么的? 在开发和维护的过程中遇到过哪些值得一提的事?有没有什么奇葩的 issue 或者 PR?对你的生活或者工作有没有造成影响(好的,坏的)?
关注者
6954
被浏览
345725
我来说一个面向最终用户的软件项目 Koreader (koreader/koreader · GitHub)。Koreader是跨平台的电子书阅读软件,支持多种文档格式,可以运行在Kindle、Kobo、PocketBook等电子书,以及Android和Ubuntu Touch设备上。目前Koreader在GitHub上有1400+ star,PR+issues超过1600个,有将近40名开发者为项目贡献了代码,在Transifex上有超过15种语言的本地化翻译。

Koreader最有特色的功能是PDF页面文字回流。和其他支持文字回流的PDF阅读软件不同,Koreader把PDF页面当成图像,按照行间距和词间距把页面分割成以词为单位的图像块,再将这些图像块适应屏幕重新排版。这种基于图像的PDF页面重排不仅支持扫描的PDF页面,还可以让大部分数学公式的结构在页面重排后保持完整,更多重排样例参考如何解决六寸的 Kindle 看扫描版 PDF 的问题? - 黄鑫的回答


Koreader是一个完全由社区驱动的软件项目,采用去中心化的管理方式。用户和开发者把bug和特性需求发到GitHub的issues列表里,由开发者自愿认领。开发者把实现或者修复的补丁提交Pull Request,由另一名或多名开发者评议然后合并。目前Koreader项目有11名开发者有合并PR的权限。这种“同行评议”的PR(peer-reviewed pull request)机制使项目不需要一个中心维护者仍然可以快速迭代

我们通过持续集成工具Travis CI(travis-ci.org/koreader/) 对主分支上的每个Pull Request运行单元测试和代码覆盖测试,一定程度上保证提交的代码不会破坏已有代码的功能。我在服务器上部署了一个每日编译(nightly build)的脚本程序,这个脚本机器人在每天的北京时间6点和18点会从GitHub拉取主分支上最新的代码,从Transifex上拉取最新的本地化翻译,所有测试通过之后会为Koreader支持的每个平台编译最新版本的软件包,然后将软件包自动发布到Koreader的OTA(over-the-air)升级服务器。在所有支持OTA升级的Koreader平台上,用户就可以一键下载增量更新安装最新的版本。所以,经常会有用户上午提交了bug报告,第二天就可以通过OTA得到问题的修复。

除了GitHub上的开发者社区之外,Koreader正在形成一个论坛形式的用户社区。在电子书阅读论坛比如国内的 Hi-PDA E-INK板块 和国外的 MobileRead 上都聚集了一大批Koreader用户。最让我感动的是,一些Koreader热心用户会不厌其烦地为新用户解答使用过程中遇到的问题,会从普通用户的角度为新用户写各种教程和指引。前几天MobileRead上的Koreader粉丝又在向管理员建议为Koreader开设专门的板块,貌似新板块正在建设中。

善用这些自动化工具,让机器尽可能代替人力来维护开源项目然后有更多的时间去实现设想的功能,我想这就是作为开源软件开发者和维护者极好的体验了。