Gordon Weakliem responds to my post about power users by suggesting that developers make their applications extensible. That way power users can build their own features, sidestepping the need to complicate your software by adding those features yourself.
It’s an excellent point, and there are certainly a number of applications that have greatly benefited from their extensibility (Microsoft Office and Mozilla, for example). Plus, making your program extensible is one of the best things you can do to help build a community around your software.
But if you plan to make your software extensible, be aware of the costs of turning power users into developers:
- Feature requests from power users won’t slow down after you make your software extensible (if anything, they’ll increase).
- Unless your support team has programming skills, it will be up to you (or other developers on your team) to support power users who are extending your software.
- Making your software extensible may complicate future versions by requiring them to be backwards-compatible.
Not long after I created the first version of HomeSite, I started receiving requests to make it extensible so that third-party developers could hook into it. I eventually exposed HomeSite’s object model through ActiveScripting, enabling customers with programming experience to roll their own features. This was enormously popular with power users, and the benefits trickled down to new users since they could download third-party add-ons that provided additional functionality. It also resulted in a very active community of “HomeSite extenders” who shared and discussed their work with each other.
It was worth the effort, but I would never claim that it made HomeSite simpler to support. Instead of requesting new features every now and then, power users would frequently ask that we make HomeSite even more extensible. At the same time, we also had to help developers who were having problems getting their add-ons working, which often meant educating them about JScript or VBScript. So while I don’t regret making HomeSite extensible, supporting it was a lot more work than I anticipated.
In addition, we had to make sure that new versions of HomeSite continued to support adds-on created for prior versions (for the record, we weren’t always successful). In most cases this was no big deal, but there were situations where changes to our object model required some “creative” coding to ensure that old add-ons would work. This was further complicated by the fact that third-party developers found all sorts of ways to hack around limitations in our object model to get their adds-ons to do things we hadn’t anticipated (truth be told, though, much of this could’ve been avoided had I spent more time designing HomeSite’s extensibility features in the first place, but when you work for an Internet start-up, time isn’t usually something you have in great quantities).
Don’t get me wrong – I’m not suggesting that you avoid extending your software. But I am suggesting that you really think about the implications before you do it. Unlike some of the features you’ll add to your application, extensibility is something that really requires thinking beyond the current version, and failing to get it right could easily complicate your software rather than simplify it.