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?