Archive

Archive for the ‘Software’ Category

I’m Dumping My Blog for Google Wave

December 14th, 2009
Comments Off

IStock_000001136467XSmall  When I first started blogging in 2006 or so, I loved the idea of being able to have conversations with people all over the world, many of whom I didn’t even know existed.  It’s served me really well in that respect, I’ve met a ton of people and developed my most important online social network.  I have several relationships in the real world that developed because of blogs.

Then Twitter came along, and was all real-timey and stuff.  It’s fun.  It feels like a cocktail party.  I can blurt out things that I think would make funny fortune cookies and there’s an audience for that I guess.  But in terms of content it was a real lightweight compared to blogs, the medium is just too constraining.  At its core Twitter is a 140-character message bus, and there are lots of things lacking there for heavy-duty collaboration to happen.

Next came Facebook, which allowed me to find a lot of people but not necessarily the ones I wanted to have technical conversations with.  It’s also completely ungeared towards anything longer than a sentence or two, the commenting system resembles a car with just an engine and a frame and a steering wheel.  Also not suited to hard-core collaboration of any kind.

Over time the collaboration model on blogs got better with the introduction of commenting systems like Disqus (although I still don’t like the fact that I rely on them 100% to safeguard those comments).  But it never really changed much, we always had blogs and RSS to distribute and comment on meatier content.

But then, this year, came Wave.  And I fell head over heels in love with it.

It’s rough, sure, but even at this point it’s a much, MUCH more exciting medium than a blog, or even Twitter.  The potential for new kinds of interactions feel limitless at this point–integration with applications, robots, all kinds of cool new things to explore.

But potential alone isn’t enough to make me move, it’s really the dynamic of the conversation that has won my heart.

To me it feels like the difference between writing a magazine article and starting a conversation.  Instead of pontificating on what I think about something, I can just seed a conversation by saying “Hey, what if?” or “Hey, what about?”  The interaction in a Wave is so much more organic and spontaneous, and it feels more genuine.  I can seed a Wave with an idea and other people can take it and run with it, taking it on tangents that I never even talked about; I can just watch in real-time.  I’ve had several collaboration sessions spontaneously break out just based on who’s reading a wave at the same time. That’s new and awesome.

Waves are also different than blog posts in that they continually evolve.  There is no “publishing a post” anymore, because it’s never really done.  Instead of 5 different posts with subtle twists on a new idea, the original idea can take off in a new direction and stay in the same conversation.  I can see Waves staying relevant and vibrant for years once the UI can accommodate that.

Lastly, it just feels right.  When I go to jot down a thought now I continually find myself saying to myself that this would be a better fit in a Wave than a blog.  So into a Wave it goes.  The blog is being bled to death.

So anyway, long story short, I’m going to be Waving much more than blogging from at least a while in order to fully explore this medium.  I’ll probably continue to post the end result of a Wave into the blog, but only after I’ve posted stuff to a Wave and given it a chance to percolate for a while, and maybe edit the original post first to incorporate Wave discussion.  My blog posts will now be written by “Jason Kolb and the Google Wave community” :)

The only problem with that at the moment is that Wave is more of a I-will-opt-you-in than an opt-in model right now and I don’t want to spam my entire contact list with Waves they’re not interested in.  So the solution is:  A Google Group.

Right now the only way to do an opt-in Wave group is to create a Google Group and then include that Group in the Wave.  So that’s what I’ve done, and if you want to be included in my “Wave Distribution List” then you’ll need to opt-in to the Google Group.

You should follow me on Wave by subscribing to my Google Group here.  

The member list is private so there won’t be any spamming or anything.

I like the fact that I can control distribution too, even make it invite-only at some point possibly.  Oh yeah, I’ve also opted in a few people I know personally so if they don’t like it I’ll buy them a beer or something.  Sorry guys :)

So that’s it then: I’m dumping my blog in one respect, which is that I won’t be posting here first anymore, or even often.  The only time I’ll post to the blog is when the community creates a Wave that is just too good not to preserve in a more static way.

Sure there’s a lot of infrastructure such as tools and tricks missing that blogs and tweets have built up over the years that’s missing right now.  But they’re corner cases, things that can–and will–be added over time.  Right now it’s still more powerful than any other medium out there. 

I feel like it’s something I should be using daily in order to stay on the bleeding edge of it and what it’s capable of. And then, as the platform grows I can grow along with it, and hopefully push it a little.  I still stand by what I said a few months back:  Google Wave is a game-changer.  While it might not be a perfect replacement for blogging yet, I’m willing to struggle thru it until it works, because it’s the tool I want to use.  I’m a programmer to boot, so I can always hack stuff when it’s all open-sourced eventually.

My gut says that blogs will die as a result of Waves.  Well, not die, but change pretty dramatically.  Blogs as we know them today won’t exist, but it will be much easier to do what I’m trying to do right now and it might look very similar to a blog today in some cases.  Will be interesting to find out, anyway!

