What is X.commerce (for the rest of us)?

First, a shout out to the eBay / PayPal / X.commerce organizers of the 2011 Innovate Conference. This was a great event, with a lot of juicy content both in the keynotes and the breakout sessions (though the general consensus was that the NPD presenter phoned this one in).

Now for my take on the X.commerce fabric

Most of the material on the X.commerce website focuses on the benefits without explaining what it really is. In fact, at the Innovate conference, the most common question I heard was, “How does it achieve the stated benefits?” (Okay, actually, it was more like… “we get what the goals are, now, what the hell is it?") Unfortunately, at the end of the conference, I still didn’t have a great answer. (To be fair, I had meetings that conflicted with some breakouts.)

Fortunately, I was there with my developer, and, since I have some rudimentary development skills, I attended Dev Camp. That is where we got a real look at the fabric for the first time. I’ll spare you the geeky details, but we actually downloaded a working version of the fabric (including activity simulators) to a laptop and managed to write some code that talked to the fabric. We enjoyed the ability to monitor the various data streams and see the activity and how the simple applications we created interacted with the simulator.

More importantly, though, we got an understanding of what the fabric is and what its possibilities are. First of all, the X.commerce fabric is a messaging system. Applications (‘capabilities’ in X.speak) can ‘publish’ messages to the fabric and other capabilities can ‘listen’ to those messages. For example, let’s say you write a capability to snipe eBay auctions. Your capability can subscribe to price update messages on auctions for that item, compare them, and recommend which one you should buy based on your desired price, brand, delivery date and so forth.

OK, so, you might claim you can just do that with the existing eBay APIs. You would be correct. However, what if you want to purchase a product on eBay that is also available on Amazon* and other marketplaces? And, what if 10 minutes before your closing bid, the price on Amazon gets lowered below your planned bid?

If Amazon is publishing price updates on its products through the fabric, your app could be listening for both. In fact, depending on how many marketplaces, comparison shopping engines, Craigslists, independent web sites, retail stores, and so forth become partners, your app will be able to listen for similar data from all of them at the same time through a single messaging system! It can then choose to make the purchase on the cheapest trusted platform, saving your user $s and getting you a seat on the couch on the Today Show. (By the way, if you write this app and make billions, please forward my royalties!)

With PayPal’s well-deserved reputation for security, you can bet it thought through the system well. So, while the auction bid is public information, there are other types of information exchanged that instruct capabilities to do something on behalf of an end user (placing that snipe bid at the last moment, for example). These messages require the capability to identify the source of the message and verify that the message is from a trusted ‘publisher’ (the capability sending the message) and that the ‘action’ (bid, for example) has been authorized by the ‘tenant’ (bidder, in this example). This is accomplished by allowing users to establish relationships with capabilities and allowing capabilities to establish relationships with each other, and a system of security ‘tokens’ that verify the relationships.

WHY THE FUNNY WORDS IN QUOTES? Those are the tech terms used by X.commerce developers. In case you read more about it, you’ll know what they are talking about.

Think of it like an old-fashioned stock exchange. You know, the kind where people actually stand in a room and yell at each other. Calls come into brokerages from their clients. Then, the brokerages send runners to the floor brokers who, through a serious of almost vulgar hand signals, let everyone know what their buy price and quantity are. Another floor broker, whose runner just came in with a buy order from his client, signals back that he will buy and how much. Then, the runners go back to their respective offices and relate the transaction.

In X.commerce, the brokerage houses are like ‘capabilities,’ all of whom have access to the exchange (or ‘fabric’). The runners serve as the trusted HTTPS calls being sent back and forth and ‘tenants’ act like the brokerages' clients. Just like in a stock exchange, a new broker can come online if authorized by the exchange. So, X.commerce can verify new capabilities and allow them access to the messaging system of the fabric. Each capability, just like each brokerage house, can operate on its own terms, have its own information systems for keeping track of its trades and clients, specialize in different kinds of products, and so forth. However, when it goes to the floor of the exchange, it knows the hand signals and proper yelling procedures so that it broadcasts its messages to all of the listeners in a way they will understand.

What does this mean for merchants?

The common messaging center and language of the fabric motivate developers by removing risk. They do so in the same way a widely accepted operating system does. With the advent of the Android operating system, for example, a programmer can write an app once that’ll be accessible on many devices and to millions of users. The app creator feels motivated to invest time and energy because of the large market potential. In the same way, a developer writing a capability for the X.commerce fabric will only need one set of code. He or she won’t have to re-write a bunch of interfaces (APIs) for different marketplaces or programs.

What do I predict?

Ebay and PayPal are making an enormous investment (I’ve heard between $1Bln and $4Bln) in X.commerce. Their developers have a solid track record of solving problems in the eCommerce space. While numerous problems exist, you can solve a LOT of them by spending your money wisely. Also, you’ll need that kind of business and technical talent available. It is true that the current form of the fabric is technical-grammar-school language when compared to the Shakespearean poetry necessary to truly inspire developers, merchants, and consumers. Nonetheless, I expect we’ll see Romeo and Juliet sometime next year, with Hamlet following close behind. After all, as more and more developers become fluent in the fabric, each will contribute to the language. As a result, it will become richer and more versatile.

Sure, the eBay companies are the only ones to participate initially. Regardless, there are some very impressive capabilities that will come to the table quickly. They will likely benefit the areas of mobile shopping, payment, customer identification, and so forth. I spoke with a number of developers at companies like Red Laser, Milo, Where, and even Adobe (not an eBay company), that are already in the process of creating or adapting applications for the fabric.

Based on the attendance at Dev Camp, I think there is a strong core group ready to innovate when the fabric goes online early next year. My developer has already started adapting his projects to be compatible with the fabric when it becomes available. [Note to self… give him a raise before he gets poached!] He saw how he would be able to offer niche capabilities to a broad audience. If his enthusiasm (and mine) are any gauge, I expect a number of exciting capabilities to become available early in X.commerce’s life cycle.

Note: *Amazon has not announced its partnership with X.commerce, yet. Let’s hope they do, and soon!