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 you go back through all the old funcitonality 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 irrritate 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.
We talked before about the new API extensions, but that pales in comparison to the single great thing about Firefox 1.5. Here it is -- You can now punch the monkey without fear of commitment. Since they improved pop-up blocking, including pop-ups spawned from Flash and Java, you can now play…
David Raynes: SubCategories 1.2: There was much complaining when Movable Type 3.0 came out that there wasn't anything new in it. To a large extent, the complainers were right — there was very little new functionality...on the surface. The real gem of MT3, it turns out, is the new plug-in…
For what it's worth, unless one of the major two numbers change in the version, the extension's probably still compatible. The problem is that the extension has a built in listing of what version of Fx can use it, so you'll have to update that either manually or using Nightly Tester Tools, but I'd be willing to bet that that is all that will be necessary for a minor version change.
It certainly is frustrating. But what to do about it? The system is built upon opensource extension developers who get nothing out of the extension development other than pure joy (ie no monetization) and who, therefore, have no real incentive to update on Mozilla's schedule.
And, did Mozilla warn they were about to upgrade to all of their extension developers?
what to do about it?
provide a rigorous api.
in particular, don't just provide the functionality, but include checks for trying to use functionality you don't want to support. this is almost never done, because there is a lot of overhead both for engineering and testing, but a well designed api will guide extension developers to create code that will survive your upgrades.
