Presence and real-time messaging are core themes of applications and services in unified communications and collaboration. In these user-centric worlds, applications, users, and devices must share presence, messages, and data. There is not (nor will there be) a single communications protocol that spans this diverse and growing universe of communications endpoints.

Based on the activity in our pipeline and the OEM deals we’ve signed (click for a recent example) Jabber is becoming the de facto standard for presence-enabling existing services and applications. Jabber easily bridges legacy and standard protocols to aggregate presence with speed, scale, and security. Jabber, Inc.’s technology is multi-protocol now, and it has the flexibility to extend to future protocols as they become established.

With the acquisition of Antepo, Adobe has made a deeper commitment to XMPP, joining the ranks of leading technology companies such as Apple, Google, Sun and others. IBM’s recent XMPP interoperability announcement is further evidence of the growing mainstream acceptance of the protocol. With such powerful backing, XMPP has clearly reached a tipping point, achieving recognition as the industry open standard for real-time messaging and presence.

Jabber, Inc. was the first company founded around this open standard (XMPP is also known as the Jabber protocol as it owes its origins and governance to the Jabber open source project). Jabber XCP, Jabber, Inc.’s XMPP-based messaging and presence platform, is chosen by our customers for its scalability, extensibility and multi-protocol interoperability. We recognize that messaging and presence will never be a single-protocol world, but it is nevertheless gratifying to see our native protocol gain such a significant endorsement.

Congratulations to Adobe and Antepo!

We were chatting the other day with an industry analyst and he started reeling off the “Web 2.0″-ish companies he’s working. We asked him about presence, and how these companies are going about making their services live.

The response was surprising and practically made us yell, Why in the world would they do that? You see, many of these companies view presence as core to their offering. Totally agree with them there.

As a core component many of these folks have gone about the business of trying to build their own presence server. The theory seems to be that “our application relies upon the ability of our users to know the presence of their buddies, and we therefore must own the presence engine.”

I beg to differ. Your service also needs a web server, and a bunch of hardware, and network connectivity, etc. Do you need to build all of those components yourself? I would argue that for many of these companies, presence is backend functionality, the application they build on top of it and how they market it should be their core focus.

At Jabber, Inc. we’ve already done the hard work with a massively scalable presence server that will interoperate with any network and just about any device. You can embed Jabber presence into just about any application and aggregate the presence from other devices and applications as well.

To illustrate the point, we recently closed a deal with a Web 2.0ish company which had been using an open source presence server (which is a nice way to get started.) But once they realized that their application and the success of their business was predicated on the ability to support millions of users, they had to go shopping and arrived at Jabber, Inc. because we’re the only store on Massively Scalable Avenue.

When Jabber, Inc.’s far-flung road warriors got caught by the recent snowstorms, presence was our first line of communication. Some stranded travelers wrote custom presence messages such as “stuck in Dallas, call my mobile”. Others used mobile IM to see who was available at headquarters to help them make new travel arrangements. In one case, colleagues on separate trips were able to meet up to share a rental car back home. With presence so ingrained into the Jabber, Inc. culture, no one was unaccounted for and people got help in real-time.

With the New Year, Jabber, Inc. enters its eighth year in the presence business, so it isn’t surprising that we use presence technology almost instinctively. What I find surprising is that there are so many organizations that are entirely presence-free. Sure, plenty of people are using enterprise and public IM to get their work done more efficiently, but typically, presence is only used to see if someone is available for a phone call or IM session. This situation is going to change radically in 2007.

I hereby go on the record boldly predicting that 2007 will be the Year of Presence in mainstream IT. Business decision-makers and IT professionals will realize that it is imperative to presence-enable communications and business processes, just as it was imperative to network-, then Web-enable business applications and processes in the 1990s. Be presence-enabled or be square. Don’t say I didn’t warn you.

The principal catalyst will likely be telephony, the technology invented 130 years ago, in the Centennial year of the United States. All forms of real-time communications benefit from presence and phone calls are the mainstream real-time communications medium. As digital telephony makes deeper inroads into the enterprise, presence will tag along and become integrated into the basic infrastructure of business.

