最强编辑器 Vim 之父 Bram Moolenaar 去世,Vim 项目谁来接管?
「如果有一天,开源项目的开发者、维护者出现了意外,遗留的项目该何去何从?」
虽然这并不是一个新出现的话题,但是对于主流的文本/代码编辑器 Vim 而言,却是当下迫切需要解决的问题。
8月5日,Vim 之父BramMoolenaar 的家人发布讣告:“我们怀着沉重的心情通知您,Bram Moolenaar 于2023年8月3日离世”,享年62岁。
一直以来,Bram Moolenaar 被称为 Vim 项目的 BDFL(Benevolent Dictator For Life,终身仁慈独裁者),管理着 Vim 项目的各个方面,他的去世让无数使用过 Vim 的用户感到痛心,这也是整个 Vim 开发社区一个沉重的损失。
他的离开给项目留下了巨大的空白。对于 Vim 的下一步,该如何走?在 GitHub 上的Vim 项目Discussions 页面中(https://github.com/vim/vim/discussions/12736),有网友讨论:
这里有人有存储库的提交访问权限吗?
现在谁还能体现 Vim 的品质呢?
就在昨日,在 vim_dev 邮件列表上,传来了 Vim 项目未来的最新消息。
核心开发者接手,但困难重重
事实上,Vim 主仓库除了Bram Moolenaar外一直还有两位重要开发者参与其中,其中一位是参与维护 Vim 近18年的 Christian Brabandt,他目前是 Ataccama 的解决方案顾问;另一位是参与维护 Vim 也有十几年的 Ken Takata。
当前,在 vim_dev 邮件列表上,由Christian Brabandt 牵头,发起了一个关于“Vim 项目未来”的讨论。
幸运的是,Christian Brabandt 透露,他和 Ken 已经从 Bram 家人那里获得了 Vim 在 GitHub 上的管理权,可以继续访问 GitHub 项目组织。
同时,他也邀请过去曾为 Vim 做过贡献的开发者加入 Vim 组织,协助一起维护项目。
然而,彼时 Bram 作为终身仁慈独裁者,在该项目社区出现争议时拥有最终的决定权。现如今,其接任的开发者没有。
而且,Bram 对 Vim 项目的未来,有着自己独特的见解与规划。如今的接任者,由于缺乏相关经验,在没有指导的过程中临危受命,必然困难重重。
在这一点上,Christian Brabandt 也在邮件中袒露心声。其表示,虽然当前已经开始合并 commits,但是仅是尝试合并 Bug 修复、安全补丁和文档更新等其他明显的改进。
其次,在接手过程中,Christian Brabandt 也承认遇到了诸如管理权限等问题。他表示:
Bram 是所有邮件列表的所有者。我还不知道他是如何管理这些邮件列表的,以及如何申请访问 vim-announce 和 vim-mac(这两个邮件列表是否仍在使用?)
邮件列表 vim-dev 和 vim-use 目前由我、Tony Mechelynk、John Beckett、Ben Schmidt 和 Ben Fritz 管理(我认为后两位至少不再活跃于 Vim 项目,请通知他们是否仍有兴趣管理该列表)。
我还无法访问主 Vim FTP 服务器。目前正在与 Brams 家人核实他们是否知道相关凭证。
我正在联系所有运行时文件的维护者,以了解他们是否直接向 Bram 发送了任何文件,否则这些文件可能会丢失。
“在我们知道如何正确处理所有这些问题之前,我们需要一些时间(当我们都同意采用更好的方法时,可能会有所改变)”,Christian Brabandt 在邮件中写道。
Vim 项目的几点规划
除了以上,Christian Brabandt 还在邮件列表中列出了几项内部亟需解决也是外界颇为关注的问题。
其一,Vim9.1是否会到来?
对于这个问题,答案是 Vim9.1会大概率地出现。
Christian Brabandt 表示,在我们处理完当前的积压工作后,我希望能发布 Vim9.1维护版本。
当然在此之前,其打算继续发布一些关于补丁的版本。
其二,Vim 与 NeoVim 未来如何共处?
在未来 Vim9.1版本发布之后,Christian Brabandt 表示,想改用更现代的方法,即类似于 Neovim 的做法来开发 Vim。
不过,他也表示,「但正如在其他地方讨论过的,这可能会对不同的子项目产生一些影响:vim-win32-installer、vim-appimage、macVim,所以不确定什么是最好的方法。」
此话一出,有不少开发者直接提议,“希望 Vim 团队能够与 Neovim 团队沟通一下,最好是社区能够融合”。
所谓 Neovim,是一个社区驱动的开源项目,是 Vim 文本编辑器的一个分叉版本,它的构建使 Vim 更容易为核心开发人员维护,它是 Vim 文本编辑器的一个增强的开箱即用版本。
那么是否有这种可能性?
其实早几天前,Neovim 团队在官方博客上发布了一篇悼念 Bram Moolenaar 的文章时,就间接地告诉了外界:不太可能。
Neovim 团队写道:
“Neovim 一直被有意定位为 Vim 的衍生产品,这意味着它既延续了 Vim,又与 Vim 有所不同。我深信,分叉可以创造能量,而不是破坏能量。因此,尽管我们无法在没有 Bram 的情况下提供 Vim,但我们可以延续一些重要的部分:
维护:实验是好事,这个世界需要创造性的破坏和有趣的失败。但 Neovim 并不代表贪新("neomania")。
文档:Vim 文档的习惯显而易见,这也是 Nvim 在vim 基础上获得的最大收获之一。
可扩展性:Bram 自己的 Agide 项目也希望实现与 Neovim 类似的可扩展性:
Agide 并不是一个单一的应用程序。可以插入不同的工具。因此,你不会被迫使用一种编辑器。... 每个工具都实现了部分插件接口。
嵌入:Vim 的设计--在其生命的大部分时间里都在宣扬 Neovim 的这一信条:
Vim 不是 shell,也不是操作系统。......反之亦然:在 shell 或 IDE 中将 Vim 作为组件使用。
还有一点:Bram 并没有把自己看得太重。他有自己的幽默感。
Neovim 是 Vim 和 Bram 的纪念碑。我们应该务实,而不是教条;我们应该记住目标是什么,并将我们的行动与结果进行比较。”
另外,也有知乎网友评论道:
与此同时,HN 上的不少网友也抵触道,”如果 Vim 没有新功能,我不会关心。如果 Vim 不再维护但仍然可以从发行版中获得,我仍然会使用它。如果 Vim 变得不可用(例如由于缺乏维护),我更有可能切换到 nvi 而不是 Neovim。“
不过,很多人认为,Neovim 在未来可能会比 Vim 发展得更强劲。
其三,Vim 项目主页迁移与开源?
在主页近期经常不稳定的情况下,Christian Brabandt 也提出了自己的解决方案和想法。
他表示,「在过去的几个月中,Vim 主页在稳定性方面遇到了一些问题,尤其是与 MySQL 服务器的连接问题(我目前也无法直接访问 vim 项目页面,因为 osdn.net/projects/vim 对我来说似乎是关闭的,但我怀疑这个页面是否真的有人在使用)。它目前由 OSDN.net 运营,由 Shuji Sado(前首席执行官)自2018年起提供。」
不幸的是,OSDN.net 现在显然归 OSChina 所有,他们目前还没有得到 OSDN.net 或 OSChina 团队的任何支持。所以,他也在考虑将 Vim 主页转移到另一家提供商。
另一方面,过去,Christian Brabandt 曾与 Bram 讨论过将主页开源的问题,由此可以接受大家的贡献,保持主页的更新,使其看起来更现代化。但那时 Bram 并不希望这样做,他担心会泄露一些敏感信息(或使任何潜在问题更容易被发现)。
”这当然是有道理的,所以还不知道如何处理“,Christian Brabandt 说道。
在邮件列表中,对于 Vim 的主要源代码,Christian Brabandt 希望在合并任何内容之前得到其他项目成员的批准。而面对遗留的一些问题,其希望能够在团队中商量着来。
开源作者去世后,项目谁来继承?
经历此番事件,也引发了我们在文章伊始提出的”开源作者去世后,项目谁来继承“的思考。
其实,未雨绸缪的思想在任何场景下都需要。有用户表示,”数字遗产是现代人必须要思考的事情,未来会发生什么事没人知道。“
当开源开发者去世或者出现意外时,通常会有以下几种可能性继续维持项目的发展:
社区继续维护:如果该开源项目有一个活跃的社区,那么其他贡献者可能会继续负责维护和更新代码。社区成员可以自愿地承担领导角色,接管项目的管理和维护工作。
团队接管:有时,开源项目的作者可能会提前计划,选择一些核心成员或团队来接管项目的维护权。
分叉项目:如果没有人愿意或能够继续维护项目,其他开发者可能会选择创建一个分叉项目,将原始项目的代码复制一份,并在此基础上进行维护和改进。
捐赠基金或组织:有时,可能会成立一个捐赠基金或组织,用于维护和支持该开源项目。资金可以用来雇佣开发者、进行代码审查以及确保项目的持续运作。
项目被放置不变:如果没有任何人愿意或能够继续维护项目,那么项目可能会被放置不变,直到有人再次愿意接手或者社区重新组织。
所以,让 Vim 社区非常庆幸的是,虽然未来还存在巨大的挑战,但是好在有 Christian Brabandt 等开发者可以继承 Bram 的遗志,把他耗费多年心血打造的 Vim 工具继续传播延续下去。
参考:
邮件列表内容:https://groups.google.com/g/vim_dev/c/dq9Wu5jqVTw
https://news.ycombinator.com/item?id=37074452
https://github.com/vim/vim/discussions/12736
- 0000
- 0000
- 0000
- 0001
- 0000