AOL Jilts Open Source
Cerb writes "AOL seems to have retracted the specs to its TiK protocol." The lead paragraph of the ZDNet story Cerb sent in says, "The controversy surrounding America Online Inc. and instant
messaging has spilled over into the realm of open source, raising
fundamental questions about open-source licenses and commercial
vendors' use of them." Could they do the same to Mozilla? A scary thought.
...should be ignored unless they are useful in other contexts. A client that has no use outside a non-open server should not be considered open source but rather a marketing gimmick.
Obviously, a client that could be used as a base for a completely open source solution is a different matter. Beware of big companies with limited open source projects.
Geeky modern art T-shirts
The way MS and Yahoo are saying that they want open protocols is such a joke, when they aren't even willing to open up their own.
I can't even get them to get me minimal information that would let me extend GTKYahoo to all of the new capabilities. I have been able to do some of the features, but others require the new login method, which I haven't been able to figure out how to generate.
Maybe it doesn't push ads now, that MSIM has like no marketshare. But if they succeed in getting marketshare, I'm sure MS will capitalize on it.
Here's how I see it:
M$ is once again jumping on a bandwagon after it has proven to be a moneymaker, and they're trying to use AOL's own servers against them.
Once they get enough marketshare, they'll simply add new "enhancements" that will be hard for AOL to duplicate using their networks, include it in future OEM releases of Windows, and gain marketshare unfairly, with their Windows monopoly advantage.
Without the false "Open Standards" push, and connectivity to AOL Instant Messenger, they run a risk of people installing the AOL IM Client even if the MSIM client comes with Windows, so they can talk to their AOL friends.
Microsoft needs to be able to make MSIM interoperate with AOL IM, or their whole strategy won't work.
The fact that M$ owns 90%+ of the OEM Operating System Pre-installs makes the whole thing tilted in Microsoft's favor. In anything to do with the Internet, that's what they're banking on.
They're too easy to read, especially after all those trials showing their business practices.
One relatively unrelated note here:
EFNET has gotten better lately as far as the script-kiddies, since it's much harder to get illegitimate channel operator access even if you resort to flooding servers, flooding clients, or the like. It's still possible in many cases, but with a large enough channel, and enough bots, it's next to impossible.
While I'm the spokesperson for EFNET , I will agree that most channels on EFNET are crap. Then again, most channels on most servers are crap. You gotta find what's good and stick to there.
As for IM versus IRC, IRC wins out. It's a lot more 'underground', in many cases.
What I __WOULD__ LOVE to see, is some encrypted IRC servers for the major networks, and some clients to boot. Preferably 128 bit or better encryption.
Even better would be to be able to share keys in private chats and among members of a channel, and keep even the server operators from being able to monitor the connections (since that's not what they do anyway) at any point anywhere in the chain.
This would be a big boon to IRC IMHO, but it might be painted by the media as an area of complete lawlessness since there would absolutely no way the government can monitor conversations between people via the internet. We're talking no phone taps, nothing like that possible. This would be the first completely secure form of communication for large numbers of people.
I could see the government making something like the scenario above impossible to achieve.
...whether you can use someone elses resources *without* their permission. Say for instance that a silk-screening shop created some really cool software to automate their shop. They decide to make it GPL.
Now, does that mean that I can use the software in my shop? Yep, I'd guess so. But does it mean that I can just walk in to their shop and start a batch of shirt's to sell in my retail store? What? No? Why not? Their software is open source, isn't it? But does that mean that they'll refuse to let the local LUG use their shop to print shirts for their members? Maybe they won't have a problem "donating" a few shirts. Does that have anything to do with open source though? Does that give me the right to freely go in their and print shirts for my retail store because the LUG can? Well, what's the difference, huh? I mean, how could anyone be so inconsistant. Shame on them...
It's the same with AOL. Sure they can make their protocol open source. Yep, they can even let others come in and use their servers. But that doen't obligate them to let everyone freely help themselves to others resources.
MS can use the AIM protocol for all AOL cares, I bet. But on their *own* servers, not AOL's. Otherwise, MS can get off their behinds and start negotiating a contract with AOL to use AOL's servers to host their Instant Messaging service.
In time we'll have a multi-vendor IM protocol that allows a bunch of servers to interopolate, just like e-mail does now. When that happens, AOL has indicted that they will support it. But until then, MS needs to pay up...
Otherwise, I can't wait until the local video rental store starts using open source software to run the store. Free Video rental, anyone?
-BrentTOC (the protocol that TiK uses, the protocol that AOL released specs for) is a pidgin, text version of the binary OSCAR protocol that is used by the "mainstream" AIM client. (AOL has a gateway box somewhere that speaks TiK on one side and OSCAR on the other. All this effort is because OSCAR is a much more powerful protocol and you could do lots of interesting stuff that AOL wasn't quite intending yet if you had the specs to it.)
Also, OSCAR uses a weird, AOL-internal application framework similar to what's used in the AOL client. (In the beta version, you can actually pop up a console window and avail yourself to AIM's command language, complete with aliases and other random "features.") It's based on dynamically-loaded modules that talk to each other according to a special message-passing architexture.
This would lead me to think that any code contributed to TiK would be of limited utility to the main AIM developers. No temptation to violate the GPL.
[The information in this post comes from, umm, staring at the AIM login screen really hard and meditating. Yeah, that's the ticket.]
Instant messaging should work roughly like mail: distributed and ubiquitous, without ties to advertising or a single vendor. ISPs should provide the necessary infrastructure just like they provide SMTP services (in fact, some mailers have support for instant messaging, but that hasn't caught on in an ISP-based world).
I wouldn't blame AOL for not building such an infrastructure--it just has nothing to do with their business. The open question is whether the newly commercialized Internet actually allows for new protocols like a vendor independent IM protocol to catch on and become ubiquitous in the same way SMTP, HTTP, and many of the other classic protocols caught on.