Building a culture of more pluggable open source

No readers like this yet.
Person in a field of dandelions

If there is one word that often percolates conversations hailing the benefits of open source, it is choice. We often celebrate many of the 800+ Linux distributions, the countless desktops, applications, frameworks, and more. Choice, it would seem, is a good thing.

Interestingly, choice is also an emotive thing.

I remember when the Unity desktop launched, and email after email of angry messages claimed that features were being ripped out and the ability to choose was being taken away. While the calmer members of our community reminded such critics of the many other options available as desktops, many of the critics still wailed about their choices being restricted.

I have always been in two minds about this. On one hand, I respect and value opinionated design. I like to see projects that put their stake in the ground of not just what they will be, but also what they won't be. As an example, I love the work the Elementary team are doing in defining a crisp, opinionated direction.

On the other hand, software that doesn't meet your needs can be uninteresting, irrelevant, or even frustrating. What often can be worse than something that doesn't do what you want is getting something that does most of what you want, but then leaves out a few of the creature comforts. Often choice can bridge this gap.

Alternatively, the circus mirror of choice can be providing too many options with the hope of serving all users. Sadly these projects can overwhelm users, and while delivering choice also deliver cognitive fog when using the software.

There is though another way, and I am increasingly becoming a fan of it.

A simple core

A little while back I started using the Atom editor.

Atom provides a fairly simple core editor out of the box. It delivers the majority of the core features and settings that most users likely will want, but is missing many of the more advanced or specific features some users may want. This is where the package system comes into its own.

Atom provides a powerful framework that allows pretty much any part of Atom to be changed and expanded. This functionality is then exposed in a package system so these customizations easily can be created, shared, installed, updated, and configured. There are packages for key-bindings, code review, color selection, user interface changes, GitHub integration, and more.

This means that Atom can be tuned to the specific needs of different users; you just switch on the pieces that you want. Want a sleek Atom with minimal features? No problem. Want a full-featured IDE-style Atom? No problem. Want an entirely different Atom experience depending on what type of code or projects you are working on? No problem.

Atom is not the only software to do this. Another wonderful example is GNOME Shell, which I wrote about a little while back. GNOME Shell has an integrated extensions system that allows you to tweak the desktop to your precise liking.

A powerful approach

This notion of a simple, sleek core and a powerful yet simple extensions/plugins system is brilliant for many different reasons, some obvious and others less so.

An obvious benefit is the choice put in the user's hands. We are all different, and we all have different ideas, preferences, annoyances, and quirks. A more pluggable platform provides an opportunity to serve more people and deliver software that meets a variety of needs. It also opens up the potential for the notion of profiles or views, in which you could load a collection of plugins for a different use case and it makes switching simple. For example, imagine a totally different Atom experience when writing Python as compared to Vala. Or, imagine a different Atom experience when writing for different desktops, web platforms, enterprises, or elsewhere.

This approach also opens up a plugin economy. Essentially this means you don't have to have one implementation of a feature that everyone has to use. If you don't like the code review package in Atom, you can build your own, or fork and improve the existing one. A well-implemented plugin system will provide an opportunity for the most popular and capable implementations to float to the surface. This ensures that the tool stays fresh—newer and better implementations of feature may trump the stalwarts. This significantly reduces lethargy setting in, and creates an opportunity for everyone to innovate and have their work bubble to the surface.

The plugin economy also opens up an opportunity for diversity. Getting core features into major projects is hard work both technologically and socially for many people. A plugin economy provides an opportunity for anyone to create great features, expose them via the plugin system of a platform, and have their work rise in popularity. This provides a chance for contributors who would ordinarily not be able to get features into a core product be able to showcase great, thoughtful work.

Of course, there are challenges with the framework approach, too. First, keeping the core simple and resisting the temptation of including popular plugins or features (and thereby defeating the purpose of the extensibility of the project) is important.

Second, the framework approach raises challenges with the on-boarding experience and training: Which plugins can and should you presume in documentation and guides?

