Evan Schoenberg of AdiumX

Another special treat for my 12 loyal readers: Evan Schoenberg, co-lead developer on AdiumX was gracious enough to sit down for another lengthy chat about a whole range of topics.

As a quick primer, AdiumX is a multi-protocol, multi-user instant messaging client for OSX. But wait, you say you already have iChat for instant messaging, so why should you care?

iChat is fine, but what if you want to use more than AIM? AdiumX allows you to access all the networks at once from within one application. If you have more than one AIM name, you're screwed in iChat, but AdiumX allows you to have them online at the same time. If your iBooks' tiny screen is overwhelmed with 10 chats, AdiumX has tabbed windows (draggable!) and a compact contact list and much, much more.

If you've never heard of it, it's really worth checking out. If you've tried an earlier version, chances are you'll be surprised with how far its progressed. It's most assuredly been slapped with the coveted DrunkenBlog Seal of Approval™, so I hope you enjoy the chat and send these guys some love for their hard work.

What's your coding background, and what led to your involvement with AdiumX?

Before I moved to Alabama in third grade, I visited the class I'd be joining. It happened to be the one day per week they went to the Apple ][ computer lab to get the vital, character-building experience of dying of typhoid fever and shooting tons of innocent 16-pixel bears for food. I saw my opportunity and quietly taught those around me how to hit command+power, drop to the Apple BASIC prompt, and write simple code. This one girl did:

10 PRINT "Evan is Nice"
20 GOTO 10

...it took me many years to shake her crush. All women love a good geek, and those who tell you otherwise are lying. BASIC to QBASIC to C++ and a dash of Java... to Objective C. Back in 2002, Adam Iser had finished up what he wanted to do with Adium 1.6, which was his GPL'd, one-man-team baby, and started privately creating the sourceforge project which would later become Adium X.

I was involved in the Adium forums at the time and ended up organizing the "Adium Community Builds," writing patches along with a couple other active programming-minded users for all sorts of silly (and useful) things and distributing compiled binaries. I was an awful, awful programmer, but threw time at figuring out problems until they just gave up and worked. :)

I joined the Adium 2.0 team as soon as Adam opened it up for other developers... slowly became both very involved in the project and increasingly proficient with Objective-C. Eventually Adam invited me to join him as lead developer, which has been awesome.

I'd doubt you were the only romance sparked by the Apple ][ and Oregon Trail. Have you been an Apple user since, or did you wander before coming back into the fold?

I wandered, with a good friend/cousin calling to me from the holy land the whole time. An 8086 (under 3 mhz, with a huge 10 MB hard drive) to a 386, a 486 (my first CD-ROM and a Sound Blaster; wow Sid Meir's Civilization never sounded better), $3200 of Bar Mitzvah money on a Pentium 166 which rocked my world, on up to a K6-2/450... and that's when it happened.

My cousin finally convinced me to pick up a B&W G3 for my next computer... and I came to realize what I'd been missing.

What's your current mac hardware?

Powerbook G4/867, 768 MB RAM, and an iPod named GhettoBlaster. The last Mac I bought, wasn't this one, however; it was a Rev.A TiBook G4/500. It had a series of problems over the course of my Applecare, getting sent in six different times, and Apple was awesome enough to replace it about 7 months ago with this shiny machine I use today.

I so feel your pain. How many people are currently involved with the project?

Well, there are 12 active developers and a handful of other code contributors. We also have a really active IRC channel and forum community with about 15 solid regulars who field questions on a seemingly hourly basis as well as tons of posting users. I'm thrilled with the response we've gotten so far.

Adium was originally a one-man show under Adam Iser, and going from one to 12 could lay the groundwork for a hell of a mess on the back-end. Have their been growing pains in bringing everyone together?

There have at times, at that. Several of our developers have strong backgrounds in languages besides Objective-C but originally had little Cocoa experience, so it's been a learning experience for all involved in that respect; we've made a conscious effort to encourage and help those who are willing to spend their time working on Adium.

In the end, a wide variety of backgrounds is a huge strength worth cultivating. For example, we now have a lex scanner which handles URL validation in messages in a manner far superior to what could feasibly be achieved using NSScanner.

For the most part, though, partly by being selective of who was invited to join the team and partly through sheer dumb luck, we've ended up with a really friendly, mutually supportive group who are awesome to work with.

There are currently three separate chat multi-service chat clients for OSX: AdiumX, Fire and Proteus. What, to you, separates AdiumX from the others?

A lot? :) Adium X aims to be both incredibly intuitive – the "Can my mother use this?" test – and extremely customizable without sacrificing usability. I believe that we are closer to fulfilling both these goals than either Fire or Proteus, and our coding architecture means that we still have a huge potential for growth.