While there will be growth in the business use of IM, that isn’t my point. The high-order bit is that from this point forward, real-time presence will be a basic information technology requirement. It all started with the dialtone. In the Web 1.0 era, Scott McNealy coined the term “big friggin’ WebTone switch” to capture the imperative of Web-enablement.

We are now entering the mainstream presence era, where aggregating and pervasively embedding presence becomes a business-critical IT mandate, just as becoming Web-enabled was back when Scott McNealy first spoke about Webtones. Jabber, Inc. has a programmable and scaleable real-time presence engine, which is an excellent foundation for the Big Friggin’ Presence Switch.

Best wishes for a happy, prosperous and presence-enabled New Year!

Right Model Wrong Architecture vs Right Architecture Wrong Model

…Or more simply Microsoft vs Google

Interesting remarks from Bill Gates chronicled by Liz Gannes of GigaOm.

According to Liz:

We each got to ask Gates one question. I asked which applications he forecast to live within the browser and which outside of it.He replied that the distinction would come to be silly from a technical standpoint, but that the necessary movement toward web APIs does present challenges on the business side. “One of the things that’s actually held the industry back on this is, if you have an advertising business model, then you don’t want to expose your capabilities as a web service, because somebody would use that web service without plastering your ad up next to the thing.”

His solution wasn’t very specific: “It’s ideal if you get business models that don’t force someone to say ‘no, we won’t give you that service unless you display something right there on that home page.”

Then for the tease: “And, you know, [inside the browser and outside the browser are] moving towards each other, but there’s still a bit of a barrier there, and new technology, things we’re working on, really will change that.”

Interesting in a few respects. On the closing quote, we were talking with a journalist yesterday who reminded us that way back when Microsoft was making the case that the Internet was just an extension of WindowsNT. Hmmm…

All kidding aside, I think Bill is definitely onto something here. If apps and data are going to primarily live in the cloud and we’re going to access them as Live Services, there are two fundamental issues that must be dealt with (and probably many more as well).

1) Scale of the presence engine. Live Services need presence, and making everything live exponentially increases the number of “presentities” (the network nodes and data streams on the network that publish and subscribe to presence information). This is no longer one person one device type presence but one person many devices, many applications, data stores, etc. How well presence scales becomes super relevant in this scenario.

2) You’ve got to have an extraordinary level of trust in the provider of Live Services that they are going to protect your data and deliver services when you need them.

Google presents a real challenge to Microsoft because they have already embraced Live Services and have the infrastructure and architecture to roll them out broadly. But…do you trust a company with an advertising model to protect your privacy and other data? They make their living off of selling your information after all.

Microsoft on the other hand has an infrastructure and architecture that doesn’t lend itself very well to rolling out Live Services. Its applications are heavy and its development model (Ray Ozzie’s initiatives notwithstanding) has not proven itself nimble in a “Web 2.0” sense. That said, they don’t rely on advertising and have a history of providing trusted (albeit security deficient) applications.

At present, there is no one company covering these issues comprehensively. Microsoft must build scalable presence, Google must build trust. At Jabber, Inc. we’re watching this looming battle with the inherent interest of an arms dealer.

Lots of analysis on IBM’s federation announcement with AIM, Yahoo!, and Google Talk.

I especially enjoyed Mike Gotta’s supposition that IBM might be laying the foundation for “a multi-protocol presence server that could integrate with a variety of signaling interfaces. Nahhhh….”

This gets at the concept of decoupling presence from any one application, so that no application owns presence but each uses it to publish and subscribe to live data.

Mike points out here that IBM’s federation announcement (particularly as it relates to Google Talk which is XMPP-based) “signals that there are no technical barriers for similar XMPP interoperability issues within intranets as well.”

A few notes for IBM customers:

