So lately there have been some users requesting a new version of Adium. Well, it’s almost ready. 1.0 is almost done. At last, we’re getting ready for the release that’s been in the works so long, so it’s a good time for some history and some musing.
A History Lesson
In order to better understand what is happening with Adium now, and why there has been no release since May 4th, 2006, first we need to understand where things have been in the past. Firstly, Adium 1.0 has been in active development since May, 2005. To give some further perspective, Adium 0.70 was released in October 2004, and 0.50, the first release after a rewrite of the original AIM-only Adium code was released in April 2004. This should give you a bit of a time frame and perspective as to what has been going on so far.
Secondly, the big difference between 1.0 and the other releases is that it’s really 2 release cycles combined. We decided around the time that 0.80 came out that we would not be releasing 0.90, and instead forge ahead to 1.0 with a “fix everything” attitude. The additional time spent would allow us, we thought, to create a release that would be truly spectacular. It worked out well, but just not in an acceptable timeframe. We will not ever be doing that again if it can be helped. Taking on too much at once leads to lots of complications and unexpected delays.
We garnered the attention of Google for their Summer of Code. They invited us to be involved, and we gladly accepted. That in itself created a large amount of additional overhead, but we thought the benefits would be worth it. The six students that we got were a very telling sign in what we needed to do additionally in order to attract new developers in the future, and to keep existing developers happy.
We also attempted to do something we hadn’t done since before the 0.50 release: we worked towards a wholly new protocol library for a major protocol, AIM.
Java, Joscar and Smack
One of our developers, Augie, spent a great deal of time working along with Evan and Keith Lea on the new AIM implementation using Keith’s joscar library. The joscar branch, as of early July, was, we believed, better than the current libgaim based AIM, so it was merged shortly before the start of the 1.0 beta cycle.
One of our main priorities for the Summer of Code was to improve Jabber, also called XMPP, support. It’s an open standard, and so is much easier for us than a closed network like AIM or MSN. We received a superb application from Andreas, in which he explained that he wanted to improve our XMPP tremendously via a Java library called Smack. Java is a hefty dependency, but we were already utilizing it for joscar and we didn’t expect that to change, so given the minimal additional resource consumption of a second Java library, this was decided to be a great direction for us. We accepted his application as well as Alvaro Saurin’s to implement Jingle (Google Talk) voice support in the Smack library and then within Adium.
Then, disaster struck. Rather, Apple did. They deprecated the Java-Objective-C language bridge that we were depending on. We had a few choices, none were very good. We could spend 1-2 years rewriting both Joscar and Smack to work using JNI, the supported way going forward for what we were doing with Joscar and Smack. We could have spent time doing other things. In the end, the decision was made to move back to Libgaim, and just take it. In some ways this is where Microsoft is a better platform, since they inform everyone of their roadmaps way beforehand. But it’s what we’re left with. Evan, David and myself came up with a letter to send out to everyone, Evan sent it, and we moved on.
Meanwhile, back in Gaim land
The good news is that the Gaim team had not sat idly by for the long period in which we were attempting to use Java libraries. For years we had been building our own unofficial hack out of Gaim and had been calling it libgaim. The Gaim project now officially has something called libgaim, which will evolve into something truly awesome. They also improved the AIM bits quite a bit.
They even were looking at Joscar for tips and tricks on how to improve the AIM support. Hurray Open Source.
I think a word needs to be said for what’s been taking place with our competition. Just to clarify, we generally do not attempt to compete with iChat. We simply cannot. Apple employs many times the amount of people that we could get to work on the Adium project, and in either case they fit another need in the IM space that we just don’t have the resources to compete in.
However, we do have competition. From Fire and from Proteus. It has always been a friendly competition between all 3 clients. Fire has always been around, and Proteus has been around for about the same amount of time as Adium, give or take.
With Adium 1.0, Adium will be able to import most things from Fire. There is a migration path for those folks on Fire in case they would like to use Adium in the future. Fire itself is a very respectable project with some of the same goals that are in place for Adium, and they should be commended for all of their hard work.
We also saw a change from Proteus, in that they haven’t really done too much. There was a change of hands, multiple times, over who would continue working on Proteus. For a long period we’ve seen only promises on the Proteus forums of new features and new features. Proteus is now resting in the hands of a person that goes by Tommy on the forums. He’s been taking things very well, and is promising that Proteus is being worked on, but isn’t promising new versions. In all honesty, the situation he is in is probably not that great, and he’s doing well in it.
However, there was a promise of full source code that hasn’t taken place. This has been promised for the next version. We’ll see, and good luck to them.
We’ll start looking into a migration path for those folks using Proteus into Adium after 1.0. Fire is, however, the priority for 1.0, since they were more than willing to work with us on this.
So what now?
So now we’re winding down development of 1.0 of Adium. We only have a few bugs left on our betas. The current betas have run for 2-3 times the normal beta period, and the results of running the beta for so long have been many additional fixes on top of our original beta.
In total we’ll have around 660 issues resolved in 1.0. 1.0 includes a very large featureset, and a huge amount of bug fixes. Those who remember each of our .50, .60, .70, and .80 changelogs will remember that each were gigantic. What people usually don’t know is that it would take us about 2-3 hours to write up the changelog via SubEthaEdit with 3-4 devs working on it. We could do it automatically, but it’s a very fun part of what we do. We’ve already spent about 10 hours on the changelog for all of the 1.0 betas, and it will take another 2-3 hours to finish combining them all.
It’s going to be an awesome release, and we’re all hoping you folks like it a lot.