Step aside Google Spreadsheets. Bricklin's WikiCalc has reinforcements

Step aside Google Spreadsheets. Bricklin's WikiCalc has reinforcements

Summary: 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.

TOPICS: Open Source

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, 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 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). 

wikicalcclip.jpgNot only does wiki architecture have the potential to drive huge amounts of complexity and cost out of knowledge collaboration (and what doesn't qualify?), every byte of knowledge and information that's borne into a wiki-architected system has collaboration already build into its genes.  It's not a afterthought.  The icing on the cake? The wiki-architecture's reliance on HTML (at least from a presentation perspective) equates to a lightweight, easily searchable (and indexable), and widely supported standard.  Ten years from now, when looking back on their expenditures for authoring tools, content management systems, and collaborative infrastructures, I'm fully convinced IT managers will be saying "We spent more than a million dollars per year on what?"  Throw in the audit trail that wiki's natively keep regarding every change (an audit trail that's both easily replayed and sets the equivalent of restore points to which pages can be "rewound") and it just keeps getting better (particularly for businesses under the thumb of SarbOx that, by law, can't "forget" anything).  WikiCalc takes this idea to an entirely new level by individually tracking any change to any cell or range of cells (see partial screenshot, above left, for a sample of such an audit trail).  Wow.

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.

Topic: Open Source

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Were you paid to write this crap?

    "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."

    Are you kidding me??? In over 10 years of support, I can only remember 4 instances where Microsoft office was corrupted. I was supporting 350 desktops at one employer, 80 at another, and currently another 75.

    Simplicity of browser based?

    Both a browser and a "fat" application require patches from time to time.

    Moving files back and forth to some server cannot be more efficient than working with files on your local desktop and saving it to the server before you go home.

    Other than live file sharing, there is nothing here of value that can't be done with citrix/remote desktop.

    In fact you could argue that the mish-mash of code required to turn browsers into spreadsheets or workprocessors is probably worse than the source code for a traditional application.
    • Yawn -- thin clients all over again

      Agsolutely agree. There may be limited use for web applications but broadly speaking it's just the thin client hype all over again in a different package. It just isn't going to happen on a large scale. And it has nothing to do with security. There are two problems: First of all, people like having their own tools. Secondly, it's going to be a long, long time before you can come even close to duplicating the full functionality of major applications on the web. Show me a feature-for-feature identical web version of Photoshop without any memory, capacity or performance hits and I might be willing to reconsider. But until that happens this whole argument is a pipe dream thought up by marketers, who are going to make a killing from the naive investors who are going to get bloody noses once again.
      • Thin, Thick, Rich...

        I believe the new terminology being used here is "rich client." It sits somewhere between thick and thin because it's not just a terminal. It has execution capabilities (like Java), storage capabilities, etc.

        • Sound more like an advertising gimmick..

          Don't change the technology much, but give it a new name:

          "Thin" client (one thinks of: withered client, slight client, shrunken client,...ect")

          While "Rich" client could equate to "prosperous client, loaded client, thriving clien..."
          John Zern
          • not just a gimic

            all of these technologies have their place. i've seen thin clients used to great effect in an education environment, reducing cost to the point where their entirne server farm cost less than most school's yearly lease. meanwhile, they were able to buy top of the line macs for the art and film departments. all of these technologies have their place, including web based computing. i'm more interested purely from the point of trouble free computing fokr mom and pop
    • Answers

      1. I said nothing about "Office" being the thing that becomes corrupted. I discussed fat clients (reference to the entire system.

      2. I'd rather have to patch my browser occasionally than keep track of/patch/manage the 30 or so applications I now run. By the way, the licensing thing is super problematic when switching machines. I've had software that I have a legit license to bomb on me as I try to install it on a new computer. This never happens with browser based applications.

      3. There are companies that like the idea of not having to pay personnel to worry about file servers or reminding people to [b]remember[/b] to copy their files to those servers at the end of the day. The last time I checked in with some ASP customers, they weren't spending too much time worry about the servers running their applications. Or inefficiently (and consciously/manually) copying files.

      • Ok - Good answers

        1) I can accept that. However, there are still a couple issues. Unless you run something that is stored in read-only flash, the "client" can still become corrupted whether by turning off a linux system running ext2, or getting a virus on your XP system. I think any sufficiently robust platform for a web browser will have corruption risk.

        2) If you are comparing strictly workstation-app vs web-based-app, you will have to keep track of paching all the apps. True. However, the citrix/RD /X-windows stuff is off-the-shelf and just as robust without having to re-write any apps.

        3) This point is a philosophical one. If you host the browser-based stuff yourself - OK I agree. But if you "buy" the service of running a spreasheet on some server in another state, no way. There is way too much moving around of data that is putting companies and individuals at risk from data theft.
      • What? Huh? Real world check!

        My rebuttal.
        #1. If proper planning and precautions are taken (and you have a clue) corrupted systems would not be an issue. Also if the "entire system" as you put it was corrupted how would the browser not be affected?

        #2 Licensing...this is a mess due to poor business practices and companies being overly greedy. Yes, I understand they need to be able to collect $ for their product, but it comes at the sacrifice of the product and the consumer. The concept from MS with the OS being a "leased" software license is crap. This tactic is straight from the mainframe book of licensing. The same model MS thwarted in their rise to fame in making mainframe computing obsolete. Make a better product for a reasonable price and people will buy it!

        #3 If a companies employees are manually copying files back to their servers, the entire IT staff should be fired. Any true IT Professional would have employed industry standard tactics to automate his/her users mundane tasks and make this seamless.

        And lastly, I must state that as I approach 20 years in IT (I am only in late 30s), I am amazed that we are about to make the final full circle turn.
        People migrated off of mainframe/dumb terminal technology for more robust client/server and peer-to-peer applications that are much richer and fuller. With the current trend being forced on us, soon we will all be using dumb browser based PCs and will again be at the mercy of the people who control the websites...and yes I do believe in web technology, but it has it place.
      • Thought on answers

        Thanks for the clarifications. Couple of thoughts about them:

        #1 you are implying a thin client is per se overall easier to maintain - hence overall more robust. True not everyone needs all the apps typically found on an average PC. But when it comes to rich functionality I typically need to download more data volume to a local PC just to get some reasonable performance. Does not matter whether that is Java classed, ASP.NET controls or huge JavaScript files.

        Just imagine a future thin client world (use an extreme for a moment where everything is thin client). Then you have a new machine. Do I then go to 20 different websites first to download all the client packs until I am productive again?

        #2 you imply patching is the most time consuming job any private person or corporate citizen is troubled with. It neglects there could be new (yet unknown) trouble of a different kind with thin clients. It neglects there could be advance in today's world. It neglects that both home and office users could have other woes that worry them more and/or cost more

        #3 the idea of outsourcing services is not new. In a company anyone sitting on the money coffer knows investment goes into hardware, client software, corporate application, helpdesk services, etc. Any piece of that can be outsourced - in the traditional sense or in new models. If I did not buy computers anymore, but leased them together with the software portfolio needed in the company I do not primarily worry what software I pay a fee for as long as it roughly meets the needs of my users. In short: I do not think there is a strong monetary incentive to move to thin clients.

    • I agree

      The idea of thin web-based clients being less susceptible to curruption is a joke. If anything, web based apps must contend with the many more variables inherent in a shared environment, and are therfore more like to corrupt. I too have been using Office since 97, and have never had it corrupt.
      I don't trust my data on someone else's server, not just for security reasons, but for reliability. If our system is down, and my boss comes to me screaming about it, I'd much rather tell him I can do something about it than to say "Sorry, salesforce is down again, we just have to sit around and wait".
      This is a big issue:
      companies change hands!
      What if I've spent the last few years creating a score of spreadsheets on some web-based app, what if that company gets bought out, or goes out of business, and stops providing the service?
      Do I just go out of business too?
      Don't think so,
      I'll take my fat client any day.

      And since when is Excel (and lets not kid ourselves, we're talking about Office here, not fat-clients in general) considered legacy software?
  • I would rather have IT out of the way

    I'm an IT guy and have made my living in IT for more than 12 years. Too often IT gets in the way of people being able to do their jobs effectively. We load up the laptops and desktops with so much stuff so that we can command and control the environment that we get in our own way in trying to command and control.

    MS Office doesn't typically corrupt...but now we have to patch the thing nearly monthly (which doesn't always go smoothly)and the licensing of the MS "office system" comes at prices that are growing more and more unreasonable with every update.

    Me, I would rather offer my business different services so I'm out of the way of them doing their job - a rich client looks like a decent middle-ground to explore. I get the service at a reasonable price and don't have to maintain as much on the client and don't have to worry about back-end (and just as problematic) Citrix/thin-client infrastructure. So now my data center is freed up to contain the stuff we don't ever want to see as a service.
  • Not entirely convinced

    The popularity of web-based data is not as broad-based as you make it out to be. There has been growth in <i>specific</i> apps where a web-based solution has offered features not replicated on a desktop. Salesforce is popular because salespeople want to update the data from diverse locations; hotmail grew popular because kids wanted their own mailbox separate from that of their parent-controlled home computer. These are niches, not the generalized trend you claim.

    These particular niches are even more narrowly defined: they are not as vulnerable to the kind of concerns about web-based apps that spreadsheets would be. A list of sales contacts or some kid's email is hardly going to draw the same kind of hacker/espionage interest as GM's annual budget.

    That said, innovation died when Microsoft gained monopoly position with Excel and Word desktop apps and we haven't seen any really new ideas for years. So there's rich opportunity for web-based innovations in these products to tempt some onto the web platform, and perhaps to risk some sensitive data. But not all. I can't see GM's budget ever making it into the wilds, which means that web-based apps will forever be a second-best alternative to the desktop...except where access to the data from diverse geographical locations is a bonus. Even then, I suspect that the big corporations will rely on their private networks and only mid-sized companies will look to the web.
  • Back to the old times, but slightly different?

    I'm in the computer business for a little over 25 years now and remember the days that there was no PC. These web-based solutions resemble the old days: you communicate with a central system where all of the computing power and storage is situated, well looked after by a bunch of operators. Of course it is also very different: graphics was almost non-existent, remote connections were very low speed en expensive, if at all possible.
    I see these developments as very promising and quite sufficient for the majority of the users. It's almost nice to have a hard-disk failure when you know that your data is secure in a big datacenter.
    So yes, with the increasing speed and lowering cost of communication lines, I think this kind of webbased application services surely will gain momentum.
  • You may not pay now but you will!

    When the kinks are worked out, the advertising will start. Oh, I'm sure there will be a "subscription" option to avoid the obnoxious advertising. But once you're hooked, well...

    Anyone remember when withdrawing 20 bucks from an ATM was *free*?
  • what people are used to using

    I'm a college teacher and for us, the thin client, hosted apps which don't cost us much and can be used for our students are obviously better than desktop stuff (I don't teach computer science, I teach writing and reporting.)

    As I introduce these kind of apps to my students, I notice they end up findging new ones on their own and showing them to me.

    When these "kids" get out in the world, I think they will be OS and thin-client consumers. Sure, they will buy specialty software like PhotoShop, but for other work, they will be loyal to their pocketbooks, what works fast, and what let's them be connected all the time.
  • C'mon, everyone [i]else[/i] is doing it [nt]

  • The evolution to client-server-services

    Computer software technology evolves in cycles of 5 to 10 years. Stay in the business long enough and you will see it come full circle...several times. Dan Bricklin invented the first client based (Apple) spreadsheet called VisiCalc and has now built a cool web based spreadsheet called WikiCalc.

    In the past 25 years we have seen evolutions from proprietary main frames, to mini-computers, to personal computers, to client server applications, to web based applications, and everything in between.

    During these transition times there is always a raging debate about which architectural approach, (client, server, or client/server) is better. The arguments are always binary, good vs bad. Rich clients are better. No, web based server applications are the only way to go. The zealots are single minded in their arguments.

    Ray Ozzie has been a major player in several of these evolutions with Lotus Notes and Groove Networks. Today, Ray is CTO of Microsoft and is driving the vision of a blended approach that leverages the best of each architecture in a software continuum.

    I wrote a blog on this evolution and why the blended approach is best. See
  • The Enterprise appeal wasn't obvious

    to me until I viewed the SocialText Pricing.

    The Enterprise version runs on a dedicated server behind the user's corporate firewall with all the usual integration. That would put it on a more even footing with other products.

    It would still pose a major training expense to maintain training for 2 separate products, an office suite and SocialText/WikiCalc.

    The difficulty is that most corporate workers are also in the business of talking / writing / communicating (interfacing :-)) with external clients.

    Every formal document has some "sales" impact, even for government agencies. So formal office suites are an essential part of producing documents that reflect well on the organization. They are part of the sales process.

    WikiCalc and SocialText may be great for internal memos, knowledge accumulation, collaborative work in an enterprise.

    But sooner or later, a "sales" job ("snow job") is needed, even if it's only to sell a budget to finance. Everybody then resorts to bells and whistles office suites.

    The main appeal would seem to be the same as free email services such as Hotmail (just how many paid subscribers do they really have).

    That seems to leave the free/low cost web services battling for the "thin wallet" market sector.