Friday, February 22, 2013

The Plugin Ecosystem

The idea of monolithic software is a rarity for most folks. Even an operating system, which is itself a big monolithic beast as far as most users and developers are concerned, has it's own plugin ecosystem. The operating system does a lot of work, but the vast majority of that work is in support of plugins, or applications, that run on top of it. Like it or not, its these plugins that make the software on which they run useful. They support the idea of an ecosystem, new plugins evolving from old ones, old and stable plugins becoming dependencies of other plugins — once the plugin development community forms, it seems there is no stopping it. The ecosystem that plugin development sets forth opens up the door to an interesting development culture, one that seems to have a strong experimental, and thus, strong educational feel to it.

To have a diverse plugin ecosystem is obviously a great goal to have when setting out to build a new software application. The alternative is to maintain a giant codebase, all the work done under one umbrella. Wouldn't it be just super if we could establish some entry points for plugin development in the core application? It would be great, but this is never easy to do, and the chief cause is cost of initial design. You're probably not developing an application with the purpose of creating a plugin ecosystem. No, you're creating an application that solves a particular problem. And that problem comes before, in terms of priority, designing a sustainable plugin architecture. The plugins, and the ecosystem they create, are merely a desirable side-effect of a successful application, one that really takes to heart the idea of extensibility.

But perhaps the plugin idea, and the rewards it brings, really are underestimated in terms of value. Think about the diversity of an ecosystem. Differences in priority, in functional requirements, in time available to solve a particular problem, these all yield a large spectrum of plugins. Plugins that are, in turn, discovered by other plugin developers. They spur further development of the system.

Ideally, a plugin can be designed and implemented quickly. This is a confidence booster for any kind of developer new to an application. You're building your own little application inside a larger pool. Just like when you design a Python application, you're extending the capabilities of the operating system rather than modifying the OS itself. We need this kind of quick, getting up-to-speed development scaffolding. Its how many developers can contribute to a single project without fear of disrupting others. You learn quickly, and you can either keep developing the plugin, or tear it down. Small core, lot's of plugins. This is a sustainable way to scale up both the feature set and the development effort.