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.
- "Interview, Page 1/2"
- "Interview, Page 2/2"