Oh, and if anyone else does this please let me know, I’d love to subscribe and see how it works out for you.  The not-so-technical details about how this works are on the Group page if you’re curious.

BIG, blog, Business Intelligence, Business Stupidity, google wave, Ideas, Investing, Market Watch, Online Identity, Personal Development, Politics, predictions, Random Thoughts, Review, Semantic Web, social networks, Software, Software Development, technology, Unified Communications, User Interaction, Web 2.0

Looming Disruptions to the Software Industry

October 11th, 2009
Comments Off

FissuresI view a major shift in technology, like the one that I see materializing right now with Google Wave (the protocol), as a huge object crashing into a an existing landscape.  There’s this massive change right in the middle, a new space that has to be filled, and then all these fissures spidering out from the main event where the rest of the world is affected by that event–new spaces that must be filled with something.

One of the fun things about technology disruptions is trying to figure out what the landscape will look like after the main event.  It’s those changes that nimble businesses can take advantage of to pivot into the new spaces that were created.  For example when the Web finally went mainstream it created an entirely new industry, but it then proceeded to change the way every other existing industry operated to some degree, and we’re still working through that with things like hosted applications and the SaaS model.

Conversation-Centric Communications

I’ve been doing a lot of thinking about the impact of a conversation-oriented communications model on application architecture, and the concept of software applications in general.  A week or so back I wrote that this was one of the most important bits of the Wave architecture:  the way they modeled a conversation in which the idea of a participant is malleable.

It seems like a forgone conclusion that all applications which require use by more than one person will move to this model sooner or later.  Just as SaaS apps are becoming mainstream, the game is changing, and the more nimble companies have an opportunity to pivot into a brand new space which is right now being created by this disruption.

While it’s fun to talk about these things in the conceptual sense, I think it’s more practical to get down to brass tacks and figure out the specifics as much as possible.  Here are a few things that I’ve come up with so far, would be interested to see if anyone else can add to this list:

  • Applications will be much less visible.  By being participants in a conversation it’s natural that applications would work within the existing conversation environment, extending it where necessary.  The measure of an application’s user-friendliness will now be how well it integrates into a conversation.  The days of going to a distinct URL to use software are numbered.
  • Service applications will grow like wildfire.  Some applications no longer need an interface at all, you will simply add them to the conversation and they will do things in the background.  For example, adding a text analysis service to a conversation would only require adding it to the conversation, along with its output.  Twitter has shown some of this potential, but only the amount that’s allowed by its restrictive architecture, API, and medium–that is, not much.  You can count on every Twitter application being rewritten to watch conversation hubs.
  • Applications will be seen more as components, or capabilities, than distinct and unique units of software.  Because of the lack of a need for an extensive user interface, and the fact that deployment is as simple as adding an application to a conversation, the very idea of what software is morphs into a capability that you add to your communications rather than software that you purchase and download, or sign up for and
  • True object-oriented applications will become a reality.  Call me archaic, but I hate the current MVC architecture that we’re stuck with to get around the limitations of the disconnected Web.  It sucks; sorry, face it.  With all applications effectively on the same message bus now, and sockets in the browser with HTML5, and linked data on the back-end, true distributed object-oriented programming in the client is closer than you think.  Praise God.
  • The conversation container will become the new AppStore.  Adding capabilities to a conversation requires that you be able to find that software and import it into the conversation.  The conversation container is king in this respect.  There’s a big potential here for conversation containers to displace the iTunes App Store as the hottest new software distribution channel.  I would be shocked if Google isn’t already looking at this–if they have the pre-eminent conversation container then they have an opportunity to displace Apple in the App Store business.

I’m still chewing on this list, but this is what I’ve come up with so far.  There’s definitely more, especially in the online identity area, but I’m still digesting that.

All in all I think this is certainly a larger number of disruptions than all but a few people out there are expecting.  The first domino is falling, and now it’s just a matter of looking at where it’s going to fall.

app store, BIG, blog, disruptions, google wave, jason kolb, Semantic Web, social networks, Software, Software Development, technology, Unified Communications, User Interaction

A Vision of a Post-Wave Internet

September 25th, 2009
Comments Off
This is a follow up to my last post about Google Wave, er, XMPP.  That post generated a ton of commentary and questions, and my goal here is to address a lot of them, as well as take a stab at outlining what a post-Wave Internet looks like to the average person.

First, there were STILL some questions about why exactly Wave and XMPP are so cool.  Well, the short answer to that is that the guys working on Wave did a number of things right.

The Conversation

The first thing they got right is the concept of a “conversation”.  This is not some marketing-speak, they actually went and modeled a conversation in a protocol.  That’s huge.