That same architecture helps us be as CPU-efficient and memory-efficient as possible; Adium X idles at 0% CPU usage, for example, which is incredibly important for an app which you hopefully will want to keep open whenever you're in near the computer. We also have a strong commitment to taking care of details; "OCD" is the most common acronym bandied about in commit logs, with good cause. We update very frequently, give users a near-immediate response to bugs, requests, and feedback, and concern ourselves with every aspect of the user experience, from the major to the minor.

Another big plus is our strong community which helps us polish up the program and contributes tons of customization packs, which we call Adium Xtras, letting us offer an even more personal experience to the end-user.

AdiumX and Fire are GPL, while Proteus is shareware. Since AdiumX and Fire are both OSS, is there any cross-pollination that is occurring between the code bases?

Draggable tabs allow you to reorder tabs within a window, or move them to their own window, or to another window altogether.

Fire, like Colloquy, has recently added and implemented our custom dragging tabs which are a huge selling point of Adium for many people. Otherwise, there's little direct code sharing between our two programs, but that doesn't mean we don't help one another.

For example, Fire's handling of an annoying Cocoa bug in which, under high-system-load situations, characters are grouped and then sent to the program but keypresses are sent individually, taught me how to improve the way we were dealing with the problem.

Fire and Adium can provide an interesting synergy because Fire has a significantly more mature codebase; this means, on the one hand, that Adium offers fresh, new, potentially more efficient solutions to problems of program design and implementation, and, on the other hand, that Fire has years of experience and tweaking under its belt so sometimes has arrived at the best of many differ possibilities.

There's a popular meme floating around the OSS world, which would hold that OSS projects often end up wasting a ton of resources through duplication of effort. The idea is that if all your effort had gone into improving Fire instead of Adium X (or vice-versa) it'd be farther along than either project is now, and that this duplication of effort is one of the ways that open source projects often shoot themselves in the foot. Does this meme hold any water for you?

Ehh. I guess a little; there are certainly times where it's clear that both projects have invested time in solving the same problem. It's just not sufficient to me to say, "Well, Fire is an IM client. Adium is an IM client. Why not just have one IM client?" I don't think the-program-that-could-have-been-Adium would be nearly where it is today were the effort invested in it instead invested in an existing project with its own sizable momentum.

I have no desire to disparage Fire publicly or privately; I'm (and we're) friendly with its development team, and they fulfill their goals well. It's just that those goals aren't the same ones Adium has per sé, and changing the course of development through small nudges just wouldn't get Fire to where we want Adium to be.

