构建更可插拔的开源文化

还没有读者喜欢这个。
Person in a field of dandelions

Opensource.com

如果用一个词来概括开源的好处,那就是选择。我们经常赞扬 800 多个 Linux 发行版、无数的桌面、应用程序、框架等等。选择,似乎是一件好事。

有趣的是,选择也是一种情感化的东西。

我记得当 Unity 桌面发布时,一封又一封愤怒的邮件声称功能被删除,选择的能力被剥夺。虽然我们社区中比较冷静的成员提醒这些批评者还有许多其他桌面选择,但许多批评者仍然哀叹他们的选择受到限制。

我对此一直有两种想法。一方面,我尊重和重视有主见的设计。我喜欢看到一些项目不仅表明他们成为什么,而且表明他们不会成为什么。例如,我喜欢 Elementary 团队在定义清晰、有主见的方向方面所做的工作。

另一方面,不符合您需求的软件可能变得无趣、无关紧要,甚至令人沮丧。通常比不能满足您需求更糟糕的是,得到一些大部分满足您需求的东西,但却遗漏了一些舒适的功能。通常,选择可以弥合这一差距。

或者,选择的另一面可能是提供过多的选项,以期服务所有用户。可悲的是,这些项目可能会让用户感到不知所措,并且在提供选择的同时,也会在使用软件时产生认知迷雾。

但是,还有另一种方法,我越来越喜欢它。

一个简单的核心

不久前,我开始使用 Atom 编辑器。

Atom 开箱即用地提供了一个相当简单的核心编辑器。它提供了大多数用户可能需要的大部分核心功能和设置,但缺少一些用户可能需要的更高级或更具体的功能。这就是包系统发挥作用的地方。

Atom 提供了一个强大的框架,几乎允许更改和扩展 Atom 的任何部分。然后,此功能在包系统中公开,以便可以轻松创建、共享、安装、更新和配置这些自定义项。有用于快捷键绑定、代码审查、颜色选择、用户界面更改、GitHub 集成等的包。

这意味着 Atom 可以根据不同用户的特定需求进行调整;您只需打开您想要的部件即可。想要一个功能最少的简洁 Atom?没问题。想要一个功能齐全的 IDE 风格的 Atom?没问题。想要根据您正在处理的代码或项目类型获得完全不同的 Atom 体验?没问题。

Atom 并不是唯一这样做的软件。另一个很好的例子是 GNOME Shell,我 不久前写过一篇关于它的文章。GNOME Shell 具有集成的扩展系统,允许您根据自己的精确喜好调整桌面。

一种强大的方法

简单、简洁的核心和强大而简单的扩展/插件系统的概念在许多方面都很出色,有些显而易见,有些则不那么明显。

一个显而易见的好处是用户手中的选择。我们都不同,我们都有不同的想法、偏好、烦恼和怪癖。一个更可插拔的平台提供了一个服务更多人并交付满足各种需求的软件的机会。它还为配置文件视图的概念打开了可能性,您可以在其中为不同的用例加载插件集合,并使切换变得简单。例如,想象一下,与 Vala 相比,编写 Python 时 Atom 体验完全不同。或者,想象一下,为不同的桌面、Web 平台、企业或其他地方编写代码时,Atom 体验有所不同。

这种方法还开启了插件经济。本质上,这意味着您不必拥有每个人都必须使用的功能的单一实现。如果您不喜欢 Atom 中的代码审查包,您可以构建自己的包,或者 Fork 并改进现有的包。一个良好实现的插件系统将为最流行和最有能力的实现浮出水面提供机会。这确保了工具保持新鲜——更新和更好的功能实现可能会胜过那些停滞不前的功能。这大大减少了惰性的产生,并为每个人创造了创新并让他们的工作浮出水面的机会。

插件经济也为多样性创造了机会。将核心功能纳入主要项目对于许多人来说在技术上和社交上都是一项艰苦的工作。插件经济为任何人提供了一个机会来创建出色的功能,通过平台的插件系统公开它们,并让他们的工作受欢迎程度上升。这为那些通常无法将功能融入核心产品的贡献者提供了一个展示出色、周到工作的机会。

当然,框架方法也存在挑战。首先,保持核心简单并抵制包含流行插件或功能的诱惑(从而破坏项目可扩展性的目的)非常重要。

其次,框架方法对入门体验和培训提出了挑战:在文档和指南中可以并且应该假定哪些插件?

