The Plugin Problem

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

For some time now (e.g., here), I’ve been advising purveyors of platform technologies to steal a page from the Eclipse and Firefox playbook, as those projects have experienced a bit of success along the way. Embracing this role can be painful for vendors and developers alike, implying as it does a deemphasized, more manageable role for the platform while deferring at least a portion of the limelight to its supporting actors: third party extensions/plugins/add-ons.

Counter-intuitive as the notion that software products should limit their ambitions might be, the point is difficult to assail from a historical perspective. The most successful software product in history, Windows, was built in just such a fashion (though it’s gotten away from those roots in recent years).

But it’s also important to emphasize that the benefits afforded by this approach do not come without a cost (though what does, in this life?). The price, in this case, being potential reliability issues. Consider the case of my Firefox 2.0 woes, which may or may not have been due to the Google Toolbar. Or the fact that subsequent to the installation of the Eclipse PyDev client, my Eclipse PHP IDE extension broke completely and utterly. Or the fact it was not damage that I inflicted upon my WordPress theme that forced it to display the same comments on every page – as originally suspected, but a plugin conflict. And so on.

The point here is not to retroactively indict the recommended approach; I remain as firm a believer as ever that the plugin strategy is the soundest for guaranteeing long term success for would-be platforms. But it’s also important for the platform provider to recognize the limitations of this strategy and design accordingly. Can you, for example, help users isolate and and deactivate misbehaving plugins? Or better yet, not permit the misbehavior in the first place?

In some cases, the answer is an easy yes. In others it requires a fundamental refresh of the architecture, framework and otherwise. In all cases, in my opinion, the investment is worth it. Sooner or later a popular platform will run into this problem, so you might as well fix it sooner rather than later.


  1. Perhaps the main innovation in Eclipse was to implement an architecture based on the notion of plugins, and to provide a way to manage the plugins. For example, a single Eclipse application can support the use of multiple versions of the same package. The licensing was also innovative in that it required that the core framework remain open-source while explicitly allowing the creation of proprietary plugins that can be licensed under a commercial license.

    Eclipse is IBM’s most succesful innovation in the open-source space to date. There is now a quite large ecosystem around it.

    Eclipse has also helped spur academic research in that it provides “flash on the glass,” allowing researchers to focus on their core innovation without having to spend most of their time developing an infrastructure just so they can run their new application.

  2. IBM’s Unstructured Information Management Architecture (UIMA), like Eclipse, uses the plugin model.

    UIMA is now an “incubator” project at Apache:


  3. […] of plugins, I’ve written before of the catch to the approach: namely that misbehaving extensions can confer an unwanted reputation […]

  4. […] is a victim of its own success. The plugins make Firefox successful, but they also introduce potential instability for users and they can hinder development (the transition to 3.0, for example, negatively impacted […]

Leave a Reply

Your email address will not be published. Required fields are marked *