a) this is the beauty of XMPP…the federation that works for Google Talk will work with any XMPP implementation. To test an oversimplification go to Meebo.com and enter your user ID and password in the Google Talk box…If your XMPP server is accessible over the Internet, you will be able to log in. Extended to an IBM shop…deploy any XMPP service on your network and the new SameTime gateway will work.

b) Jabber, Inc. has already built a multi-protocol presence server that integrates with a variety of signaling interfaces at carrier-grade scale with military-grade security. The flexibility of XML and XMPP means that IBM shops can presence-enable new and existing network services by adding Jabber XCP™ and it will work with the existing SameTime front-end.

Interoperability means more choices and we’re thrilled to see IBM further embrace open standards.

Scalability has always been a hallmark of Jabber XCP, in fact it was the primary reason we forked away from the jabberd open source code back in 2000 and why we have almost no code in common with that project today.

Scale, followed by extensibility, and broad interoperability were the driving forces for our largest customers back then. When we delivered the real-time messaging service for Disney’s Go network back in the day, we were tops in scalability by just about every measure. Today, scale remains a key issue for really big customers, including many carriers, which is why we just completed some heavy load and scalability testing.

When we stepped into the test center recently, we already knew we could scale, with one telecom customer having already certified Jabber XCP as capable of supporting 100,000 concurrent users on a single box. We walked out a few weeks later in awe of our server and the 1,020,000 concurrent users we have now been independently certified as being able to support across a single domain.

For this test, the baseline was 420,000 concurrent users on a single T2000. Each concurrent user was programmed to methodically exchange messages, presence, and subscription requests to simulate likely scenarios in a carrier environment. At the top end of this test we had 1.8 million registered users with an average roster size of 30 . Each concurrent user performed an action every 120 seconds for the duration of the test, resulting in more than 15,000 delivered stanzas per second…these were not stagnant accounts.

What amazed even us was that as the scale of the test increased, the efficiency of Jabber XCP also increased while CPU utilization decreased significantly. For Jabber, Inc., this furthers our hypothesis that the scale of Jabber XCP - even in a single domain - has no known limit, clearly reaffirming that when it comes to scalability, Jabber XCP is in a class by itself.

If you’re interested, I’m happy to answer publicly or privately any questions about our methodology and results, along with the specific hardware requirements necessary to achieve supreme scale using Jabber XCP.

Please post your questions here as comments to this post or email me personally at ckaes AT jabber.com.

Mike Gotta’s continuation of a discussion on ‘the cost of distraction’, itself a continuing thread from here and here is very salient at Jabber, Inc.

Attention is our most valuable commodity, what we are attending to at the moment is what gets done.  There are all manner and means of distracting me from what I am doing in the hopes of getting me to do what you need or want me to do.

One argument (to which Mike poses a plausible counter) is that interruptions are killing the productivity of the interrupted.  Mike’s counter is that perhaps the interrupters are having an equal or greater increase in their own productivity as they are able to get the information they need when they need it from the interrupted.

So, while the cost equation may be in question, the trend is unmistakable: there will be more means of interruption in the future, not fewer.  The key then is how to manage those interruptions?

At Jabber, Inc. we see this as a problem of disaggregated presence and attention management (a topic that seems to be popping up more of late.)  We think the solution lies in presence models that account for a seemingly limitless number of rapidly changing variables very quickly to present me with just the information I need or want at a specific moment.

In a press briefing this week, Joe Hildebrand (CTO of Jabber, Inc.) got to talking about presence-oriented networking.  The salient item being that if you can trust the layers of security, authentication, and transport methods below the application and data, you can begin to make some very interesting policy choices that allow information to route itself based upon an individuals availability, location, organizational role, current capabilities, subscriptions, etc.

It is complicated stuff to be sure, but it is also being deployed today to help first responders and financial traders amongst others attend to the stuff that requires their immediate attention while filtering out the stuff that isn’t helpful in the moment.

“Convergence does have some merits then-mainly in cutting costs and increasing efficiency-but the hype is wide of the mark. Its chief significance is that it heralds the advent of far more vigorous competition in the telecoms industry. It will be a bloody fight for the companies involved, but the ultimate victors will be their customers, who will benefit from greater choice and lower prices.”