第三,平台中可发现且能够使用各种指标将最佳软件包推向顶峰的插件/软件包管理系统至关重要。

最后,框架方法取决于拥有一个真正可破解但安全的平台。这是一个复杂的架构考虑因素。

未来

虽然框架方法可能难以实现,但我认为机会是巨大的。回到 UNIX 的旧时代,平台被定义为一组可以以有趣的方式组合在一起的工具。这使得 UNIX 成为一个非常强大的系统——不同的工具可以连接并服务于几乎无限数量的用例。

如果我们能够构建更可插拔的开源文化,那么我们进一步扩展范围并服务更多用户的潜力是巨大的。它还为人们提供了一个令人难以置信的社区入门途径,让他们可以通过插件而不是对核心代码进行重大贡献来试水。这可以使更多人参与开源,建立成功的信心,并使我们更广泛的社区多样化。

我喜欢 Atom 和 GNOME Shell 中对此的周到实现,我希望看到其他项目也使用类似的方法。你怎么看?您是否也认为这将是一种更好的做事方式?

User profile image.
Jono Bacon 是一位领先的社区经理、演讲者、作家和播客。他是 Jono Bacon Consulting 的创始人,该公司提供社区战略/执行、开发者工作流程和其他服务。他还曾担任 GitHub、Canonical、XPRIZE、OpenAdvantage 的社区主管,并为多家组织提供咨询和建议。

2 条评论

我不一定 100% 确信这始终适用,可以被认为是好事(TM)。我可能会将以下内容视为例外

* 固有的复杂应用程序。本着 Atom(以及 Emacs 和各种其他程序)的精神,是的,您可以将文本编辑器扩展为一个完整的 IDE。但是,如果您的主要重点是开发完整的 IDE(NIHS,等等)或功能齐全的文字处理器,那么简单的核心概念就会开始退化。

* 当您开发高度可扩展的应用程序时,您还需要创建另一类需要支持的用户(扩展开发人员)。如果您已经很难提供常规用户文档,那么添加额外的用户层是一项不可忽视的维护成本,需要考虑在内。它还增加了代码的复杂性……使其更不简单。

* 我要戴上我的偏执狂帽子了,但可扩展性也为商业劫持打开了大门。有一类应用程序致力于为用户提供完成任务(或一组相关任务)所需的所有工具。但是,当用户被迫依赖第三方扩展程序来完成工作时,原始应用程序就未能完成其使命(尤其是在这些扩展程序最终成为闭源的情况下)。有时您需要决定您是在编写用户应用程序还是在编写库/框架。您不可能总是两者兼顾。

* 但是,即使一切都保持开放,这种可扩展性也会带来用户层面的复杂性。您会遇到这样的支持问题:“为什么我不能做_____?” 答案最终是:“如果您使用这些扩展程序,您就可以做到。” 而且,不可避免地,随之而来的是,“我到底是怎么知道的?” 如果没有某种发现引擎,可扩展性就行不通。软件包系统会有所帮助,但这又是另一层复杂性(此外,这可能会引入与正在使用的操作系统或发行版的本机软件包系统竞争的概念)。

好的……我在这份回复中写了很多内容(可能比格式舒适支持的要多),但对我来说,我想您可以将其归结为“不。它不总是更好。” 如果您围绕该概念构建项目并完成所有脚手架以支持它,那么它可以更好……但我会警惕(例如)建议大多数现有项目开始朝着这个方向转变。

Jono,这是一篇很棒的文章。我特别喜欢对我们这些老家伙的提醒——很多原始 Unix 实用程序中固有的基本设计原则:this_command -xyz | that_command -abc | the other command -pqr,我们可以做我们想做的几乎任何事情。

恕我直言,除了 Kernighan、Pike 等人的伟大著作之外,实现这种互操作性的原因是标准输入/标准输出和管道提供的粘合剂。即,基本上是 shell 公开的功能。

也许这就是您指出的背景下缺少或具有挑战性的地方;我们没有等同于“shell”的东西来公开可以挂载插件的真正有用的钩子。一般来说,无论如何。因此,也许 Gnome Shell 做到了这一点;我还没有玩过它,所以不知道。

显然,阅读 Jason Van G 的帖子,我们缺少的东西之一是类似于 Kernighan、Pike 等人的连贯而充满活力的指南。

Creative Commons License本作品根据 Creative Commons Attribution-Share Alike 4.0 International License 获得许可。
© . All rights reserved.