The Importance of Plug-Ins and Configurable Architectures
We have added additional plug-in functionality into the Pentaho BI platform in the latest version (V3.0). The platform has always been very customizable (you could always replace every component, engine, and sub-system through configuration) but now it is even easier to add new features into the platform. I really like the results, we have already added several new features to the platform (like the community dashboard framework) with very little effort. I think the combination of plug-ins and a configurable architecture enable several things:
- `Yes you can`
- Cleaner design
- Cleaner code
- Reduced risk of forking in open source software
`Yes You Can`
The combination of plug-ins (to add new feature/function) and a configurable architecture (to enable the architecture itself to be modified) provides you with a `yes you can` answer to almost any question. No matter what your users or customers want to do they always have the ability to create a plug-in that meets their needs or modify a piece of the architecture to solve their problem. This design makes it very easy to make the modifications desired with the smallest possible change: you can extend an existing component or layer by sub-classing it and changing the one function you need to, then telling the system to use your version of the component.
Creating a plug-in architecture mean, as a matter of necessity, you have to have clean interfaces and well-defined boundaries between the various sub-systems and objects. These things are clearly good to have. You can of course have these things without a plug-in architecture but having a plug-in architecture forces you to have them.
I have worked for proprietary software companies where the code was littered with flags and special cases that were put there to support a single customer’s special use case. This was necessary because the software was not sufficiently extensible to allow the custom behavior to be easy added as a plug-in.
For open source projects benefit of this kind of extensibility is that it can reduce the risk / necessity of a fork. If the software can be customized to the extent that almost anything is possible you reduce the ‘direction’ arguments. In many cases forks occur because a part of the community would like to see the software go in one direction while the core developers want to take the software in another direction. If the software is pluggable at all levels it can be possible for the software to support both modes, keeping everyone happy and reducing the risk of a fork.