Sometimes, to do something the way you think it should be done (and, I'd like to think, the way it truly should be done), you have to do it from the ground up. This doesn't mean you have to abandon what's been learned from other projects; it'd definitely be a huge waste of resources if there were no communication between projects facing similar hurdles.

AdiumX is garnering a reputation for being very, very polished. The recently-added double-click install of message styles and dock icons come to mind. Is this something that was identified to be a focus early on?

Early on, Adium 2.0 (which is what we originally called Adium X) was intended to be much like Adium 1.6, but with a cleaner codebase and greater expandability from a programming perspective. In that sense, there was absolutely no focus on true polish; the idea was, and I quote quite seriously, "So customizable you'll crap your pants".

Adium was to be more the hackers' instant messenger, chock-full of preferences and hidden little tricks for making the program work 100% to a crazy geek's liking, and Adium 2.0 was the continuation of that goal.

Adium X grew out of Adium 2.0 with an entirely different set of goals... a goal of keeping the feel-good customizability without the scary, rough-around-the-edges ambiance. So, in a sense, yes, absolutely – from the inception of Adium X, polish was precisely our focus.

Examples of AdiumX current preferences

Was there a certain point in Adiums' development (such as a user crying) where you realized you really had a problem and had to start either pulling back on features or actively working on better paradigms of presenting them? Or was it more of a gradual realization?

There was a span of time where we (sorta one of those group mind things – I think Adam started it, but I'm not even sure) began just pulling useless or asinine preferences out of the program and replacing them with markers calling for a rational default to actually solve the problem instead of masking it with a user-specified value.

I believe "*yoink*" was the CVS commit message of the week. Come to think of it, all that activity must have been in response to something... but no event springs to mind. So it must have been gradual :)

We just had this then-ever-increasing mound of advanced preferences and hidden features... and it was getting both unmanageable and confusing even to us. Discussion led to a ToDo list in CVS with a clear goal of streamlining the whole affair as a starting point for continued development.

With the rewrite of AdiumX, you've spent enormous amounts of time moving to a new plugin architecture. Terms like a "plugin architecture" have a tendency to sound like generic buzzwords unless you're a developer. Could you break down why this was important, and how AdiumX benefits from it?

We definitely got talk, particularly from non-developers, about how we had a plugin architecture and that therefore we should have a plugin for everything – you know, a plugin to control your lights through Adium commands via an X10 module, that sort of thing. "Bloat! Useless bloat!" we would respond. "But it's just a plugin! You can disable it if you don't want it!" they cried.

The plugin architecture is incredibly important to both Adium's efficiency and its maintainability. The idea is not to have swappable modules, though that is a nice side effect as seen by the availability of an external SQL Logging plugin module; in fact, 90% of our "plugins" are compiled directly into the Adium binary and are not visible to anyone who isn't in XCode.

The idea is to have a clear and nearly-absolute delineation of coding responsibility between classes. Central controllers – a preferenceController, a dockController, a menuController, and so on – are the only bridges plugin classes have to one another and to the Adium core. Plugins themselves have specific goals and, by convention, work only towards those goals in as abstract a manner as possible. This means that if a problem occurs, or something seems to be performing inefficiently, we can usually tell without a moment's hesitation precisely which class is responsible and then isolate it.

Also, abstract plugin-based coding makes it much easier to handle future changes. When we decided to move to the WebKit-based message view, we didn't touch message window code, or menu code, or preferences code; we disabled the "Standard Message View" controller plugin, wrote a new message view controller plugin which worked via WebKit, and were done. (Of course, that second step isn't a simple matter... but in troubleshooting it we could be certain that any problems were solely contained within the new message view controller, since no other changes had to be made).

One of the other big changes that occurred during the rewrite was moving the core of AdiumX to LibGaim. This is a little beyond wrapping a command line utility with a GUI. Was this harder than it looked?

An emphatic yes. LibGaim had never been used on this scale before; we wrote the Cocoa <--> LibGaim bridge which is now also being used by another OS X client.

The Gaim team, particularly Christian Hammond and Mark Doliner, have been incredibly helpful in the implementation of LibGaim, which it should be noted doesn't officially exist. It's an ongoing project of Christian's to split the core and UI of Gaim into LibGaim and GTKGaim, and as such isn't a finished product by any means. We've helped in LibGaim and Gaim development in the course of our implementation, which always feels good.

Even with their help, there were huge hurdles in initially getting Gaim and all its dependencies compiled into a form that they could be packaged with an application (spend an hour or three compiling and installing and balancing Gaim and all its dependencies on OS X, particularly while maintaining compatibility with OS X 10.2, and you'll know where we had to start.)

Once that was done, there was the problem of working in an Objective-C environment with C code originally designed to be used with GTK+. It has been an endless series of challenges. As a random example, GTK+ doesn't block the UI while code is working, so we had to figure out how to run the entire LibGaim codebase in a separate thread so as to avoid the Spinning Beachball of Doom. Well worth it though; great protocol code, and it's like Hanukkah every time Gaim releases a new version and we get all those "free" improvements to our protocol core.

Woa there cowboy, can you elaborate on why you say its never been done on this scale before? Weren't other chat clients using LibGaim before this?

Well, I guess you could mean gpe-gaim, ChipX86's pet project for which he originally began working on LibGaim. It's a reimplementation of what is more-or-less the Gaim GTK UI running on the Zaurus and other PDAs running Qtopia.

Very important in that Chip enjoyed (enjoys) working with it and it led to LibGaim. Not a huge target audience, though. :) So technically we're the second client to use LibGaim – but the first to use it on this scale. By "this scale", I mean that we are targeting a much larger audience, making libgaim completely transparent to the end user via both packaging and interface, and implementing the fledgling library with a UI completely alien to the one for which it was originally intended.

