Role of addons

Kent James kent at caspia.com
Tue Sep 18 16:19:50 UTC 2012


On 9/18/2012 6:23 AM, Mark Banner wrote:
> Generally, I'm not yet convinced moving items to add-ons that are 
> shipped with the core product, will actually benefit us - the 
> maintenance of those add-ons would be approximately the same, or even 
> slightly more. From the user interface perspective, we'd have the same 
> UI with the add-on enabled and we'd need to do some kind of dance for 
> having the add-on enabled for existing users, and some sort of UI to 
> enable it for new users if they wish to (including explaining the 
> feature).
The benefit does not come "with the add-on enabled" but with the addon 
disabled.

The main point of this is not to start a round of featurectomies moving 
things to addons, but rather to upgrade the role of addons in the 
application so that we could have a class of addons that is considered 
part of the "core product", but does not add to the complexity of the 
standard user interface. Right now, addons are second class citizens, so 
we cannot really leverage the power of addons as well as we could. Can 
we have addons that are not considered second class citizens? Addons are 
one of the most powerful advantages that our platform has, and I want to 
be able to increase their value to our users.

A recent example was a tweet from David Humphrey "I want to continue 
loving Thunderbird, but I have zero interest in debugging my Google 
Calendar integration broke by this update. Zero."

Some would argue that the answer to that class of problem is to 
integrate Calendar and Google Calendar Provider into the core code. I am 
arguing that we need a class of addons that has features that we 
consider critical, that watch as part of release, and that have 
increased visibility. Only then would we consider featurectomies.

:rkent



More information about the tb-planning mailing list