Third, a plugin/package management system in the platform that is discoverable and able to bring the best packages to the top using a variety of metrics is essential.

Finally, the framework approach depends on having a truly hackable platform, but one that is safe. This is a complex architectural consideration.

The future

Although the framework approach can be challenging to deliver, I think the opportunity is huge. Back in the old days of UNIX, the platform was defined as a set of tools that could be strung together in interesting ways. This made UNIX a tremendously powerful system—different tools could connect and serve an almost infinite number of use cases.

If we can build a culture of more pluggable open source, the potential for us to reach further and further afield and serve more users is profound. It also opens up an incredible community on-ramp for people to dip their toes into a project with a plugin, than with a big contribution to a core piece of code. This could empower more people to participate in open source, build the confidence to succeed, and diversify our wider community.

I love the thoughtful implementation of this in Atom and GNOME Shell, and I would like to see similar approaches used in other projects. What do you think? Do you think this would be a better way of doing things, too?

User profile image.
Jono Bacon is a leading community manager, speaker, author, and podcaster. He is the founder of Jono Bacon Consulting which provides community strategy/execution, developer workflow, and other services. He also previously served as director of community at GitHub, Canonical, XPRIZE, OpenAdvantage, and consulted and advised a range of organizations.


I'm not necessarily 100% convinced that this is an always-applicable as a something that could be considered a Good Thing(TM). I might consider the following as exceptions:

* Inherently complex applications. In the spirit of Atom (and Emacs, and a variety of other programs), yes, you *could* extend a text editor into being a full IDE. However, if your primary focus is to develop the full IDE (NIHS, blah blah) or a full-featured word processor, then the simple core concept starts to degrade.

* When you develop a highly extensible application, you also create another class of user that you need to support (the extension developer). If you're already struggling to provide regular user documentation, adding that additional tier of user is a non-trivial maintenance cost that needs to be accounted for. It also adds a level of complexity to the code... making it *less* simple.

* I'm going to put on my paranoid hat here a bit, but extensibility also opens the door to commercial hijackery. There are a class of applications that endeavor to provide a user with all of the tools necessary to complete a task (or set of associated tasks). However, when users are forced to be reliant on third-party extensions to get their work done, then the original application is failing at its mission (especially if those extensions end up being closed-source). There are times when you need to decide if you're writing a user application or if you're writing a library/framework. You can't always do both.

* But even if everything stays open, there's userland complexity brought on by this extensibility. You have support questions that start off with, "Why can't I do _____?" and the answer ends up being, "You could if you use these extensions." And, invariably, the follow-up is, "How in the world was I ever supposed to know that?" Extensibility doesn't work without some kind of discoverability engine. A packaging system helps, but that's another layer of complexity (plus this may introduce concepts that compete with the native packaging system of the operating system or distribution in use).

OK... so I wrote a lot in this response (more than the formatting probably supports comfortably), but for me I suppose you could boil this down to, "No. It's not *always* better." It *can* be better if you build your project around that concept and get all of your scaffolding in place to support it... but I'd be wary of (for example) recommending that the majority of existing projects start shifting in that direction.

Jono, this is a great article. I particularly like the reminder - for us older folk anyway - of the basic design principle inherent in a lot of the original Unix utilities: this_command -xyz | that_command -abc | the other command -pqr and we could all do pretty much anything we wanted.

What, IMHO, enabled this interoperability (besides great books by Kernighan, Pike, etc) was the glue provided by standard input / standard output and pipes. Ie, essentially capabilities exposed by the shell.

Maybe this is what's missing or challenging in the context you point out; we don't have the equivalent of a "shell" that exposes Really Useful Hooks on which plugins can be hung. In general, anyway. And so maybe the Gnome Shell does this; I haven't played with it enough to know.

And clearly reading Jason Van G's post, one of the things we are missing is a coherent and spirited guide to this stuff à la Kernighan, Pike et al.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.