The app seems to be hitting a bit of a stride, but you've just come out of a massive, massive rewrite. Have you learned any lessons from this you think could help others in the same situation? And, knowing what you know at the end of the tunnel, are there any decisions that were made that you wish you had done differently?

It's been hard sometimes to maintain focus on our goals with an established userbase already trained to use the old program in a certain way. There've been near flamewars on the Adium forums at times as we took out Joe Luser's favorite feature in favor of a much better idea or in preparation to rework the idea from scratch.

My best advice to anyone in our situation – not, I suppose, a common one – would be to do your best to listen to your users, who will often provide invaluable advice and feedback, but to also remember that you, not they, are ultimately spending your valuable time on this project, so you should fulfill the vision you have in mind above all else.

Much of your work is in the interesting position of being 95% dependent upon the network of others who often give the impression of 'grudgingly tolerating' 3rd party access. Of course I'm asking this on the day Yahoo has again made changes to their protocol that broke 3rd party clients. Does this keep you up at night?

Not even for a second. The day you're talking about was June 24, 2004; Yahoo claimed they were blocking unauthorized access to their network in an effort to reduce spim.

On that awful, fateful day, all users of third-party IM clients – Adium, Fire, Proteus, Gaim, Trillian, and all the rest – were suddenly blocked from getting their Yahoo fix. For a terrible, miserable hour and fifteen minutes, at which point Cerrulean studies found the two line change needed to more precisely match the authentication hash the official Yahoo client sends... and shared it with the open source community.

They can keep requiring stricter and stricter authentication compliance; AOL's OSCAR protocol for AIM already calls for a hash check against data stored inside the AIM executable. Gaim supplies the same data the official client would. If it's sent over the Internet, it can be packet sniffed; if it can be packet sniffed, it can be implemented by the protocol geniuses.

IM spam really is a growing problem though, especially as IM moves into a larger communications role. While you may have very different motives than joe-spammer botting a services' IM network, would it be fair to say that both 3rd party IM clients and the spammers use the same means to different ends? I.E., the changes you mentioned to re-establish Yahoo connectivity were rolled into LibGaim, which were then picked up by other clients, but couldn't they just as easily have been rolled into IMSpim2000™?

I haven't really done my homework on IM spam, and as I have never received a single piece of IM spam even though my IM names on every service are listed on the Adium team page, I haven't had any incentive to do so. However, I would argue that the spam claim on the part of the companies is mostly absurd, a ploy to bring users back to the advertising-sporting official client.

Sure, IMSpim2000™ could make use of the Yahoo changes, and if it exists as such I'm sure it did, an unfortunate byproduct of the real users getting access to the fix... but the bot could much more easily be an add-on to the official Yahoo client than a full protocol code+bot package. Certainly that's how the AIM bots I remember using (for purely legal, non-phishing purposes of course!) functioned back in the day.

In that vein, where is 3rd party IM heading? Do you foresee a perpetual race of change and patch? Or do you see something new on the horizon?

Hmm.. corporate policy can be amazingly resistant to so-called "facts". I expect they'll just keep trying, with varying degrees of unsuccess.

To present the other side of the argument, what if they're playing by a separate set of facts? You mentioned the protocol geniuses, and I don't think there's any doubt that given the time these things will be reverse engineered. But we haven't seen the fully end-to-end encrypted protocol yet, and we haven't seen the client with 180 stored hashes and encrypted routines for choosing them, which could well bring in the DMCA. Long-term, in the age of the DMCA, is a reverse-engineering strategy one you still think can win in the end?

Grrr, DMCA. I'm afraid if I talk about it Homeland Security might postpone the election for national security reasons until I'm hunted down and interrogated for my anti-patriotic statements. They'd never do something so undemocratic, though, I'm sure. :)

