Plug-ins: isn’t there a better way?

If there’s one thing that bothers me about using a ready-made solution like wordpress for my blog, it’s plug-ins. I hate software plug-ins. The first question every support engineer for any software product that supports plugins asks in response to a trouble report is “are you using any plugins?” And when you say “yep, I’m using plugins!” the reply from support is to disable them immediately and see if the trouble goes away. That’s a problem.

What’s worse, if the plugins are maintained by a third party (often the case), there’s no telling whether or not they’ll exist when the next version of the base software is released, or whether they’ll be supported in future versions of the software.

Two examples that touch my daily life are Firefox, and WordPress.

Lately (since around March) I’ve been having lots of trouble with Firefox. I thought upgrading to Firefox 3 would’ve helped, but it really didn’t. Running it on OS X, Firefox hangs frequently enough that I’m actually considering using Safari (I do NOT like Safari). Know what happened right around that time? Ah – I found the firefox plugins for managing EC2 and S3. So today I’ll uninstall those and see if it helps.

With WordPress, there are two things I’m missing: I need to let readers subscribe to comments via email, and I need better Google AdSense for Search integration with WordPress. Both things are kinda maybe supported in one version or another “but should work under…” – whatever. I don’t really want to spend my time downloading, reading the documentation to do the install, doing the install and configuration, etc., and then finding out that it doesn’t work, or worse, having it look on the surface like it works, but then finding later that it fails in evil-but-silent ways.

These two products are by no means exceptions. Moodle, PHP-Nuke, XOOPS, MediaWiki, Twiki, Postnuke… and for that matter, OpenLDAP, BIND, SSH, MySQL, Sendmail, PAM… all have plugins available written by other folks, and all have bitten me at one point or another. Usually when it comes time to upgrade the base software.