Why is this important?  Because as applications are becoming capable of doing more and more on their own, they’re turning into participants in a conversation, not a destination in and of themselves.  The fundamental way you interact with your applications is changing–you’re working WITH them, not IN them.  You are collaborating with your applications, perhaps even multiple applications, in a conversation.

Haven’t you ever thought of a new system you’d like to build and thought that there has to be a better way to interact with the users themselves, at a fundamental level?  Creating a new account in a system and then logging into that system as one of 500 different URL’s that you’re required to remember is just stupid.  It flat doesn’t work.  Turning the application into a participant in the conversation changes that dynamic.  The federation aspect of Google’s extension to the XMPP protocol handles this magnificently, 

XMPP

The second thing Google did right is build on top of the XMPP protocol.  (The protocol is an XMPP extension, look it up.  It runs on an XMPP server, look it up. ‘Nuff said.)  This is important because in order to participate in a conversation with someone or something you need to be able to talk to it.  Right now, we are in a world of walled gardens:

  • Facebook  
  • Myspace 
  • LinkedIn 
  • Enterprise applications 
  • Home applications 

These are very proprietary systems and you certainly cannot talk between them without something translating in the middle.  If you wanted to write an application that worked across Facebook and Linkedin, for example, you’d have to write it twice, and translate in the middle.  And then there is still no standardized way to talk with OTHER applications.

But once you can talk directly with someone or something, bypassing the proprietary gatekeepers, the value of the entire network grows exponentially with each new connection.  Go look at Metcalfe’s Law.  I would argue that not only does the value of the network grow exponentially with the number of connected users, but also with the capabilities that those users have when interacting with each other.

The point of the whole thing is that endpoints on the network—whether it’s your phone, a Web site, a client in the browser, can talk directly with each other.  Now, I am quite obviously abstracting away some details here, thanks to everyone who pointed that out :P  Your phone and my phone obviously do not have a direct IP connection to each other.  But think about this:  If a message is *routed* directly to the other device, doesn’t that have the same effect?  That’s what XMPP enables.

XMPP Addressing

Now, HOW does XMPP do this?  It addresses people in the form you@yourdomain.com.  Email format.  This is a feature of XMPP, and the wave protocol does not change this.  Instead of a username on Twitter that only the Twitter API knows how to talk to, or an email address that is a proxy for a username on Facebook or Linkedin, which also requires an API to get to the actual user, you can talk directly to the user.  The domain identifies the server, the username identifies the user on the server.  It’s simple, and works well.  XMPP also provides for ways to talk directly to different devices that a user might be on.

This necessitates a server that speaks XMPP on both ends.  That server listens to messages to and from the users on that domain—including applications.  It also speaks with the other XMPP/wave servers across the Internet to syndicate and synchronize data as necessary.  Do you see how this creates an application message bus that works across every network in the world that runs the protocol?

In the same way that companies run their own email servers, they will run their own wave servers.  But not only will the replacement for email be stored on that server, but the interaction with applications as well.  The data generated by an application participating in these conversations lives on the wave server (provider), so you can easily have partners working on your system, in your system, with your system, and in the same conversation, but storing your own data on your own servers.  Now that’s what I call collaboration.

Also, there’s nothing stopping you from running your own wave server, just the same as lots of people run their own Web and email servers.  It’ll be the same thing as email all over again, your ISP might be your wave provider for a while, or your company, or Google, or Hotmail, or whatever.  It’s all open-sourced from that perspective.

Remember what I was saying about the existing social networks becoming dumb pipes?  If they don’t support wave they bleed users.  But in order to let their users participate in a wave they’ll have to open up the XMPP floodgates.  They will no longer control the conversation between their users end-to-end, in fact users from multiple *social* networks are free to communicate freely amongst themselves.  This relegates the *social* network to a “dumb pipe”, and I’m sure they will fight this tooth and nail.  For everyone else it’s a flat-out win, because they can do more, everywhere.

A Post-Wave Internet

So, stop thinking about where the Google client ends and start thinking about what comes after that, because you can talk to anything now. It is a platform to build on, it comes free with the success of this new communication technology.  