Such is the opinion of The Economist in a special report on the future of telecoms [subscription required], which I thought flowed nicely with an early draft of some marketing copy we’ve been kicking around that is targeted to the same senior executives the writers chide.

Proposed text reads “The convergence of voice, video, text, data, along with fixed and mobile technologies represents a leap frog opportunity for some and a potential body blow to others.”

As The Economist goes on the argue, converting all content-regardless of origin or destination-into Internet Protocol (IP) technologies makes too much sense in cost and complexity terms alone for anyone to ignore it entirely.

The other side of that equation is that the macroeconomics of convergence wreaks havoc on existing business lines. Any basic service is easily commoditized and the consequences for traditional pricing models are predictable, severe, and ultimately unavoidable.

So, the people we want to reach with our message are in unenviable positions because they know the way forward likely involves the slaying of sacred [cash] cows. Yet they have big dreams. They envision the winners as the world’s most valuable brands because they manage customers’ attention—very personally—at the customer’s own request.

Right now, our best customers are the ones who either had no sacred cow to begin with or have already resigned themselves to its impending sacrifice on the altar of creative destruction. They are investing in architectures that support services that follow identities, not devices. These same services can publish and subscribe to an aggregated model of presence that allows information to seek people; reaching them only in the context they want it to find them.

Their vision is attainable, and I don’t think there is too much hype in what the end game looks like. However, the road to convergence nirvana will be paved with ideas that were before their time, brands that lived and died on the changing habits of just a few key connectors, and probably many others.

A constant that will run through every winner will be how their services interrelate, cooperate, and compete for our attention, which to Jabber, Inc. sounds a lot like what we already do.

It’s the tagline for Jabber, Inc., but what does it mean?

To extend the filaments/bulb theme: when the light is on, people and systems can see the context of other people, systems, and things more clearly.

Yes, but that doesn’t really answer the question…

The Power of Presence is the ability to control the dimmer switch, and choose where, when, and at what to shine the bulb. The power lies with individuals and systems; each exerting some control over what they see as well as what parts of them can be seen by others.

Separately, the many strands of presence offer variable luminosity, collectively they are powerful beacons influencing what information goes where, to whom, and when, why, and how it is consumed.

The value of search-driven advertising is the flicker of a distant candle in comparison to the power supplied from aggregated presence. Just taking myself for instance, many different entities have access to lots of pieces of my presence. My mobile carrier knows when I’m using that device and perhaps even my location, my satellite provider knows when and what I’m watching, my bank and credit card companies know what I buy and where, certain people and services know when I’m online, search companies know what I’m looking for at a given moment, and so on. But none of them sees the entire context, which includes who I’m with, precisely what I am doing or what I would rather be doing.

But, some already know more than others. From service providers to content producers to technology providers to organizational consumers of content, there is a race on to illuminate as much context as possible.

The drive by telcos to offer triple and quadruple-play services to consumers is at a very deep level about presence and context, and not simply about average revenue per user (ARPU).

If my quadruple-play vendor knows what I am watching, when I am watching it, and knows (because I told them) that I don’t want to be interrupted during that show, they can prevent most electronic interruptions (alas, they cannot control the person sitting next to me). Moreover, if they could aggregate - with my permission - things on my calendar, they could do really useful things, such as sending a coupon for “dinner, Saturday night.” But, and it’s a huge BUT, my service provider knows nothing of what kind of food I like, what neighborhoods I prefer, etc., not to mention those of my companion(s). Some of that information can be mined, the trick is in getting me to trust any one company with enough information so they can extrapolate and make recommendations without annoying me or otherwise violating the trust I have granted them.

In the more controlled environments of an enterprise, using presence to route information in the right context is already an achievable end. But is it possible in the consumer space (i.e., do you think you could trust any one company that much)? We can envision scenarios where clearinghouses and other trusted third parties broker information exchanges of a highly personal nature that are to the mutual benefit of individual content consumers and producers. What do you foresee?