I’m not saying anything new here. People have had this problem with lots of different software products for a long time. My question is “why is this still a problem?” I’m not asking this because I have some magical obvious solution or answer, I’m asking because I feel like there’s probably more to it than I’m grasping. I’m not a masterful developer, or even a masterful software project manager, so I’m calling on all of you who are (or are closer than I am) to help me understand the problem. Some day, I might find myself in a position to take the wrong or right path where plug-ins are concerned, and I’d like to be more informed than I am so I can avoid putting users in the position I find myself in when I use other peoples’ software. Has Joel blogged this yet? If so, I can’t find it. Links please?

  • Eric Day

    Conceptually plug-ins are a great idea. Everyone can develop their independent modules using a well defined API from a core project and things will just work. The problem is that the API’s are not always well defined, and when they are, they can change between every version of the core software component. The core project development will usually require some new functionality for new modules, so the API will have new calls. The old calls could also have new arguments or, in the worst case, the old API calls will have a different behavior that breaks the modules. In the end, all modules end up being at the mercy of core project development choices.

    One solution to help is versioning of the API interfaces. You can see attempts at this in some projects but they usually have strict single-versioning so modules fail to load due to version mismatches. A better way to deal with this is for new releases of the core project to support multi-versioning of the APIs. This way old modules will work as intended with same old API, even though a new version of the API may be available. The module developers can then get around to upgrading their software to use the new API at their leisure without worrying that their old version will break immediately.

    This creates more work for the core project developers, especially when core changes break behavior expected by the older APIs. A developer may have to write a significant amount of extra code just to convert data or emulate the old behavior. In some cases it may not be possible and you end up with broken modules. Despite these drawbacks, multi-version API support has been the most effective method I’ve found.

    In the end it comes down to finding a flexible API design from the start of the project. This means trying to plan ahead so you can avoid having to modularize some specific code at a later time (usually resulting in an awkward or non-intuitive API). This is closely tied to efficient modular design of the project in general, and this can take years of programming experience to really master (one of the differences between a “hacker” and “software engineer”). Following object-oriented design principles certainly helps (even when not using a class-structured language), but you can still create some nasty spaghetti code!

    Developers out there intending to create a plug-in or module interface should take some time to study modular design principles before getting too far. 🙂

  • André Roberge

    Perhaps I’m looking at this question too simplistically…

    1. Plugins are an easy way to extend an application – they do not require the plugin writer to have a detailed knowledge of the core.
    1b. As a consequence, it encourages more people to contribute to the development, increasing the functionality of the application.

    2. Plugins will often extend an application in ways not foreseen originally. Plugin writers will often run into limitations of the plugin API, thereby encouraging the core developers to modify the API in later versions.

    Thus a plugin based architecture encourages and facilitates the evolution of an application, making it more useful to more people – but “breaking” more frequently, since it evolves more quickly.

    As a specific example, I know that when we switched the design of Crunchy to allow extensions via plugins, it made the code more modular and much easier to extend. But, then again, the API is unsually simple due to the nature of the application. And, we have not had to deal with plugins written by 3rd parties yet…

  • Doug Napoleone

    One group that seems to have figured plugins out is Adobe.
    Specifically PhotoShop. The plugins for that application are simply amazing, and I have yet to see one cause a problem. The Adobe application framework is based 100% around their plugin architecture. I wish I knew how they did it.

  • Alec thomas

    The Trac project has experienced similar problems with their plugin base ( Nearly every release causes some plugins to break and the mailing list is full of users asking “does plugin X work with Trac version Y”. It’s frustrating for the users and we (the Trac developers) have considered several solutions (among them the API versioning mentioned by Eric Day). We haven’t settled on one solution yet, or even if it’s a problem that even needs to be solved in the Trac plugin system.

  • Noah Kantrowitz

    Trac has been having some major growing pains due to this as well. We have reached a tipping point where there are enough bad or unmaintained plugins, and the install process is annoying enough, that people simply can’t be bothered to deal with them anymore. Ideas we are working with to ease this are creating a big user rating system to allow people to clearly see if a plugin is broken and building an in-app system to browse/search/install plugins. Still working on the API versioning. As a project we work pretty hard to enforce at least 1 major version where the API is deprecated before removing it, but minor changes are still tricky. There is also a problem when you get 20 plugins that all do roughly the same thing (see also: CPAN). GitHub’s idea of trivializing personal branches is one idea, but not very non-dev friendly.

    I still insist quite thoroughly that plugin-based software is the only way to develop complex tools without them turning into giant, monolithic globs of insanity. Maintenance requirements of a codebase increase in a very non-linear fashion relative to the size, so having multiple loosely connected projects allows everyone to stay focused and use their time well. Also allow for disconnected release cycles means new plugins can get bootstrapped much faster. If people have some ideas to make all this less insane I would certainly love to hear them too!

  • kl

    For browsing, try Opera. It has plenty of plug-in-like functionality built-in (from adblock to mouse gestures), but all is well integrated and officially supported. No S3 uploads though 🙂

  • Krys Wilken

    While I certainly understand where you are coming from, isn’t the simple answer to *not* upgrade the core application until all the plugins you depend on have also been upgraded?

    That means not getting the latest adn greatest as fast as we might like, but does mean that once the plugins are all ready, the upgrade should go more smoothly.

    That said, I upgraded to Firefox 3 almost immediatly and not all the plugins are available for it. It’s bugging me too. Maybe I should have followed my own advice.

    Anyway, I hope this helps the discussion. If there is a better way, I’m all for it.

  • m0j0

    @Krys — sometimes foregoing an upgrade means more than just doing without wanted features. Sometimes there are security releases that are essential. What then? Well, you wind up choosing to do without the plug-in functionality that breaks when you apply the security fix. This doesn’t even touch on what happens when there’s a flaw in the plug-in itself and it’s been left to rot by the original developer(s).

  • nis

    No easy way around this one. This is what “enterprise software engineering” is all about. Fight until version 1 of product A talks to version 2 of product B and then don’t touch it again. One of the reasons Python comes with “batteries included” is to avoid precisely this problem. The debian project and its repository which keeps groups of compatible packages together are the once that handle it the best in my opinion. Hundreds of packages in stable just work after a simple installation most of the time.

  • sunny beach

    > And when you say “yep, I’m using plugins!” the reply from support is to disable them immediately and see if the trouble goes away. That’s a problem. No, that’s a huge feature. The ability to immediately narrow down the issue you’re having is a good thing. Without plugins, you would either not have the functionality you want, or it would be baked in. Since plugins are opt-in, having them even if they are faulty is strictly superior to not having the functionality you want. And it’s not reasonable to think everything you want can be baked in, unless you want to get the overhead of all the plugins everyone else wants baked in. If all of the plugins were baked in, then when you called support with an issue they would STILL have you open your settings and disable the features you are using to narrow down the problem, but you would also have to open your settings and disable the hundreds of features you are NOT using.

  • David Avraamides

    I think the problems you are talking about are more about the implementation of the plug-in feature in FF and WP. The plug-in concept, as others have pointed out, is pretty good: develop a clean, solid core of a system with the important functionality, and then add an API to extend that functionality.

    Think of the alternative like Word or Excel. These are apps that simply add more “core” functionality with each new release such that the applications are large, complex and confusing to learn and use. If more of those feature sets were released as optional plug-ins, then users could disable the things that they don’t use, resulting in a lighter app with a simpler menu structure.

  • Marc Laporte


    I feel your pain. A better way? I think so, and it’s called TikiWiki CMS/Groupware.

    People need/want features. Either you let everyone add them in the core or you have an API and hundreds/thousands of external modules/extensions/plugins. The problems are well explained above (dependency hell, code/feature duplication, etc.).

    TikiWiki has an all-in-one approach to features. Think of it as a suite of applications like Open Office. Tiki has more built-in features than any other Web app (if you know of one, please let me know). The features are built-in and all optional instead of offered via 3rd party modules/extensions/plugins, and getting write access to the code is very easy. Some people are concerned about all the features and that “it can’t work” or “it’s not the way to do it”. Since Tiki has a different model than the “conventional wisdom”, I feel it’s important to explain how it works and why it works. I like to think of it as applying the Wiki Way to Software development. About explaining if it works, well the proof is there!

    Not to say that the all-in-core model is perfect. While it solves many issues, it brings another set of problems. One of which is having an admin panel with several hundred settings. But for us, it’s a lesser evil. And we develop strategies to address these.

    Interestingly, even if the application is huge (over a million lines of code), it feels pretty nimble because it’s a single code base and we don’t have to worry about potential consequences to 3rd party code. If we need to re-factor, we just go ahead.

    Please read more here:

    Best regards,

    M 😉