Assume for a minute that Google successfully launches wave and it becomes the next “email”.  Think of the possibilities…

  • You want to update somebody when their vacation or benefits change is approved?  Have the HR system send a message via XMPP, and listen for it on the other end.  The other end could be a Web app like Google’s, a fat client, or your phone. 
  • You want to update your team when a critical metric crosses a threshold?  Have your application watch it and then create a new conversation alerting your team.  You could also include a workflow system in the conversation.
  • You want your cash register to send your customer’s phone a request for payment authorization?  By all means, send them the request and then listen for the response.  My entire shopping history with you is a conversation, but I’ll keep my thumbprint to myself on my phone, thanks
  • You want big flashing lights and a heavenly chorus to play when you walk in the door of your house?  Let your house listen to location updates from your phone, sent by the client and subscribed to by a client on the computer in your house.
  • I’d like to keep a running conversation with Amazon about my purchases and recommendations.  I want to include LibraryThing and Mint as well to track other aspects of my reading and financial histories.
  • When a customer buys a product, you are engaging them in a conversation.  Especially if it’s complex–they ask questions, you answer, they ask for help, you help, you give them tips and tricks, and so on.  Your support systems should be involved in this conversation. 
  • When I want to sell some old furniture, I’m starting a conversation with potential buyers.  If I add an auction system to the conversation it should connect me with interested buyers and join them to the conversation. 
  • If I answer a customer question, I should be able to pick an interesting bit out of a conversation with a customer and add that to a different conversation that is shared with a wider audience.  Again, people should be able to see this update on whichever kind of device they’re using at the time. 
  • Meetings spontaneously generate conversations, actions are taken in the midst of this (see the bug assignment demo in the Google keynote), and workflows and external systems are automatically triggered. 
  • Reports and information are continuously published to ongoing conversations, updating participants in realtime, regardless of where they are at the time. 
  • Sharing is comprised of conversations now, and you host your stuff wherever you want to.  Go check out the photo sharing demos from Google.  File sharing via special services (including social networks) is a thing of the past.  As I said in my last post, storage is a utility now.
  • Blog posts like my last one turn into a giant conversation, with all of the various social aggregators like Digg and Reddit turning into participants as well, branching off their own private sub-conversations (wavelets) that only include their own user community.  Or include everyone, whatever.  Subsequent posts, like this one, are part of the same conversation.
  • Sites like TechMeme and other “curators” come almost for free.  They’re just outlines of conversations, displaying the most active branches. 

I could keep going.  But I won’t, because that’s your job :)

I hope I’ve done justice to this thought in my head.  I hope that you realize that I’m extrapolating the possibilities IF wave actually gets traction, and this stuff isn’t going to come for free with the Google version of a wave client either.  I’m talking about what the ripples will look like across the technology spectrum.

P.S.  A point of clarification:  A Web site like the Google wave client should absolutely be considered an XMPP client.  It doesn’t matter what protocols the Javascript and GWT code uses, that’s irrelevant.  The point is that it’s an XMPP endpoint that a user uses directly.  Do you think users care about whether the browser is talking to the Web server XMPP?  No, of course not.  They get the benefit of the XMPP interaction in front of them and they couldn’t care less if it the browser communication is happening in semaphore.  I am talking about the network itself, you are talking about the form the client takes.

P.P.S.  I am aware of the scalability issues with XMPP.  After reading the Wave protocol specs, I believe that Google has solved this problem with their federation model.  A wave provider serves all of its local users, so the wave only has to be sent to each domain ONCE.  That is key.  Google’s federation model makes perfect sense to me and I see no reason why it can’t scale VERY well.

BIG, blog, google wave, internet, jason kolb, Online Identity, predictions, social networks, Software, Software Development, technology, Unified Communications

Google Wave: You need to pay attention to this.

September 17th, 2009
Comments Off

So here’s the deal with Wave:  If you deal in technology, and you get this one wrong, you’ll miss the boat.  And it’s a big boat.  If, on the other hand, you get this one right, you have the potential to do some incredible innovation.

In a nutshell, this is the next revolutionary leap in Internet application architecture.  Maybe the first truly revolutionary leap since HTTP itself.

I’ve been wanting to write this post for a while, but first I wanted to read fully thru and digest the specs and available code.  I haven’t done any posts about XMPP for quite a while, but you’re going to start hearing a whole lot about it, and not just from me.

What is it?

Ok so what exactly Google Wave is can be confusing, because there are three parts:  the protocol, the server, and the client.  A lot of people are really going to miss the boat here if they don’t keep the distinction between the three in mind, because I see a lot of people focusing on the wrong parts.

The Protocol

WaveAndXmpp At its core, Wave is an extension to the XMPP protocol.  This is the REALLY important part.  Here I’ll back up for a moment for a little background on XMPP.  

XMPP is a protocol which describes communication.  It models communication between two nodes on a network.

Now, communication can take many forms, and XMPP accommodates many of them.  It also supports different types of conversations:  presence, notifications, subscriptions, back-and-forth–these are all modeled by XMPP.  And it supports a wide variety of communication TYPES as well:  video, audio, text, and so on.

I hear people mistakenly talking about Wave as immature or new technology.  It’s not.  XMPP has been around since 1998, being developed and actively worked on for almost 12 years now.  It’s been approved by the IETF since 2004.  

Although it’s been mostly used for chat, that’s only the tip of the iceberg when you dig into this protocol.  I’m still pretty flabbergasted that this protocol hasn’t been used more than it has, and I’m excited to see somebody finally tapping into its potential.

I’ll touch on what Google has brought to the table with the protocol in a minute, but suffice to say that if Wave takes off as I hope it will, the full power of the XMPP protocol will finally be available as a core piece of application architecture.  This is the real game-changer here, and what you need to be thinking about.

