Jabber Asks the Tough Question

How do you make money with something that becomes ubiquitous internet infrastructure? It's a question Jabber is asking about instant messaging and presence.

Doc Searls is the Editor in Chief of Linux Journal


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: Jabber Asks the Tough Question

Doc's picture

Several things.

First, Jabber is serverware. Not clientware. In that respect it's just like Apache and Sendmail, both of which also don't care about clients. If people don't like any of the Jabber clients already out there, they're free to write one of their own.

Second, Jabber doesn't compete with any of the centralized IM systems out there today. It's about letting you or me or anybody set up their own IM or XML routing or presence management system (it does all those things) and use whatever clients you like, including any you roll on your own. The good work Jabber folks have done to make AIM and MSN clients work with Jabber is embrasure, not competition. It's about compatibility and interoperability. It's about the Net, not anybody's private IM system, least of all one of their own.

Third, Microsoft would certainly be very smart to support and push for the adoption of Jabber, and to support Jabber compatibility for its MSN Messenger cleint. I would think there is a potentially large business for anybody selling Jabber-derived servers and services, which is Jabber, Inc.'s business already. But they don't have to be alone there.

Fourth, Jabber routes XML streams. That makes it highly compatible with all sorts of stuff. Add SOAP and/or XML-RPC and you've got interoperability with all kinds of other services, including many of the things Microsoft is doing with .Net

Re: Jabber Asks the Tough Question

Anonymous's picture

There's been a fair amount of commentary on Jabber in Linux Journal, but it really isn't terribly clear what it does better than anything else, or why we should be that bothered about it.

Messaging is a vague concept all by itself, and no-one is going to get worked up about something if they can't immediately see it in action and get to grips with it themselves. Having said that, the technical audience of Linux Journal readers should be somewhat receptive to more abstract concepts, but I don't think we've reached the point where the "clouds have parted" and we have "seen the light".

Why would IM users care about Jabber? Well, it's surely a similar story as to why they would care about any other IM system out there. I first got onto ICQ because various friends of mine were on there; later, various friends took up AOL chat instead, so I downloaded Gaim. There are supposed to be gateways which let Jabber users chat with lots of different IM systems, but they never appeared to work (or be up), so that seems to be another unique feature crossed off the list.

Why would messaging providers care about Jabber? I can't see AOL, Microsoft or Yahoo being bothered about letting their IM users chat "across borders". Meanwhile, the fact that "Jabber routes XML streams" is too vague even for most developers to bother evaluating the technology further - us open source people have lots of "itches to scratch", remember!

So, either it's a question that Jabber really isn't up to much, or Jabber really isn't being explained that well. Given the way lots of open source projects present themselves, I suspect that the latter case applies here.

Re: Jabber Issues

Anonymous's picture

