Interview with Chris Forsythe of Adium and Growl

Today we feature a very interesting interview with Christopher Forsythe, the developer behind the Growl notification system and project manager of Adium, the multi-protocol chat application for Mac OS X.

1. Why Growl doesn’t ship (and enable) by default support for Mail, Safari, iTunes? To me, as a new Growl user, this is something that I expect it would have been integrated automatically. It didn’t make sense to hunt and enable them individually.

Chris Forsythe: There are a few reasons. Most of them are technically just because we haven’t gotten to it yet. The major problem to address here is that some applications actually ship the entire Growl Preference Pane (the thing to configure and run Growl) with their applications, so we don’t want to cause problems there.

Some of it is that we want users to understand how exactly Growl
works, and separating things at the time seemed to make some sense.

Luckily your hunting shouldn’t take long though. In the Disk Image
that we ship Growl in, there are also 2 folders, Extras and Scripts.
Both of these contain all sorts of things, such as the GrowlMail,
GrowlSafari and GrowlTunes, but also a lot of other things. For
instance, we have a add-on we ship in the Scripts directory for
Salling Clicker, so that you can get Caller ID information for a
BlueTooth cell phone to display in a Growl notification.

Overall, the real problem is just lack of resources, much like any
other project (Open Source or not). We’ll get around to addressing
it, but for now it seems to work alright.

2. Are there plans to allow the customization of the position the Growl alerts are showing in the screen?

Chris Forsythe: Yes. We’ll have this added in 1.1. The major hurdle here is that
we wanted separate display types to be able to work together. For
those who have not used Growl, or cannot because they are not lucky
enough to have a Mac (that’s a joke folks), your notifications/events
can look different per application and per notification type in each
application.

3. Are there plans for a small “Growl Server” for Windows or Linux that can display vital information about these systems on a normal Mac OS X Growl Client (maybe via Rendezvous)?

Chris Forsythe: I haven’t heard of one, and there really isn’t a huge need for it
from what I can tell. We have a great bunch of users who have already
made this a non-issue.

Rui Carmo has made 3 network notification sending “bindings”, 2 in
python and one in php. These should allow anyone who needs to to send
a notification over the network. We’ve gotten permission from him to
ship these with Growl, and we’ll probably be shipping them with .7.5.

Bindings in general make Growl more useful to a lot of people. Not
everyone likes Cocoa or Carbon, and no shoe fits every foot so to
speak, so we’ve always accepted Bindings for any language so long as
it works. For 1.1 it looks like we’ll have Java, Applescript, Perl,
PHP, Python, RealBasic, Ruby, Tcl, and the networking bindings
mentioned earlier. All in all this should make it easy to talk to
Growl via the network from other platforms, and other languages as well.

Neither of those platforms support Rendezvous/Bonjour, so if we ever
did implement a Growl Server for those platforms (I really doubt
windows support at the very least, Linux is more likely) then we’d
have to take that into consideration.

We’ve also been promised support from Guifications at some point.

4. Some users online said that they would expect better defaults on Adium. The Adium preferences are so many that creates a bitter feeling to users who have to delve in to make it look better or to make it take less space. Any plans on this issue?

Chris Forsythe: With 1.0 we’re starting to work on this somewhat. The major issue
here is that one of the previous goals for Adium was “So many
features you will crap your pants”. Some folks took that literally.
In any case, that’s no longer a goal or even on our radar.

We now apply to a few things. One real goal we have is to no longer
add a preference if at all possible. Another is to apply the “80/20”
rule to things. For those who are not familiar with this, it’s the
process of deciding if 80% of your userbase would use something, or
20% of your userbase. If it’s 20%, then it’s not really something
that should be considered.

We’ve removed a lot of functionality in 1.0. We’re currently in the
Beta process for Adium 1.0, and only one or two things that changed/
got removed have been brought up.

If anyone has problems finding an actual preference or feature they
need, then by all means they can bring it up on our forums.

Then again, this is Open Source, and if someone works on Adium and
wants something, it’s well within their rights to add it. It may be
removed later, but it will at least be considered for a while.

5. Are there plans for audio and USB/FW video support for AIM, MSN and Y!?

Chris Forsythe: This is a sore spot for us. AIM, MSN and Yahoo are all the “major”
IM protocols in the US, where a decent proportion of the Adium team
is based (just a side note, we have people in other countries too).

The problem is that all of these are proprietary protocols. We have
no access to any documentation. Up until a few years ago, Yahoo would
actively try to disconnect “unofficial” clients claiming that they
were the cause of spam.

I’m not sure how many of our developers have cameras, but if anyone
was wanting to get this implemented donating cameras to their
favorite IM client project might not be a bad first step. Plenty of
people request this, but nobody really asks if the developers even
have the gear.

We do have a project underway by one of our Summer of Code students
to add in Google Talk Voice to Adium. This is possible because Jabber/
XMPP is open, at least in part, and it’s also interesting work. It’s
also possible because Google asked us to be in their Summer of Code
application list, and we got 6 entries. We didn’t have to apply, they
literally asked us, they’ve been good to us, so we thought we’d give
something back on that stance.