You make an excellent point. My gut is that either reverse-engineering will continue until the big players get tired of messing with a worldwide community of individuals who thrill to the challenge of playing their ‘games', or some other arrangement will be reached. The latter seems unlikely; the companies want their IM services to be profitable, as that's why they exist in the first place, and so are going to demand either licensing or advertising, while I doubt the 3rd party programs would agree to either.

It may be tough, and next week Microsoft may introduce the new MSN-MSDNA Scanner to verify that your DNA matches the database they have secretly been collecting of individuals whose computers have been shown (via Office and Windows Autoupdate scans) not to have any third party software, but I stand by my claim that anything they can dish out we can take.

Instant messaging clients have been around for awhile, and by and large chat clients have fairly standard interfaces. But multi-protocol apps are fairly new, and many projects still seem to be trying to find paradigms that work well. Where do you look for inspiration in designing the UI, and are you happy with AdiumXs' paradigm?

I'm happy with most of our paradigm; the only multiprotocol issue which sorely needs work is our status system, which is still very much AIM-centric with just "available," "away," and "idle." That'll get fixed before too long, but it's a big project to handle it dynamically across multiple protocols which often don't have congruent state options.

I look everywhere for UI options. Unrelated programs sometimes have good solutions to novel problems. Other IM clients rarely satisfy me with their implementations, but it can be educational to see what they tried and to attempt to extract the good and leave the bad – almost every client, including the official ones, does something right, and it's only logical learn from it.

For example, iChat's buddy list provides an outline of a great system for supplying state and user information at a glance; it is the inspiration for a new set of customizable contact list options which Adam is currently slaving over.

Speaking of slaving over the code, people might not realize you're in the middle of applying to medical school. That's a pretty divergent focus from working on an open source chat client. What holds your interest in working on AdiumX instead of, say, studying or drinking more?

Obsession, mostly :) It's more fun than studying – just ask anyone who was under strict instructions in March and April to beat me senseless if they spotted a code commit when my away message claimed I was studying for the MCATs.

Drinking more, I've found, is not necessarily inconsistent with working on Adium... many times last year I'd be up drinking with friends, they'd head to bed, and then they'd wake up the next morning to find me sleeping in my desk chair in front of the laptop, XCode open on both screens as usual.

It's just plain glorious having something you care about and in which you feel like you can uniquely make a difference, and I have discovered how much I like the feeling of staying up until dawn riddling out the solution to a problem or the best way to implement a feature.

WebKit-based Message Views

You've moved to using webkit for the display of message styles, allowing a chat windows' appearance can be modified with simple HTML & CSS. Where did the idea for this come from? And even though its in its infancy, have you been surprised at the creativity shown by the theme authors?

I've no idea who first mentioned the possibility; it was a long time ago, in fact. As soon as we knew of WebCore and later WebKit, it seemed like a sweet idea – all the power behind Safari harnessed to make Adium's message display beautiful and easily modifiable.

We had an empty WebKit Message View plugin target sitting in our project file for months... an enterprising, since-retired developer thought he would make it happen, then discovered it wasn't nearly as easy as it sounded. We filed the whole idea away as a pipe dream until Colloquy came along.

Regarding style authors' creativity, absolutely. You just have to look through the WebKit Styles available on our Adium Xtras Message View Styles page to see a wide range of web design talent displayed in yummy IM message view form.

There are basic "build your own browser" tutorials out there for webkit and Cocoa, which might make this look like a trivial feature to impliment. Where there any challenges you have hit in moving to integrate WebKit into your app?

The biggest challenge, and the reason we rejected the idea of a WebKit message view when it first became available in OS X, is that a web page is nothing like a conversation. A web page is largely static; it has information which it displays to the user, and that's that. A conversation changes constantly; the information being displayed must update each time a message is sent or received.

WebKit is great, but it's far too slow to reload an html file each time a message goes through without visible lag. Colloquy is an excellent up-and-coming IRC app; xeon figured out a nifty javascript trick using javascript to append to HTML and CSS rather than needed to reload the whole page. That's what makes the WebKit views which are in Colloquy and Adium, and more recently Fire and Proteus, possible.

Beyond that, there are some oddities to performance and CSS rendering which a CSS guru could tell you more about than I can – I just work here :) Hopefully Safari 2.0, which I hear is coming down the pipeline with Tiger and hopefully to Panther as well, will offer some nice improvements in that department; I expect it will, since Apple is using WebKit for non-webpage material in their new Dashboard technology so probably has focused on squeezing the most out of it.

