ReadWrite web posted an article titled “Google Should Stop Playing Around With Wave and Focus on Spreadsheet” a few days ago.

As the title suggests, the author believes Google is wasting time working on Google Wave and should put their efforts into Google Docs SpreadSheets.

I believe there are a few misconceptions. Google wave is not the Google Wave Client, that is in private beta. That is like saying GMail is Email. Google wave is an open protocol (like SMTP for email, or XMPP for IM) for realtime concurrency control.

On the other hand, ordinary folk create real apps on spreadsheets all day long.

More people use Email, IM and Social Networking. This is the areas Google Wave will be used in.

Real-Time Spreadsheets? That Is So 1980s, Dude!…
Online spreadsheets that anyone can edit concurrently solved the version control problem. Problem solved! Done, finished. Can we move on now?

No, not just yet. Version control is not concurrency control. However, they are often used synonymously. Simplistically, version control, is the saving of changes made to a document, while concurrency control, is the merging of these changes.

Here is an overview of version control systems in use today. Most of today’s version control systems such as used in Subversion, Mercurial and GIT implement a copy-modify-merge for their concurrency control. I’ve already blogged about how concurrency control in today’s version control systems is different from realtime concurrency control.

In the case of Google Docs, including Google Spreadsheets, there is no concurrency control. If you simultaneously edit a document with another user, any save overwrites the previous save. So if your update had not reached the user yet, it would be lost.

Google Wave implements true realtime concurrency control. It does this using Operational Transformation (OT), which is not new, and used by other software. What is new is that Google went ahead and defined a standard protocol for editing documents concurrently.

Most importantly Google built Google Wave on top of XMPP Federation (Open Source Instant messaging), so that anyone can host a Google Wave server by hosting an XMPP server and/or XMPP component, just like hosting an SMTP (Email) server. They also went ahead an made an open source implementation of the Google Wave Server. (I’ll be adding a post on how to build the Google Wave Server on CentOS 5). Already, there are other implementations of Google Wave Servers such as pygowave and yet to be release EJabberd extension (XMPP for client-server also).

This is a very important factor. If Google had not made Google Wave an Open Standard that can be implemented by anyone, they there would be very little hype about Google Wave from developers. I wouldn’t be writing this article. Instead I’d probably be joined by others criticizing Google for creating a monopoly on a new technology. However, Google made the “right choice” and made Google Wave and open standard like the rest of the open internet standards.

Now that we have a better understanding of what Google Wave is, we know that it:

1. Is not a software like spreadsheets, it is a protocol
2. It offers a basis for real time concurrency control that spreadsheets do not have
3. Spreadsheets and similar applications will be built on Google wave in the future
4. Better communication and collaboration is a much greater need then better spreadsheets

So you cannot say stop working on Google Wave and work on the Spreadsheets since they are not mutually exclusive. Working on Google wave will bring much needed true realtime collaboration features to spreadsheets. In fact it will bring realtime collaboration to the whole web, allowing the creation of applications that surpasses the uses of the spreadsheet.

Almost every software developer has used some sort of source code version control system. You’re probably familiar with the acronyms GIT, SVN or the now aging CVS. Here is a list of version control systems.

Version control is a form of concurrency control with the benefit of revisions. Todays major versioning systems work by creating a copy of a resource, and allowing a user to work on that copy. The user then checks their modified copy back to the central source code repository. If the copy at the repository has changed, then the user must merge the two changed copies together.

Since each user is working on a remote copy, there is no real time collaboration involved at all. Each user must edit their copy individually without input from the other users. The collaboration is somewhat chunked, instead of a smooth integration of two or more users inputs.

I’ve been waiting for the day when real time concurrency control is integrated with source code version control. Just lately Google launched Google Wave, which essentially implements real time concurrency control in document editing. A while before that, Appjet Launched their Etherpad product, which implemented real time concurrency control in document and JavaScript source code editing.

Neither of these currently implement source code version control. However, they are proofs that real time concurrency control can be achievable over the web (HTTP) using Operantional Transformation (OT).

Now the missing link is to tie together a real time concurrency control system, with a version control system. Imagine checking out a document with a number of colleges, editing it concurrently in real time, and checking it back into version control.

The model of source code versioning will change dramatically with integrated real-time concurrency control. Checking out a copy may be a thing of the past. You can just join a a group that is editing a live copy, and revisions can be saved automatically for individuals and/or the group as a whole.

Add your own thoughts here…