The Server

The server (a “wave provider”) is a modified Openfire XMPP server that understands the Wave protocol extensions.  Openfire has been around for a while too.

While wave providers are used for storing and server XMPP content in Google’s implementation, there is a lot of potential in turning existing applications into wave providers as well.  Any existing server-based content can be used as the basis for a wave, so just about any application out there right now has the potential to extend its existing functionality by offering its contents as waves.

The Client

Ok, this is probably what you’ve seen videos of.  It’s a wave client because it speaks wave protocol to wave providers.  

Google_wave

What Google has done is develop the first really full-featured XMPP client, which also uses some of their new XMPP extensions to facilitate things like character-by-character updates.  They’ve developed an incredibly sexy client, and I’m glad about it, because a sexy client like is what’s required to sell an innovation this large to both the mass market AND the technical community.

What Google has done, exactly?

So what exactly has Google done to the XMPP protocol?

A couple of things:
  • It recognizes a conversation as data, and stores the data in a persistent way that can be easily referenced over time.  Conversation storage and persistence is a huge gaping hole in enterprises right now, which you’ll nod your head in agreement with if you’ve ever scoured a wiki for information or cleaned out your inbox because it got too big.
  • It makes XMPP conversations secure and scalable.  By building in synchronization protocols, conversations can take place distributed across the network instead of at specific central servers (which is how wikis, blogs, and microblogs operate).
  • It describes a way to replicate content over a large network so that it’s available on a wide scale while still being fast and synchronized.  Data replication on a global (but as-needed) scale, very cool. 
  • It integrates a very simple and elegant security model which operates on an as-needed basis.  I’ve blogged about this in more detail before here. 

These were some needed additions to XMPP, and really describe some of the peer-to-peer operations that I’ve been looking for for a long time.

Why is this so interesting?

XMPP.  In case you haven’t noticed, I’m a big fan.

XMPP is so versatile that if it becomes widely adopted it will be to the Internet what HTTP was:  a platform for new types of applications.  And where HTTP as a platform is a server-centric model, XMPP is capable of peer-to-peer communication.

Remember what happened when everyone got HTTP clients (they’re called browsers :) ?  The Internet exploded.  Well, if everyone gets a full-fledged XMPP client I think you can expect roughly the same thing to happen.

One of the most fascinating features of XMPP is the way things are addressed.  EVERYTHING is addressable over the network. You can talk directly to ANYTHING, and ANYONE.  I can’t stress how big of a shift that would be from the current model.  It’s HUGE.  I wrote a whole series of posts on this a few years ago, and it’s just as exciting now as it was then.

Let’s take a step back and think about this for a second.  I’ll probably do another post just on the addressing scheme at some point because it’s so key, but it’s worth a brief recap.
  • Right now I cannot send text directly to your instant message account (unless you’re using an XMPP-based client), I have to send the message to your IM server which relays the message to you.
  • I cannot send audio directly to your phone, the phone company has to route it there. 
  • I cannot share a picture directly with your Facebook account, I have to sent it to Facebook first to be carried on to you.  
  • I can’t send a file directly to you, I have to put it on a share or email it to you. 
(Not to mention the fact that these are all disconnected, you can’t combine these into a single message stream.  XMPP addresses that problem very nicely, as the wave client shows.)

XMPP removes these intermediaries from the network.  Social networks and proprietary transports no longer have an exclusive license to deliver content, the clients talk directly to one another.

Do you see the difference?  There are no longer social networks or any other type of networks required to relay the communication, we are now down to exactly 3 components:
  1. Clients 
  2. Storage 
  3. Applications 
Of course there is always the underlying dumb pipes that transport the data, but from a functional perspective the network has been normalized out of importance.

Clients can be whatever we need them to be.  It can be the Google wave client, it can be your phone, it can be a desktop app.  These will evolve over time, but the Google client is a fantastic starting point, certainly light years ahead of anything else that’s available today.

Storage becomes a utility, something you pay for as you go.  I already use this model myself for backups, I shoot them up to the Amazon cloud and pay for the amount I use.  As time goes on my communication–audio, video, pictures, text–will be stored there as well, and I’ll use it in my waves as needed.  (Note that waves do NOT embed this content, they link to it and the client downloads and renders it in place.)

And the applications.   This is really exciting, because just about every application in existence will be transformed by this quantum shift in the network topology.  Applications now interact with your client and provide input to your communication stream, and output to your storage.  They will become a facet of your communication, not a completely disconnected activity.  You will communicate with apps much in the same way that you communicate with people, and they will communicate with you.

