Step aside Google Spreadsheets. Bricklin's WikiCalc has reinforcements
Dan Bricklin, the co-inventor of the electronic spreadsheet and now the inventor of WikiCalc, and Ross Mayfield, the CEO of wiki solutions provider SocialText, have gotten together in a unique partnership that could be more disruptive to the status quo than most people may realize. Whether it is or not remains to be seen. But the potential is clearly there now that the Sun, the Moon, and the stars have lined up in this way.
Face it. Web-based computing is inevitable. 99.99 percent of the problems people cite as the reason they'll never move, including "the offline" and the privacy/data security problems, are resolvable. With no legacy software business to protect, companies like Google, AOL, eBay, Salesforce.com and Yahoo have enough reach and might and no holds barring them from dethroning the desktop as we know it. The proof is in the pudding. Dating back to the pre-Microsoft ownership days when HotMail was quite possibly the the first to take a mainstream desktop application (email) and move it onto the Web (not in some freaky proprietary client from Compuserve or Prodigy, but the Web), Web-based apps have slowly been on the march to replace their desktop counterparts.
And it's not like nobody is signing up. The total number of users of Web-based applications is not in the hundreds, thousands, or hundreds of thousands. It's in the millions and climbing everyday. Where are these users coming from if they're not coming from the desktop world? OK, maybe some of them are running in dual modality like I am. I use a Windows-based client for Exchange-based mail and a Web-based client for Google's GMail (although, via Google's APIs, I think there's a big opportunity for some whippersnapper AJAX developer to build a better user experience).
The bottom line is that even though many of us are in a dual modality, we are relying more and more on Web-based apps every day. With a little more investment into Web-based apps from companies that are clearly prepared to make that investment, their applications will begin to make us ask if we really need that dual modality or is it time to switch to something that doesn't require such girth, expense, and aggravation on the desktop side. Not to mention the security headaches (which, contrary to urban mythology, are not just on Windows anymore).
Naysayers including some ZDNet readers cite data security as the reason they'll never entrust their personal data to an application service provider. That's not surprising given the number of data breaches that seem to be happening on a nearly daily basis. But at the end of the day, the upward trend in terms of subscriptions to service providers speaks for itself. Ask any salesforce.com user when the last time he or she upgraded their software or had to tweak their registry to fix some sort of corruption, and it isn't hard to understand why. Ask that user's CFO why they're smiling too, and something about getting capital expenses and their associated write-downs off the books could very easily be the first words out of their mouths. Which brings up the next point.
Moving to Web-based applications should be less about overcoming the objections and more about realizing their potential. Looking at the recent Google Spreadsheets announcement (charting not supported), there's obviously some potential for Google's offering as well as other Web-based spreadsheets like Thinkfree's to solve the 80/20 rule where Web-based offerings deliver the 20 percent of the functionality that's needed by 80 percent of users at a significantly reduced if not ad-subsidized free cost. Between the support-simplicity of moving to a browser-based environment (versus the very complex and highly prone-to-corruption fat client), the potential for hard dollar savings, and the extent to which Web-based storage can ameliorate the complexity of insourced file-sharing (and perhaps the need for network operating systems), the largely incremental benefits over a thick-office are indeed compelling. But if you ask me, the questions that get asked when a new Web-based offering shows up shouldn't be about how well the new offering matches the functionality of something like Microsoft Office. The question should be about how the offering may actually represent an advance or quantum leap.
For me, in the area of spreadsheets, WikiCalc represents that sort of quantum leap. WikiCalc isn't about how to acknowledge the Web's shortcomings with an offering that, not-coincidentally, handles the 80/20 rule (or the 90/10, 70/30, or 60/40 rules). Dan Bricklin, the co-inventor of the original spreadsheet (VisiCalc) and the inventor of WikiCalc would probably be the first one to acknowledge that his new creation may only solve 95/5 rule. In other words, it lacks a significant amount of the functionality found in Excel. WikiCalc basically "says" that if Excel defined the 100 percent of functionality by which all Web-based offerings will be judged, that that 100 percent isn't enough and suggests that there may be an additional 20 to 40 percentage points by which all offerings, Excel included, should be measured.
How does WikiCalc do this? Primarily through a steroidal injection of collaborative auditable wiki-juice into the notion of spreadsheets. This is juice that spreadsheets hardly had before. I've already extolled the virtues of wiki architecture here on ZDNet. Even without their amazing collaborative context, wikis (and blogs to some extent) shatter any and all pre-conceived notions that knowledge and information must be encoded in heavyweight document contexts that require heavyweight content management systems (to keep track of that content).
From a collaborative point of view, toss in the support that's typically needed from heavyweight email systems (to pass documents around or issue notifications) and heavyweight "sharing" layers of software that documents (and their authoring tools) must be strapped to (layers like Lotus Notes, Microsoft's Sharepoint, or even "Microsoft's" Groove"), and wiki architectures really start to shine. With the technology that's in place at most businesses today, collaborating and sharing is an unnatural act. It's hardly intuitive and it often feels like you're pushing a square peg through a round hole (despite all the resources that were expended to make it frictionless).
By marrying the DNA of wikis to productivity of spreadsheets, WikiCalc was already ahead of its time, setting the new bar to which most other entries should be judged. But now that the very open source-friendly wiki solution provider SocialText is putting its muscle behind WikiCalc, a serious disruption to the world as we know it should be at hand for a number of reasons. Before hooking up with SocialText, Bricklin was chief bottle washer for the open source-based WikiCalc. During my many phone calls with Bricklin over the last year (most having to do with our common passion for audio recording gear), Bricklin spoke of the interest that WikiCalc was getting from large organizations. But, much the same way those organizations need top flight support for Linux from Red Hat or J2EE from JBoss before they're willing to incorporate those open source technologies into their infrastructures, WikiCalc needed a throat to choke and in SocialText, Bricklin found one.
The alignment between WikiCalc and Socialtext is practically too good to be true. First and foremost, they are both wiki-oriented. The ability for multiple people in an organization to collaborate on or simply view a spreadsheet in the same fashion that typical wikis facilitate the same activity around text and images is quite remarkable. WikiCalc has quite a few other special tricks up is sleeve including the the abilities to accept wiki markup right inside of a cell, to pull data off of other Web sites (like stock data off of Yahoo Finance), and to reference other spreadsheets (for a screencasted demo that highlights some of WikiCalc's coolest features, go here). Second, while there are plenty of open source-based wiki offerings, there are none out there that I know of that provide the sort of support for that IT managers like to subscribe to so they can sleep at night (knowing there's a single throat they can choke if they wake up in the morning to find something broken).
Now, with a recent commitment to open source, Socialtext is one such throat. In a telephone interview just before Socialtext made its WikiCalc announcement, Mayfield told me that Socialtext, WikiCalc, and Wikiwyg (a SocialText-developed WYSIWYG editor for wikis) would all be released under the same open source license as the one used by SugarCRM (It's important to note that even though the SugarCRM Public License is a derivative of the Mozilla Public License v 1.1, it has yet to be officially recognized as an open source license by the Open Source Initiative).
With an existing support infrastructure for supporting organizations in their use of wiki-esque open source software already in place, it's far easier for Socialtext to add Wikicalc to its menu of supported solutions than it is for Bricklin to add an enterprise-support department to his garage. Thirdly, at its very core, Socialtext's namesake wiki is based on Kwiki which is written in Perl. WikiCalc is written in Perl. That's sort of like meeting your soulmate and finding out that his or her favorite food is sushi, just like yours.
Finally, the open source nature of this announcement adds some additional disruptive flair to this announcement that you don't get with announcements like the one about Google Spreadsheets. Notwithstanding any questions raised by the license's lack of OSI-certification, Socialtext's open source intent and gesture brings us full circle to the aforementioned 80/20 business. Due to WikiCalc's open source nature, the opportunity exists for other individuals and organizations to step up to the plate and fill in the blank spots that Bricklin hasn't gotten to yet (and I mean "yet" quite literally -- for Bricklin in his "garage," functionality has simply been a question of time and priorities). WikiCalc's open source nature stands worlds apart from solutions coming out of other providers (eg: Google) of Web-based productivity applications that have been criticized for their functional shortcomings. With WikiCalc, if you see a shortcoming, you're empowered to fix it. And just to be sure, Dan Bricklin is now on Socialtext's payroll, getting paid to make sure his creation lives up to its potential (who says being an open source developer doesn't pay?!!).
In the bigger picture, not only was this move great for Bricklin, but it puts SocialText in a very interesting spot. When I step back and look at SocialText, I now see an open source company, who, like Red Hat, JBoss, SourceLabs, SpikeSource and others, can derive a significant amount of its revenue through the subscription-based support of a very specific open source software stack. Like SourceLabs though, which is one of the few if not the only company supporting the highly specialized (and open source) SASH stack, SocialText is carving a name out for itself as the go-to company for support of an open source wiki stack. Judging by the way Red Hat's recent acquisition of JBoss expanded the scope of the stack supported by that company, it's not hard to imagine a larger open source company like Red Hat, Sun, or Novell rounding out its stack with wiki-based offerings. Particularly when they realize how disruptive wikis can be to the current document and content management regime and what that could mean to their customers and their business.