Extending Your Application

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.

Comments

[critter42]

What about the FD newspapers - Do you consider them extensible since you added the fdactions? I've mentioned it before, but you just about have a quasi-API with the fdactions that you have added

Now I know and understand it all might change with each new version cycle, break compatibility, etc, etc and that's why you're reluctant to, but is it possible to get formal documenation of all the fdactions and their arguments?

>In addition, we had to make sure that new versions of HomeSite continued to support adds-on created for prior versions<

I realize that this is a personal goal and is excellent for the customer, but I do want to point out that many customizable applications break compability with previous versions (Winamp skins/plugins and Firefox extensions are just a couple major ones off the top of my head) and have very little complaint from the userbase; most communities that offer application-specific, user-created content (like skins, plugins, extensions, themes, etc) indicate what version(s) of that application a given piece of content is compatible with, and there haven't been any issues. Again I understand that this is a personal goal to maintain version compatiblity, I'm just pointing out that there are many successful examples of applications that don't

Thinking about this, I guess you could also put my earlier question down as something else for programmers to think about before extending their application - they in all likelihood will need to sit down and thoroughly document the API in such a way to make said API easy for others to pick up and run with

[Nick Bradbury]

Critter, you're right about FeedDemon's newspapers being a quasi-API, and you're also right about why I haven't documented them. I *know* that they'll change, so explaining their innards would likely result in unhappy third-party newspaper devevelopers. For example, the security lockdown added in v2.1 would've broken any third-party newspaper style that relied on JavaScript (ie: pretty much all of them!). So until I'm confident that they won't dramatically change, I won't document their format.

IMO, applications that consistently break compatibility between versions are a PITA for end users. I *hate* how a simple Firefox upgrade often requires getting new versions of the extensions I use.

[Jeff Wilkinson]

"It's an excellent point, and there are certainly a number of applications that have greatly benefited from their extensibility" ... Especially HomeSite... and its users!

... and we still thank you and the other HS developers every time we use it... that extensibility has let users do a ton of things they'd never be able to do in most editors, and it's kept HS useful even now in spite of a few years of slow development over there.

So, sorry if it was a pain sometimes for you all to support, but we *really* appreciate that effort.

believe me, as the guy trying to keep most of the homesite extensions listed on my site, I definitely know how much it helps. ;-)