Take CRM and ERP systems for example.  Instead of customers emailing you about a sale and then sending purchase orders, it will be part of the “sale wave”.  The entire sale, from start to finish, will be encapsulated in a single wave, bringing individuals in and out of the conversation as need.  The ERP and CRM platforms themselves will be participants in this conversation, recognizing the purchase order, executing the workflow, processing the order, making the order details available to manufacturing or delivery in a sub-wave, and then making the receipt available to the customer and the sales team.  Your CRM Whether you approve the purchase order from your desktop, your phone, or a point of sale device, makes no difference–they can all be directly addressed and participate in the conversation natively.

That’s just one example off the top of my head, but I truly believe that every software application in existence will eventually need to be re-architected to be much less application-centric and much more communication-centric.

The Bottom Line
This is no longer pie-in-the-sky stuff like it was when I was first writing about it.

I have seen nothing else out there that rivals the XMPP/Wave protocol for the sheer richness of the conversation that’s possible, not to mention the fact that it can easily turn into a bona-fide platform for next-generation applications.

The danger, then, is that you ignore this and it takes off.  You and your application will be shut out of this rich, real-time collaborative stream of communication.  You can, of course, tack integration on later, but the real benefit here is to the application that incorporates these concepts into its core architecture.  I can look at just about any application out there and think of tons of potential applications for this technology.

This is the type of revolutionary advance that is required to lift productivity and open brand new possibilities to the extent necessary to revive the economy, which is pretty exciting.  If this post sounds like I’m breathlessly waiting for this technology to take off, it’s because I am, and I have been for about 3 years now.  Here’s hoping Google succeeds.

BIG, blog, communication, google wave, jason kolb, Online Identity, Semantic Web, social networks, Software, Software Development, technology, unified communication, Unified Communications, wave, xmpp

Google Wave: You need to pay attention to this.

September 17th, 2009
Comments Off

So here’s the deal with Wave:  If you deal in technology, and you get this one wrong, you’ll miss the boat.  And it’s a big boat.  If, on the other hand, you get this one right, you have the potential to do some incredible innovation.

In a nutshell, this is the next revolutionary leap in Internet application architecture.  Maybe the first truly revolutionary leap since HTTP itself.

I’ve been wanting to write this post for a while, but first I wanted to read fully thru and digest the specs and available code.  I haven’t done any posts about XMPP for quite a while, but you’re going to start hearing a whole lot about it, and not just from me.

What is it?

Ok so what exactly Google Wave is can be confusing, because there are three parts:  the protocol, the server, and the client.  A lot of people are really going to miss the boat here if they don’t keep the distinction between the three in mind, because I see a lot of people focusing on the wrong parts.

The Protocol

WaveAndXmpp At its core, Wave is an extension to the XMPP protocol.  This is the REALLY important part.  Here I’ll back up for a moment for a little background on XMPP.  

XMPP is a protocol which describes communication.  It models communication between two nodes on a network.

Now, communication can take many forms, and XMPP accommodates many of them.  It also supports different types of conversations:  presence, notifications, subscriptions, back-and-forth–these are all modeled by XMPP.  And it supports a wide variety of communication TYPES as well:  video, audio, text, and so on.

I hear people mistakenly talking about Wave as immature or new technology.  It’s not.  XMPP has been around since 1998, being developed and actively worked on for almost 12 years now.  It’s been approved by the IETF since 2004.  

Although it’s been mostly used for chat, that’s only the tip of the iceberg when you dig into this protocol.  I’m still pretty flabbergasted that this protocol hasn’t been used more than it has, and I’m excited to see somebody finally tapping into its potential.

I’ll touch on what Google has brought to the table with the protocol in a minute, but suffice to say that if Wave takes off as I hope it will, the full power of the XMPP protocol will finally be available as a core piece of application architecture.  This is the real game-changer here, and what you need to be thinking about.

The Server

The server (a “wave provider”) is a modified Openfire XMPP server that understands the Wave protocol extensions.  Openfire has been around for a while too.

While wave providers are used for storing and server XMPP content in Google’s implementation, there is a lot of potential in turning existing applications into wave providers as well.  Any existing server-based content can be used as the basis for a wave, so just about any application out there right now has the potential to extend its existing functionality by offering its contents as waves.

The Client

Ok, this is probably what you’ve seen videos of.  It’s a wave client because it speaks wave protocol to wave providers.  

Google_wave

What Google has done is develop the first really full-featured XMPP client, which also uses some of their new XMPP extensions to facilitate things like character-by-character updates.  They’ve developed an incredibly sexy client, and I’m glad about it, because a sexy client like is what’s required to sell an innovation this large to both the mass market AND the technical community.

What Google has done, exactly?

So what exactly has Google done to the XMPP protocol?