So, on to why we don’t have voice/video, and how to get that fixed.
There are four points to this problem, at the very least:

– The first part to all of this is locating a library (or creating
one) that sends and receives the information required. For multiple
protocols this could be multiple libraries, or a single library that
does them all. For those who don’t know what a library is, think of
it as the engine in a car, taking care of a lot of things that most
people don’t know about.

There are a few libraries, but as of right now we don’t have anyone
implementing them in a way that we can use them, with the exception
of our Summer of Code student working on Google Voice support.

– After we get a library, we have to hook it up. This was mentioned a
bit above, but basically this would be like hooking up libgaim to
talk to Adium, or Joscar. It depends on the library for how difficult
it will be, along with the experience of the developer implementing it.

– QuickTime. Simply put, we need something to process the images, and
QuickTime is it. QuickTime is also a pretty big API that none of us
know much about as of yet (except Peter, who does not know IM
protocols, and is therefore not suited to hook QuickTime up to
anything).

– Someone to do all of this. Hooking up a library to talk to Adium,
and then hooking that into QuickTime, and making sure it works with
at least an iSight if not USB/Firewire cameras is a big task. One
that nobody has really stepped up and said they wanted to do as of yet.

6. Are there any VoIP SIP plans for Adium? If not, why not?

Chris Forsythe: We have (at least in the upcoming 1.0, I don’t remember in .89.1)
a SIP/SIMPLE account type.

We’re in talks with multiple Voice Over IP providers with regards to
supporting their stuff in Adium. If you (the person reading this) are
a VOIP provider, please contact us and we’ll work on integration with
your protocol/userbase.

7. Are there plans for a Growl Dashboard widget that stacks the alerts on top instead of having them flashing one by one on the main desktop?

Chris Forsythe: We have a dashboard widget, but we need an artist. It might ship
with 1.1, it might not.

I really don’t want to setup for a dashboard widget to solve this
issue. The proper way would be to have a history system for
notifications, much like Adium logging solves the problem for IM.

8. What are the biggest challenges you had to face as a developer for Adium and Growl?

Chris Forsythe: Users. Growl has about 100 thousand users, and Adium has about 700
thousand (maybe more by now). Making that many users happy is.. tough.

And it’s getting tougher. For instance, with Adium, we have a ticket
system we setup about a year or two ago. And we are about to hit 5000
tickets. We have 2 guys working on just the new tickets.

This isn’t such a bad thing, but it’s just a lot. For instance, the
two most important users to Adium are Evan’s girlfriend (our lead
developer is Evan) and my wife. A lot of things that have been
complaints by my wife or suggestions have made it into 1.0. Guest
accounts in 1.0 are basically because Evan’s girlfriend said it would
be nicer to have them.

And Evan’s girlfriend and my wife are two completely different kinds
of users. Apply that to 100 users, and then 1000 and so forth, and
you should get the idea. The funniest part is that both his
girlfriend and my wife don’t know that they are the most important
users to the project

This is the same for any project. On Growl we actually have two
completely different user bases. Growl users, and Developers using
Growl with their application. For those not familiar with it, any
application that sends a notification to Growl is “Growl Enabled”.
Skype for instance works with Growl, so we automatically gain their
Developers and also their userbase. We can usually tell when a new
application adds Growl support, because some of their users email us
for help with Growl.

So finding a way to balance features that are useful to everyone, and
features that are only useful to that 20% but might apply to the 80%
in a way that you can implement is always a battle albeit it’s a fun
one.

9. What do you think about Mac OS X Leopard so far, based on Monday’s keynote?

Chris Forsythe: I don’t really have an opinion on it, and won’t until I get my
hands on it.

I think it is good to integrate things into the OS that just make
sense. Some Growl users feel that Growl should have been cloned or
copied (Growl is BSD licensed, so Apple could do that).

I think it’ll be a fun year next year.

10. Are you going to provide a full 64bit binary of Growl/Adium when Leopard comes out? Or you prefer to only stick to 32bit universal binary environment as recompiling for 64bit sometimes produces new bugs due to the application’s programming not being specifically developed or tested at 64bit environments?

Chris Forsythe: It shouldn’t be an issue, honestly. Xcode probably has one or two
buttons and we’ll be done with it. And if it’s not really super easy
to build it, it’ll be a challenge for someone and of course they’ll
treat it like a game until it works.

Regarding support, the best way to get support for any sort of
hardware is to donate that kind of hardware/software to the projects.
For instance, there are two products that we have donated site
licenses to, SubEthaEdit and BuildFactory. Before we were donated
licenses for these items, we didn’t really work with them, but
afterwards we really do use them, provide feedback and bug reports,
request features, and tell all sorts of folks about them where we get
a chance.

But if nobody donates a 64 bit machine to the projects, then we have to depend on either a developer purchasing one (unlikely at that price) or relying on users to help us with it. Depending on the user, it can be really helpful feedback or not worth the time expended on it. Either way, it’s not as good as actually having the hardware/software, but it works in some ways.