We support Jabber as one of the protocols in our client called Vista (http://i3Connect.com) and this is NOT a flame.

As much as I like Jabber, there are issues with it.

1. None of the Public servers support HTTP proxies. As a result Jabber is useless to folks behind the firewall.

2. No one is offering Jabber as a service like ISPs offer EMail accounts. This makes it difficult for normal folks to use it.

3. The protocol documentation leaves much to be desired. Ok, I understand that software developers don't like documentation. But when Jabber.com’s client JIM does not follow the documentation to send formatted messages, it’s an issue.

4. As an Open Source project, developers want to scratch their itch and not solve the above problems. That’s why you see so many extensions around the Jabber but the focus on the core is lost. No one wants to build a robust IM server like what the Apache and SendMail folks did, but do something cool.

>What we need here is imagination about what can be done with XML-based IM and presence

I disagree. The Jabber community has showed a lot imagination. What is needed first is robustness and some basic features to be taken care of first.

There is no doubt in my mind that lot of cool stuff can be done in Jabber as some of the experiments like jogger show, but it is a question of priorities.

The central issue here is accountability. How do you ensure that customers’ needs are taken care of first in an Open Source project. Answering this question will solve all the above issues.

Jabber is cool but unless something magical happens, SIP will win.



Jabber as competition for exchange...

Anonymous's picture

In my mind Jabber/IM is next generation email, it offers features that pop3/imap miss (especially simple things like mail appearing instantly). Surely in a corporate enviroment there is an oppertunity to replace exchange.


Re: Jabber Asks the Tough Question

Anonymous's picture

I would use jabber except I don't like any of the clients.

Gabber comes the closest to something that I would like. But it is too big. If someone took 2 hours and made the client narrower then I would probably use it. They should take the buttons off the top and just have one new button that pulls up a window to configure stuff.

Perhaps I shouldn't be so picky about UI but I have a small screen and all the space is valuable. This is a small request and it would make jabber useable for me.

I guess I could do it myself but it would take me longer because I have barely used gtk at all.

Re: Jabber Asks the Tough Question

julian's picture

You do realize that I made the option of turning off *all* of the toolbars and the menubar for exactly this reason, right?

Re: Jabber Asks the Tough Question

Anonymous's picture

Gee, its not like you have the source-code to Gabber so you could do exactly that, is it?

Jabber is on my radar screen but,

Anonymous's picture

I work for a company that does system management we sell IBM/Tivoli/Peregrine all these companies have a presence and they make their presence felt. Now that IBM wants its partners to go Linux, we are feeling the water. We do some Linux, Perl, Apache, Bash.

The thing is for a company like ours to get into OSS, we first have to understand it, then we have to adopt it into our business model and then we have to select the applications that we feel we can sell to our customers. License fees are not really important to us selling service is.

The other thing with OSS is that there are often too many competing products providing a similar function. Jabber stands out because it is inclusive.

When an OSS company wants to do business, it has to do marketing. With all the IBM partners getting into the business kicking and screaming there are enough companies who can do a great job with a Zope, a Jabber, possibly with LimeWire. Companies like Jabber are well placed cause our company does not want to get into programming. We are better at documenting, implementing, integrating into the customer business.. So that is something that we would be happy to let Jabber do.

One other thing that is a problem. When people are sold on the idea of OSS, they are told that it is gratis. They are not sold on the idea that they pay for their itch to be scratched. When you pay for proprietary software you pay for a service where it is not clear what you get. With OSS you can write a spec and use it as a RFC and ask for a sponsor. The community can take it up but it will really make headway when there is a sponsor. Also when a bug is found, the cost of fixing can be in two parts, quick fix and proper fix. Companies that implement a Jabber, LimeWire can save substantial amounts of money. It is in their interest to see these products develop. They pay now for better functionality in the future vs they pay with no visible benefit.

Thanks, for reading my rambling


Re: Jabber Asks the Tough Question

wkearney99's picture

This is incorrect. Exchange has shipped with it's Instant Messenger Service since it's introduction. It's free as part of Exchange. No, this isn't the same thing as the MSN messenger client. It's a server component like Jabber. And it's based on RFC standards.


Re: Jabber Asks the Tough Question

wkearney99's picture

I sent a message to Doc taking this a step further. He's asked me to respond here. Here goes...

I think there's an underlying principle of Open Source that can allow for the development of a free and open protocol as the basis for several implementations.

One of these implementations is going to be an Open Source reference platform. This is likely to be the embodiment of the protocol and a reasonably complete implementation.

The other implemenations can be equally free or even commercial. If the other implementions are using solely the protocol then there's little licensing to debate. Much like how Apache and IIS both use HTTP and HTML. However, be clear, I'm not suggesting that another implementation can 'lift code' from the Open Source implemention. If you want the code, you'd have to abide the license.

So for a situation like Jabber it appears they're encouraging an open discussion of the protocol and are freely releasing the code that implements it. They're also working, in parallel, on a separate code base that also implements the protocol with the intention of shipping it as a commercial product.

Some folks are likely to mistrust this intention. Other folks are equally likely to complain that any development on the commercial implementation somehow 'robs' the open source one of something.

If someone misappropriates the code and integrates it inside of their commercial implementation, they will eventually get caught. The PR debacle makes this a hugely risky endeavor.

But asking someone that's taken the time to create a protocol AND a reference platform to ignore the opportunity to develop a commercial implemetation is ridiculous.

Here's an analogy. Perhaps a protocol can be thought of as a language. Let's say you've written a book. That book requires using a new language to sufficiently express itself. If nobody speaks the language then you've got to teach them. Once they learn the language you've then got the opportunity to sell them your book. But at the same time the people are free to do whatever they want with that language. They're under no obligation to purchase your book nor can they reasonably demand you give it to them for free. At the same time you're certainly in no position to demand they cease and desist from using the language for even writing their own books. The underlying principle here is the freely useable language/protocol.

Is this a clear analogy to the Jabber protocol and it's implementations? I think it is.

Is there an opportunity for this to run afoul of evolving protocols? Sure. But it's also a very healthy race, one of who can make the 'best' implementation of the protocol. I think this is a very healthy development for the software industry.

-Bill Kearney

Re: Jabber Asks the Tough Question

Doc's picture

I like the analogy, but of course we run into trouble around the "freely reusable" phrase. There are plenty of people who believe they are in a position to restrict your use of their code. Otherwise we wouldn't have so many arguments about licenses, or such a plethora of them.

Code is like many things: a language, a naturally occurring substance (RMS has compared it to air), a published work, a building material (Larry Lessig calls it "an analog for architecture"), an ecosystem (one that Microsoft has recently picked up)... Choose your metaphor and make your argument.

We have two bazaars here as well: the open source development bazaar, and the commercial bazaar we also call the marketplace.

There are software communities native to both these habitats, and remarkably little cultural overlap between them. But it's there. Like Apache and Sendmail before it, Jabber rides high in the straddle.

I think we're not going to build out the common infrastructure we need unless both bazaars contribute to each other. And we're only beginning to work that out.

Re: Jabber Asks the Tough Question

wkearney99's picture

Perhaps I didn't clearly differentiate between the protocol and the code. They're different. From the analogy I used, the protocol is like a language and the code is like a commercially sold book.

The language; Jabber's protocol, is free. The open source reference platform is a free example expressing the versatility of the protocol. The Jabber.com product is similar to a commercially sold book, one with something 'more interesting' about it.

What's interesting here is Jabber bringing all three to the table at once. They seem to recognize that unless people learn and use it's protocol there's not going to be a market. So they're giving away a reasonably feature complete implementation of the protocol in the form of an open source product. At the same time they're working in parallel on developing a commercial implementation that's not based on that code.

Are they truly separating the two? From what I've seen that appears to be the case. Will they raise a sink if/when the open source platform evolves to compete with the commercial product? Time will tell.

The simple fact of the matter is they've let the cat out of the bag and appear to be willing to accept the consequences.

-Bill Kearney

Re: Jabber Asks the Tough Question

tseng_mike's picture

Okay, this article had way too many focuses/question, puts me off track, heres my comments anyway.

You are damn right about the lack of Jabber support againest AIM, MSN, ICQ, YIM. Look no further than LinuxJournal, the user registration give NO option for you to put your Jabber ID.

Even worst they (Jabber Inc) are not going to get very far if they trademark the protocol name. They should change the protocol name to something other than Jabber. They are in pretty deep ***** about becoming the defacto IM protocol if you ask me. Since it essentually competing with SOAP (shh, its a secret) if you looked at it carefully, but SOAP is a hell lot more popular, not controlled by a single company and got industry heavy weight support.

About the financial rewards for contributors, theres ongoing discussion about paying contributors for fixing sponsored bug/feature on the free software business mailing list [fsb].

Re: Adding Jabber ID

scott's picture

Hi Mike,

Jabber ID will be probably in user info tomorrow or Thursday. Someone (you?) had pointed that out already but I got sidetracked during implementation.

Thanks for reminding me.



Re: Adding Jabber ID

julian's picture

Actually, that was me. Thank you.

Re: Jabber ID added

scott's picture

Just a followup. Jabber ID is now an available option for user's to input. If anyone spots a bug in that, drop me a line.

Scott Blanchard


market recognition

Anonymous's picture

i think they should make a deal with microsoft or aol to get jabber bundled with software that everyone uses. this is how microsoft's messenger and aol instant messenger got users. anything else is doomed to failure, because users don't care about the politics of how they communicate. this isn't the internet of '85 where hackers used email because they could patch sendmail to do what they wanted. this is 2001, get with the times.

Re: market recognition

Anonymous's picture

are you stupid? aol and microsoft are not stupid enough to bundle a competing product with their own. you might as well suggest to red hat to make a deal with microsoft so linux gets bundled with windows xp.

Re: market recognition

Anonymous's picture

I agree. Most internet users today are not going to download and try out the different software emerging, no matter how wonderful it is. To many of them their e-mail clients are difficult enough. To reach enough users you have to find a way to distribute your application in a way where the user do not have to actively go out and get it. Another important aspect is that the application must be as preconfigured as possible. It must work out of the box. The same goes for server applications. And then there is the documentation: The documentation for most open source applications today is way to complicated for the avarage user, using too much technical terms and asuming too much background knowledge. Most non-technical persons will after 10 minutes assume it is an application for geeks and nerds, and move on. The days when most internet users where techies is long gone, and the open source community must wake up and smell the coffee...