A couple of things:
  • It recognizes a conversation as data, and stores the data in a persistent way that can be easily referenced over time.  Conversation storage and persistence is a huge gaping hole in enterprises right now, which you’ll nod your head in agreement with if you’ve ever scoured a wiki for information or cleaned out your inbox because it got too big.
  • It makes XMPP conversations secure and scalable.  By building in synchronization protocols, conversations can take place distributed across the network instead of at specific central servers (which is how wikis, blogs, and microblogs operate).
  • It describes a way to replicate content over a large network so that it’s available on a wide scale while still being fast and synchronized.  Data replication on a global (but as-needed) scale, very cool. 
  • It integrates a very simple and elegant security model which operates on an as-needed basis.  I’ve blogged about this in more detail before here. 

These were some needed additions to XMPP, and really describe some of the peer-to-peer operations that I’ve been looking for for a long time.

Why is this so interesting?

XMPP.  In case you haven’t noticed, I’m a big fan.

XMPP is so versatile that if it becomes widely adopted it will be to the Internet what HTTP was:  a platform for new types of applications.  And where HTTP as a platform is a server-centric model, XMPP is capable of peer-to-peer communication.

Remember what happened when everyone got HTTP clients (they’re called browsers :) ?  The Internet exploded.  Well, if everyone gets a full-fledged XMPP client I think you can expect roughly the same thing to happen.

One of the most fascinating features of XMPP is the way things are addressed.  EVERYTHING is addressable over the network. You can talk directly to ANYTHING, and ANYONE.  I can’t stress how big of a shift that would be from the current model.  It’s HUGE.  I wrote a whole series of posts on this a few years ago, and it’s just as exciting now as it was then.

Let’s take a step back and think about this for a second.  I’ll probably do another post just on the addressing scheme at some point because it’s so key, but it’s worth a brief recap.
  • Right now I cannot send text directly to your instant message account (unless you’re using an XMPP-based client), I have to send the message to your IM server which relays the message to you.
  • I cannot send audio directly to your phone, the phone company has to route it there. 
  • I cannot share a picture directly with your Facebook account, I have to sent it to Facebook first to be carried on to you.  
  • I can’t send a file directly to you, I have to put it on a share or email it to you. 
(Not to mention the fact that these are all disconnected, you can’t combine these into a single message stream.  XMPP addresses that problem very nicely, as the wave client shows.)

XMPP removes these intermediaries from the network.  Social networks and proprietary transports no longer have an exclusive license to deliver content, the clients talk directly to one another.

Do you see the difference?  There are no longer social networks or any other type of networks required to relay the communication, we are now down to exactly 3 components:
  1. Clients 
  2. Storage 
  3. Applications 
Of course there is always the underlying dumb pipes that transport the data, but from a functional perspective the network has been normalized out of importance.

Clients can be whatever we need them to be.  It can be the Google wave client, it can be your phone, it can be a desktop app.  These will evolve over time, but the Google client is a fantastic starting point, certainly light years ahead of anything else that’s available today.

Storage becomes a utility, something you pay for as you go.  I already use this model myself for backups, I shoot them up to the Amazon cloud and pay for the amount I use.  As time goes on my communication–audio, video, pictures, text–will be stored there as well, and I’ll use it in my waves as needed.  (Note that waves do NOT embed this content, they link to it and the client downloads and renders it in place.)

And the applications.   This is really exciting, because just about every application in existence will be transformed by this quantum shift in the network topology.  Applications now interact with your client and provide input to your communication stream, and output to your storage.  They will become a facet of your communication, not a completely disconnected activity.  You will communicate with apps much in the same way that you communicate with people, and they will communicate with you.

Take CRM and ERP systems for example.  Instead of customers emailing you about a sale and then sending purchase orders, it will be part of the “sale wave”.  The entire sale, from start to finish, will be encapsulated in a single wave, bringing individuals in and out of the conversation as need.  The ERP and CRM platforms themselves will be participants in this conversation, recognizing the purchase order, executing the workflow, processing the order, making the order details available to manufacturing or delivery in a sub-wave, and then making the receipt available to the customer and the sales team.  Your CRM Whether you approve the purchase order from your desktop, your phone, or a point of sale device, makes no difference–they can all be directly addressed and participate in the conversation natively.

That’s just one example off the top of my head, but I truly believe that every software application in existence will eventually need to be re-architected to be much less application-centric and much more communication-centric.

The Bottom Line
This is no longer pie-in-the-sky stuff like it was when I was first writing about it.

I have seen nothing else out there that rivals the XMPP/Wave protocol for the sheer richness of the conversation that’s possible, not to mention the fact that it can easily turn into a bona-fide platform for next-generation applications.

The danger, then, is that you ignore this and it takes off.  You and your application will be shut out of this rich, real-time collaborative stream of communication.  You can, of course, tack integration on later, but the real benefit here is to the application that incorporates these concepts into its core architecture.  I can look at just about any application out there and think of tons of potential applications for this technology.

This is the type of revolutionary advance that is required to lift productivity and open brand new possibilities to the extent necessary to revive the economy, which is pretty exciting.  If this post sounds like I’m breathlessly waiting for this technology to take off, it’s because I am, and I have been for about 3 years now.  Here’s hoping Google succeeds.