The community, and number of users coming onboard seems to be growing in leaps and bounds. This is generally seen as a good thing™ for any project, but does a quickly growing user base bring its own set of challenges?

It does, but with a strong community like ours they are self-correcting. The seasoned users are around to guide the new ones in forum etiquette and general troubleshooting, so it ends up somewhat balancing out. The day after a release (so approximately once a week) the forums are crazy though.

To touch on that, the previous Adium mantra of "So customizable you'll crap your pants" attracts a certain type of user, but pretty message styles attract another type of user. Less geeky users are pining for working file transfer, geeky users think that's what FTP is for and other things need a higher priority. Has this been something you've had to deal with as the base has grown and changed?

It has, but I can no longer even keep the types of users straight in my mind. It seems like almost every person has an entirely different, often contradictory, set of priorities in an IM client, the file transfer and voice-video and IMAP email checking people to the applescripting and random-away-message and bouncing-scrolling-contact-list-which-has-wings-like-a-flying-toaster people and everywhere in between.

Some users have even gotten angry when we've decided that their particular preference isn't one that's actually best for the program and the userbase as a whole; these ‘select few' have gone rampaging about other forums spreading poison about how we don't listen to anything users have to say. Fun stuff :P

If you could push a feature request or perhaps a bug on your wish-list to the top of Apples' radar for OSX, what would it be?

Feature: I wish Apple would open up the APIs for their iApps a lot more. iChat gets to have a little "buddy availability" column in Mail.app, for example... there's no way I can find (even having done class-dump searches) to supply that information from Adium's buddy list. I know Apple likes people to enjoy their iApps, but it only makes good business sense to let the platform be as immersive and intuitive as possible, and that really requires supporting 3rd party developers in at every turn.

Bug: I've filed a bugreporter item for this one, but haven't heard back yet.... The Keychain access code likes to crash sporadically. It's frustrating because there's no good way to reproduce it, and it seems to most users who experience it like Adium is just crashing on launch.. but as far as we can tell we're making a standard call to the keychain as per documentation, and then *boom*.

To touch on your feature request... If we follow the iApp modus operandi, there'll be a paid upgrade for the iApps sometime between now and Tiger, but then they'll be included with Tiger as an incentive for upgrading. There's a meme going around that bundling the iApps with the OS essentially makes them part of the OS, and that locking out 3rd parties is extremely harmful... do you think they are setting themselves up for a developer backlash?

What a touchy subject, especially given the recent fiasco with Konfabulator and Arlo Rose's very vocal response to Apple's introduction of Dashboard. Knowing how much of myself I put into working on Adium, I can only imagine how developers such as Arlo feel when all of a sudden their work is superceded by a product which may not even be better but is bundled with the OS – creating a huge activation energy for any new user even considering the third party solution.

Developers in general seem to be feeling a little afraid of the company that used to feel like a father of sorts; it can be difficult to remain motivated when there's a chance of this sort of thing happening. Closing the iApps and other bundled programs to access from 3rd party apps serves to further this impression that there's an "inside" and an "outside" and only Apple can be on the "inside."

It's discouraging and counterproductive, and I hope for everyone's sake they change their policy soon. According to the released information, it looks like they are planning to open up Spotlight, Automator, and Dashboard, for example, to third parties. Maybe this means the already-established iApps are opening up, too - that'd be nice.

Mac users, developers included, are a fairly dedicated lot, so if a backlash comes it will be later rather than sooner, but Apple definitely is setting itself up at present to be worse off than it would be if it embraced its most important partners – the developers who create what people use. No matter how beautiful that flat-panel hangable tablet iMagic system is, if the software isn't there, it's useless.

In the spirit of the site, what's your spirit of choice?

So many great ones, so little time. I think I'm going to have to say Maker's Mark; on the rocks or with a coke waved at it by an understanding bartender, I'm a huge fan.

yummy alcohol posted button Posted by drunkenbatman
    July 15, 2004, at 03:39 AM

Comments (16)

Post a comment

Anonymous comments are allowed, but please enter something for a name.

And do endeavor to appear sane.

Remember personal info?