The Dark Side of Plugin Architectures
I love plugin architectures. Having a well-done method for people to extend your system is a huge, huge benefit that we’ve discussed and lauded in relation to Firefox and Movable Type. But, there’s a dark side. When you update software to a new version, you normally do a regression test, which means…
The document discusses the drawbacks of plugin architectures, particularly when updating software. It highlights the difficulty in testing plugins and extensions that are written elsewhere, leading to potential issues when upgrading. The document also highlights the potential for user frustration and refusal to upgrade due to loss of a beloved extension, and the loss of control over the software developers.
Generated by Azure AI on June 24, 2024I love plugin architectures. Having a well-done method for people to extend your system is a huge, huge benefit that we’ve discussed and lauded in relation to Firefox and Movable Type.
But, there’s a dark side.
When you update software to a new version, you normally do a regression test, which means you go back through all the old functionality to make sure it all still works. If the software has been completely written within your organization, this isn’t a normally problem since you have the whole codebase. But if there are plugins and extensions that are written elsewhere – some that you may not even know exist – how do you test those?
Well, you don’t. What this means is that different things break for different people when you upgrade. Case in point – I ran an automatic update to Firefox this morning, and I lost four extensions that weren’t compatible with the new versions. I hope that sometime in the future, compatible versions come out for those extensions, but until then, I’ve lost some functionality.
What gets worse for software developers is when someone writes a “killer extension” for your system – an extension that everyone uses. You may find yourself in a position of not releasing upgrades until you’re sure they’re compatible with all the killer extensions lest you really irritate your users or they just refuse to upgrade rather than lose their beloved extension.
The same can be said of the relationship between OS and software, I guess. I remember reading that when Windows XP came out, Microsoft had to insert thousands of hacks and special cases for specific software titles (SimCity, for instance), to ensure they didn’t break. If they did break, Windows would take the blame, although in most cases, the problems were because the software developers were doing very unorthodox and unsupported things.
As people write stuff (software, plugins, extensions, etc.) for your platform, you start to lose a little control. Some of this can become critical to people, and your users may look to you to make sure it keeps running after you upgrade.