BIG, blog, communication, google wave, jason kolb, Online Identity, Semantic Web, social networks, Software, Software Development, technology, unified communication, Unified Communications, wave, xmpp

Google’s Ingenious Wave Security Model

September 15th, 2009
Comments Off

Reading through the Google Wave specs this weekend, I realized that Google has really accomplished something wonderful with the security model baked into the Wave protocol.  (Not the CLIENT, specifically, but the extensions Google made to the XMPP PROTOCOL.)

Usually security is done one way, in just about every application on earth:  you create the thing you want to secure, whether it’s a file, or an email, or a piece of content, or a financial transaction, then you find a security button somewhere that usually looks like a big lock or something:

Images

You click that button, and from there you can select the users who you want to have access to your thing.  This is all fairly standard, and there are very few deviations from this.  Entire companies have been founded to make this process a little less painful.

I don’t think I’ve ever looked at an application’s security model for the first time and thought “wow, that’s really easy”, which is the way EVERY feature SHOULD be.

Until now, that is.

Reading through the Wave protocol specs I realized that they kind of changed the workflow for applying security to things.  Instead of setting security as a separate operation, the security for a Wave is constructed as the wave is being used.

Security in a normal application is very disconnected from the act of using the thing you’re securing.

With Wave, however, you add people as they’re needed.  The act of adding somebody to the conversation grants them permission to operate on the Wave.  You can break off into sub-Waves (“Wavelets”), and give people access to just those as well, by adding them to the sub-wave instead of the main wave.

It has the effect of creating functional user groups on the fly, moving individuals in and out of the group as needed by creating new wavelets.  As opposed to the typical model of preconfiguring user groups and tweaking them as needed.  

I think you could call it “participatory security” versus the old “administrative security” model.  The whole idea seems kind of a “duh” item in retrospect, like all great ideas I suppose.

I was just very impressed with this as it’s the first common-sense and intuitive way to handle object security that I’ve ever seen.  It’s going to be such a great fit for the enterprise that I seriously cannot wait to begin using it myself in an application.  I’ll be interested to see how this model ends up either competing or integrating with Microsoft Exchange.  If they’re smart, Microsoft is watching this VERY closely.

I have lots more to say on Wave, but suffice it to say that I’m very keen on the security model it employs, and will be rooting very hard for it.  It’s a nice simple and elegant solution to what’s been a pain forever.

blog, google wave, jason kolb, security, Software, Software Development, User Interaction, wave

Google’s Ingenious Wave Security Model

September 15th, 2009
Comments Off

Reading through the Google Wave specs this weekend, I realized that Google has really accomplished something wonderful with the security model baked into the Wave protocol.  (Not the CLIENT, specifically, but the extensions Google made to the XMPP PROTOCOL.)

Usually security is done one way, in just about every application on earth:  you create the thing you want to secure, whether it’s a file, or an email, or a piece of content, or a financial transaction, then you find a security button somewhere that usually looks like a big lock or something:

Images

You click that button, and from there you can select the users who you want to have access to your thing.  This is all fairly standard, and there are very few deviations from this.  Entire companies have been founded to make this process a little less painful.

I don’t think I’ve ever looked at an application’s security model for the first time and thought “wow, that’s really easy”, which is the way EVERY feature SHOULD be.

Until now, that is.

Reading through the Wave protocol specs I realized that they kind of changed the workflow for applying security to things.  Instead of setting security as a separate operation, the security for a Wave is constructed as the wave is being used.

Security in a normal application is very disconnected from the act of using the thing you’re securing.

With Wave, however, you add people as they’re needed.  The act of adding somebody to the conversation grants them permission to operate on the Wave.  You can break off into sub-Waves (“Wavelets”), and give people access to just those as well, by adding them to the sub-wave instead of the main wave.

It has the effect of creating functional user groups on the fly, moving individuals in and out of the group as needed by creating new wavelets.  As opposed to the typical model of preconfiguring user groups and tweaking them as needed.  

I think you could call it “participatory security” versus the old “administrative security” model.  The whole idea seems kind of a “duh” item in retrospect, like all great ideas I suppose.

I was just very impressed with this as it’s the first common-sense and intuitive way to handle object security that I’ve ever seen.  It’s going to be such a great fit for the enterprise that I seriously cannot wait to begin using it myself in an application.  I’ll be interested to see how this model ends up either competing or integrating with Microsoft Exchange.  If they’re smart, Microsoft is watching this VERY closely.

I have lots more to say on Wave, but suffice it to say that I’m very keen on the security model it employs, and will be rooting very hard for it.  It’s a nice simple and elegant solution to what’s been a pain forever.

blog, google wave, jason kolb, security, Software, Software Development, User Interaction, wave