I hate slides, you hate slides, and the military really, really hates slides. Slides are everything Tufte says they are: “presentations too often resemble a school play – very loud, very slow, and very simple.”

But then we all hate taxes too. Barring a miracle or some sort of populist revolt, we are stuck with slides for the foreseeable future. Given this, the question becomes triage: how do you minimize the damage? The answer, sadly, is that it’s not easy.

The options from a presenter’s standpoint can be grouped into three buckets: native clients (e.g. Powerpoint, OpenOffice.org, etc), browser based (e.g. Google Docs, Prezi, etc) and HTML (e.g. S5). None of these options is ideal for my usage.

• Native Clients:
  The mainstream option. Most of you are likely using Keynote or Powerpoint, depending on your operating system of choice. Neither are options for me, as I run neither Mac nor Windows as my primary operating system. Which is no real loss for me, in all likelihood, because while I’ve used Powerpoint extensively I’m not a fan of the product. Like many of its Office brethren, it’s suffering from the weight of years of innovation: there are simply too many bells and whistles, the majority of which I have no intention of ever using. Perhaps Keynote is better, but it’s still a non-starter for me. Which leaves, among the mainstream options, OpenOffice.org’s Impress. Which I want to like, but just can’t. It’s clunky, a few years behind from a design perspective, and is even more difficult to navigate than Powerpoint.
• Browser Based Clients:
  As an unrepentant fan of browser based apps, this would seem like a solid marriage. But they each have their issues, above and beyond the perptual limitation of SaaS apps, offline functionality. Google Docs’ font selection, for example, is terrible [see above]: I’m no typography junky, but six fonts? Really? Prezi, meanwhile, is an innovative tool, but one that falls down on portability. Yes, it has an export capability, but have you looked at the package it exports? I created a test presentation with nothing in it; the resulting exported archive was 18.7 MB, included two directories and a 4.3 MB *.exe file. No thank you. Zoho, meanwhile, while a bit more generous with the font selection – 19 to Google Docs’ 6 – still didn’t have my preferred Helvetica Neue. I’ve also had some issues with image uploading and manipulation in the past.
• HTML:
  Every so often I consider switching to straight HTML based slides, a la S5 or Slidy. But then I imagine walking up to one of those harried, possibly-competent conference A/V guys, handing him a memory stick, and saying “No, actually, it’s not a PDF or PPT, it’s a self-contained HTML file, just fire it up in the browser, you’ll be fine!” And then I don’t consider it any more. I present off of my own machine whenever and wherever I can, but there are a great many times when that’s not possible, practical or both. So whatever I’m using has to work on someone else’s machine, and easily.

  Throw in the fact that many HTML formats require a working knowledge of stylesheets – where my abilities are more generally described by, “Ok, let’s refresh…wow, no, that didn’t work at all…” – and the HTML presentation options aren’t a great fit for me.

Which leaves what, exactly? Not much. My friends from the Clutter team have recently pointed me at Pinpoint [see below], which I may experiment with if I can get it to export to PDF (even after installing Cairo 1.10, it’s balking).

Others have pointed at HTML5 based options like 5lide, but that’s far too restrictive to output the kind of slides I like to deliver. Nothing I’ve looked at yet is ready to replace OO.o, then, a tool I actively dislike. None of this would be a big deal if we didn’t have to prepare so many presentations. But we do, and so I’m desperate for a tool that I like using, or at the very least, don’t hate to use. Here’s what I’m looking for:

• Export:
  The tool must export to – at a minimum – PDF. ODP/PPT are nice to haves, but PDF is non-optional. Any tool whose export involves a *.exe file is disqualified.
• Features:
  As a presentation tool, it should be able to create a presentation. Meaning incorporate text, graphics and, I suppose, audio and video easily in a presentation capable format. Inline integration with credible clip-art or stock photo libraries would be excellent.
• Fonts:
  You have two choices: come with lots out of the box, or let me add my own.
• Markup (HTML, etc):
  Is acceptable as an authoring mechanism, whether it’s HTML, Markdown, Pango, etc. Packages requiring even rudimentary CSS skills are disqualified.
• Network:
  Any presentation tool that assumes network connectivity is disqualified. Simple as that. The first rule of presentations is that you cannot rely on the network during a presentation.
• Offline (browser):
  Offline authoring for the browser based tools would be ideal, because many of my presentations get written or at least tweaked on a plane. It’s not a must have, however.
• Operating System (native):
  The tool must be either cross platform or Linux compatible.
• Opinionated Sofware:
  Best case, the tool is opinionated. I don’t want a tool that is going to encourage me to produce a few dozen slides of bulleted lists; I want a tool that encourages me to think creatively about what my presentation. Prezi’s got that part down, at least.
• Pretty:
  Lastly, the tool should be pretty. Pretty is a feature, remember.

What about you? What do you use to create your presentations?

IBM Project Vulcan, originally uploaded by ed brill.

It’s easy to view the recently previewed Project Vulcan from Lotus as the Facebookification of Notes because, well, it is. In the waning years of the last century in particular, the Lotus enterprise collaboration suite looked it, lagging significantly the next generation collaboration user interfaces evolving, daily, on the web. But midway through the ought’s or whatever we’re calling it, the folks from Lotus began expanding their horizons, taking their cues from the web. The first product manifestations of this design evolution were Connections and Quickr.

Project Vulcan continues this trend.

But to dismiss it as merely a pretty face, a gussied up nod to the Gen-Y crowd flooding the workplace, misses the point. Under the covers, IBM is attempting to solve the same problem that anyone with an email account these days has: volume. Or, by extension, attention, referring to the time required to process said volume.

There’s no need to rehash the specifics of the systemic attention deficit. There might not be an app for that, but we do have a generally accepted definition of the condition. In addition to being a massively successful social network and the connectivity fabric for a couple of hundred million people, Facebook is part of the problem. The Facebook primary News Feed, for example, becomes increasingly unusable with each “friend” you add. Manageable at first, each additional contact becomes an input. These inputs, manageable individually, are problematic in the aggregate.

But consider the problem faced by those that would transition that experience to the workplace. If I lose the latest pictures of a “friend’s” kids or an account of their vacation amidst the noise of Facebook, it’s a pity. If I miss, on the other hand, an action item from my boss or a customer request in my Inbox, that’s a potential crisis. But it gets worse. Facebook, for the most part, is charged with handling little more than text and photos. That won’t work in an enterprise context, where businesses need the ability to collectively track everything from calendar to email to office documents to Twitter.

This might be, in other words, one of those cases where consumer simplicity genuinely isn’t enough for enterprise usage. Business apps can and do have far more bells and whistles than they need, but Facebook by itself just isn’t enough.

An enterprise Facebook clearly needs to be able to consume a variety of assets. Further, it needs to help users effectively manage that firehose, by any means necessary. Of those two, I would submit that it’s the latter that’s the real challenge. Google or Zoho, for example, offer tools that permit users to collaborate on presentations, share calendars, and the like. But who’s helping users triage their extended inboxes?

There are startups like Gist – who announced a partnership today with IBM, perhaps not coincidentally – and Threadsy attacking the space, but the short answer is that no one yet has a good solution to the over-hyped but very real problem of information overload. IBM included, Project Vulcan or no.

But of the firms with an eye towards attention management, IBM has perhaps the widest array of assets to bring to bear. They have the table-stakes collaboration pieces, as well as some interesting experience in the synchronization and federation of persistence mechanisms (think Notes databases or, more recently, CouchDB), whether that’s done client or server-side. All of which is interesting. What’s more so is their analytical expertise, from Cognos to IBM Research.

We know IBM sees analytics as vital moving forward, because everyone from Ambuj Goyal to Steve Mills have said as much. You don’t bother to create college curricula, after all, if you don’t need the people. Desperately.

In Vulcan, we may see why analytics are at a premium. For all the benefit of methodologies like GTD, the solution to the information overload problem will be algorithmically derived, because it must be. We can only ask the likes of GTD for so much; at 34 GBs per person, per day and growing, something has to give. What that is is likely to be determined, ultimately, by an algorithm. We’ll be using analytics, in other words, to tell us what we don’t need to pay attention to. It won’t be trusted at first, but that’s a problem for another day.

The idea of marrying analytics to collaboration is not new – I’ve been asking for it since 2004, actually – but its time is almost at hand. Vulcan could be the first implementation for the enterprise, if not the masses, slated as it is for a 2011 release. But it will certainly not be the last implementation. Whether Lotus gets it right or not, we’re all going need more analytics, all the time. Collaboration being no exception.

Don’t be fooled, then: Vulcan is more than an enterprise Facebook. It’s analytically assisted collaboration, and thus one to watch.

Disclosure: IBM is a RedMonk customer, as are competitors such as Microsoft and SAP. Gist, Facebook, Google, and Threadsy are not RedMonk customers.

“Why would a virtualization vendor acquire a messaging provider?” asked a customer of ours last week when the rumors started. With the deal now official, we have answers from both VMware and Zimbra, but as I tend to think there’s more to it than “adding to the portfolio of partners,” I thought I’d take the time to answer a few questions on the deal for all of you.

Q: Before we begin, anything to disclose?
A: Definitely. Neither VMware nor Zimbra are current RedMonk customers, though we know people with both firms well. Competitors of the two, on the other hand, including IBM and Microsoft are current RedMonk customers.

Q: Now, for those that missed it, can you rehash the announcement?
A: Yesterday, VMware announced that it had entered into the proverbial “definitive agreement” to aquire Zimbra, an open source messaging and collaboration provider, from Yahoo. The deal was expected to close in Q1 of 2010. Yahoo, remember, had previously acquired Zimbra in September of 2007 for $350 million dollars.

Q: Were the financial terms disclosed?
A: They were not, but AllThingsDigital’s Kara Swisher reported that the transaction price, while over $100M, would be shy of the $350M Yahoo paid three years ago?

Q: So is this merely a buy low opportunity for VMware?
A: I’m sure that’s a component of the decision, because even at a $350M valuation they would be acquiring it at a discount considering that $350M two years ago is worth morth than $350 million today, and that’s without taking into account the fact that Zimbra’s paid accounts have balooned to 55M (according to VMware – they were ~44M back in April) since the transaction. But to answer the question, no, there’s a lot more to it than buying low.

Q: What then is the primary motivation for the transaction?
A: An analyst colleague, Forrester’s Ted Schadler, in a piece for ZDNet, says “it’s about the seats, and I think that’s partially correct. It’s about the seats, yes, but really it’s about who’s controlling those seats. Zimbra’s strength from an account perspective has always been service provider types; it’s not clear what percentage of the tens of millions of seats are sold through the likes of Comcast and NTT Communications, but it’s safe to assume that it’s substantial. Which are, not coincidentally, precisely the type of customers VMware needs to realize its lofty cloud ambitions.

Q: How does Zimbra help?
A: Well, put yourself in VMware’s shoes. You effectively own the still growing virtualization market, but growth is far from assured due to the commoditization of the virtualization technologies at the low end, the sublimation of virtualization into the operating system (e.g. RHEL, Windows, etc) at the high end, and the increasing attention virtualization management is receiving from the high end IT management players – remember this ad? So what do you do? You look for opportunities for growth. Expanding your footprint, and thus your share of enterprise dollars, as VMware did previously with SpringSource – and as Red Hat did with JBoss before them – is a good place to start. But considering that Maritz is a Microsoft veteran, you have to assume he’s thinking bigger than incremental, sustained growth. He knows, first hand, that true margin comes not from platform success, but from platform dominance.

In spite of their best efforts, however, VMware has yet to totally disintermediate the operating system – and thus own the platform – for the general server market. True, VMware’s share is massive and everyone’s got tons of Linux and Windows running on top of VMware, but the operating system providers still exert control by virtue of their status as ISV target.

What if, however, there were a market where the operating system was already highly abstracted? Where, in some cases, it was completely obscured via the frameworks layered on top of it – frameworks we now call Platform-as-a-Service?

Q: So this acquisition is about the cloud?
A: I believe so, yes. Zimbra, by itself, does little to advance these ambitions. Sure, their application portfolio is now that much more complete with the addition of a very credible, open source collaboration platform. But the real key, to me, are the customer relationships Zimbra has established with just the sort of people VMware is going to want to talk to as it looks to own the cloud.

Q: What sorts of people are those?
A: The Comcast kind of people. If I was VMware, the day the acquisition closes I would have my new, joint sales team out talking to every service provider’s CEO about a bleak, dystopian future in which the service providers own nothing, and have been reduced to dumb pipes that exist to shuttle data and workloads from one Amazon datacenter to another owned by Google. I would be asking every application host that Zimbra’s currently working with how they expect to compete with providers like Amazon or Rackspace that can out-innovate them in cloud infrastructure. And I would be telling all of them that we, VMware, can help you.

Q: But is the account access worth better than a hundred million dollars?
A: If it helps advance VMware’s cloud ambitions, which could be core to the future of the company, yes, easily. Because the marginal value of that access is different for VMware than it was for, say, Yahoo, who harbors no such platform ambitions. And besides, it’s not as if Zimbra’s unable to sell the product; quite the contrary, from all accounts. So the initial cash outlay could and should be easily offset by the improved sales that will naturally result from having an established direct sales force.

Q: And there’s the Java angle…
A: Indeed. VMware’s an enterprise technology vendor, enterprises prefer and subsequently advantage Java, hence the Java bet on SpringSource. Zimbra fits, in that respect, both from an internal resourcing standpoint and in terms of its external customer messaging. Which is not to say that VMware would not have acquired Zimbra if it was written in, say, PHP. But the acquisition logistics and hurdles would have been more significant, certainly.

Q: What does this acquisition mean for customers?
A: James thinks it’s good for them – he even found a happy one on Twitter – and I mostly agree. While Zimbra made sense as a Yahoo technology acquisition, it was never a good fit for the established business model. As is amply demonstrated by Yahoo’s lack of commitment to the direct sales resources necessary to competing effectively in an ever more competitive collaboration market. VMware, whatever else may be said about it, understands the process of selling to and supporting enterprise customers. So from that standpoint, it should be an improvement.

That said, I could see VMware being far more aggressive with pricing than Yahoo ever was, or Zimbra before them. At least in an unbundled fashion; those who purchase virtualization as well are likely to see significant discounting.

Q: Can VMware handle this very different business, or are they likely to be distracted?
A: We’ll see, but I suspect it won’t be a problem. SpringSource, a materially distinct business from VMware’s core virtualization product line, didn’t really force them off message at VMworld this past fall.

Q: How about a question from the audience, one from Karsten Wade: how does the M&A benefit the open communities whose work is bundled in Zimbra?
A: As a company whose relationship with open source – at least prior to the SpringSource acquisition – is complicated, the Magic 8-Ball says “Ask again later.” At the very least, the projects could benefit from potentially wider exposure (I’m referring to pieces like nginx and Sieve, clearly, rather than MySQL), and it’s probably beneficial that they are in markets not material to VMware but very much so to some of its competitors.

Q: Is there a play for VMware parent EMC in this acquisition?
A: Possibly, though EMC has traditionally done an admirable job of being hands off with its virtualization wunderkind. Zimbra, while optimized to minimize storage costs, could still drive substantial additional storage revenues if it makes large inroads into VMware’s existing customer base.

Q: Anything else to add?
A: No, we’d be here forever. If you’re a customer, give us a call and we’ll walk through the implications for your business.

“The only thing we know about the future is that it will be different.” – Peter Drucker

So let’s do some predictions, shall we? True, I dislike the entire business of prediction, close cousin that it is to guessing. Which I hate. But James’ excellent thoughts on what we might see in the year ahead got me thinking about what I’m anticipating.

Maybe we see over the hill imperfectly, but the following assertions are not without their substance either. Feel free to take them with a grain of salt, several grains, or not at all. We’ll see how we did a year from now.

One thing to keep in mind about our predictions: we’re looking a bit further out than, say, Gartner. Where they are predicting that cloud computing will a strategic technology for 2010, then, we instead consider that a given. So if you’re looking for predictions like, “open source will be a mainstream option,” you’ve come to the wrong place: we figure you know that already. It doesn’t mean that Gartner’s wrong, of course; merely that we’re having an entirely different conversation.

Cloud API Proliferation Will Become a Serious Problem

When I meet with cloud providers these days, the default answer to questions about the openness or lackthereof with respect to their software is “we have an open API.” But this is, unquestionably, the wrong answer for customers. It’s not that open APIs are bad, individually: far from it. You’d rather have one than not. But how are customers to manage them as they multiply? Cloud providers should be considering Kant’s Categorical Imperative:

“Act only according to that maxim whereby you can at the same time will that it should become a universal law.”

Unsurprisingly, however, they are not. Which means that cloud API proliferation will reach new, frightening heights in the year ahead. Or maybe you want to individually review and compare the APIs as they iterate. Watch the Deltacloud project for traction as a result; platforms with an API compatibility story like Eucalyptus should benefit as well.

On a semi-related note, I expect IaaS to remain more popular than PaaS for 2010.

Collaboration Will Never Be the Same

Google Wave was quite a splash when it landed; Mozilla Raindrop far less so. Or so says Google Trends. But both will play an important role in the fundamental reshaping of the interfaces – and in the case of Wave, infrastructure – that we all use to collaborate in the year ahead. Nor will the impacts be limited to the early adopter market those products are aimed at. As James noted, Lotus sold 1M licenses of its Connections product in two weeks to six customers. The appetite for next generation collaboration toolsets is strong, whether we’re talking about Rogers’ innovators or laggards.

But all of that may end up being the least interesting trend we see from collaboration in 2010. Of potentially greater impact are those that go beyond the interface. Github, for example, strongly incents social coding and cross pollination in ways that change the way development is done. Offerings like Gist and Threadsy, meanwhile, take a business intelligence-like approach to email, attempting to both consolidate multiple streams and process the content algorithmically according to its inter-relation. Message from your boss? Important. Someone you hear from once every two months? Less so. Neither are ready for primetime, by my testing, but they point the way forward.

And collaboration will never be the same.

Data as Revenue

I’ve written about this fairly extensively already, so I won’t belabor the point. But we’re going to see datasets increasingly recognized as a serious, balance sheet-worthy asset. Twitter pointed the way with its Bing and Google deals, and then Infochimps reinforced that value by making available, commercially, data they harvested from everyone’s favorite micro-blogging service.

This will continue. I’m fully in agreement with IBM’s Steve Mills when he says that we’re “moving into an era of information led transformation.” As margins slim and economies continue to stagnate, enterprises of all sizes will increasingly turn their eyes to data based assets, both for their latent commercial value as well as for improved decision making.

As a result, fear and concern over the privacy implications will spike.

Democratization of Big Data

Yes, Facebook and its 24 terabytes of new content per day is an outlier. But what about the individual developer that wants to make sense of the 1.7 GB Twitter dataset that Infochimps is making available? OpenOffice.org, as I can personally report, doesn’t want anything to do with it.

Fortunately, the democratization of big data is well underway. Hadoop puts MapReduce within reach, Pig puts Hadoop within reach, and with the Cloudera desktop you even have a nice, shiny browser based GUI. Throw in Amazon, and you have as many machines as you could possibly want. We’re still a little light in the front end space, with the ability to visualize the data lagging far behind the ability to process it, but that will come. Maybe in the next year, maybe not.

But either way, the ability to work on big data will increasingly be available to any business, large or small. Democractization of Big Data, commence.

Developer Target Fragmentation Will Accelerate

Between cloud fabrics, programming language proliferation, mobile application development and the spike in development framework popularity, development targets have been fragmenting for several years now. We are more or less in full retreat from the one time promise of write once, run anywhere as an industry. I see nothing on the horizon that will throttle or even slow this trend; if anything, the increasing volume of cloud platforms and the surge in interest in mobile development will accelerate this trend.

This has significant implications for purveyors of middleware, application development tools and cloud platforms, but also for those charged with setting enterprise technology standards. The CIO’s job is going to get harder in 2010, because picking a winner from the myriad language, framework and platform options will be much more difficult than picking a safe option.

It’s All About the Analytics

Flowing Data, a blog run by PhD candidate Nathan Yau, is one of my favorites. The visualization of data is as much an art as a science, and there are few practitioners more talented. The challenge of taking data and hammering it into a form that conveys meaning and supports conclusions is, of course, an age old challenge. But the tools at our disposal are getting better, fast.

Consider the simple analytics that are available, for free, to virtually anyone today: Google Analytics for the web, Feedburner for feeds, Bit.ly for links, About:Me for the browser, Flickr Stats for pictures and so on. Emerging services like PostRank will even extend that value by consolidating various streams into a meaningful, single glance assessment of performance.

I’ve never subscribed to the idea that only what can be measured can be managed – open source, in particular, belies that claim – but there’s no debate that metrics can be immensely important in maximizing returns, and to an extent, profits.

We’re going to see analytics become, as James said, ubiquitous to the extent that they’re not already. Two projects to keep your eyes on in this space, both from IBM: the chronically underleveraged ManyEyes, and the Hadoop-backed M2. Both could – should, in my view – be important at advancing the state of analytics forward in the next year.

Marketplaces Will Be Table Stakes

Why has it taken so long for the idea of marketplaces to catch on? Don’t look at me; I’ve been banging on about them since 2006 or so. The equation has long seemed like a no brainer to me: developers and ISVs get a centralized channel and wider audience, platforms get a wider ecosystem, and customers get a more efficient discovery and acquisition process – at a minimum.

Whatever the initial reluctance, that’s over. Two plus billion Apple iTunes store downloads later, mobile players are falling all over themselves to roll out marketplaces to compete. Canonical, sponsors of the Ubuntu project, are moving towards their own software store (though, regrettably, it still doesn’t include developers as I’ve hoped for). Amazon, meanwhile, has most of the pieces it would need to sell apps, and a sustained rate of innovation that is more or less unmatched in the industry at present.

What does 2010 hold, then? Marketplaces, and a lot of them. Mobile is quickly becoming staturated, web apps and the desktop are probably next, and data marketplaces may ultimately eclipse them all. If you want to play next year, bring your marketplace. Or go home.

New Languages to Watch

Seems like we have a new hot programming language every year. Some are in it for the long haul, some fade away, and some linger in between like the undead. I’m not prepared at this point to call the winners for the next year, but two that a.) might lend themselves well to cloud and cloud-like environments and b.) are receiving disproportionately more attention relative to their erstwhile competition are Clojure and Go. The former is essentially Lisp reborn on top of the JVM, while Go borrows from C syntaticly but adds in modern language conveniences such as garbage collection without taking too much of a hit performance-wise (Go is 20-30% slower than C/C++, reportedly).

It seems unlikely that either will make significant inroads at the expense of the currently popular compiled languages such as C#/Java or the dynamic alternatives (PHP/Python/etc), but the level of attention – and the people paying attention – distinguish them from other languages aimed at concurrency like Erlang and Haskell.

NoSQL Will Bid for Mainstream Acceptance

Maybe the NoSQL label is a misnomer, and maybe Michael Stonebraker is right that NoSQL has nothing to do with SQL. Either way, I am not ready to predict that the NoSQL moniker will retired in favor of, say, AltDB.

What I will claim, however, is that projects in this space will individually and collectively make serious bids for mainstream acceptance. Cassandra, CouchDB, InfiniDB, MongoDB, Riak, Tokyo Cabinet and the like – different as they all are from one another – will position themselves not as relational replacements but complementary technologies that solve a different set of problems.

While I don’t believe the bid for mainstream acceptance will be successful generally – enterprises are too wedded to the RDBMS model, the tooling for the NoSQL projects is generally weak, etc – they will find a fertile ground in areas illsuited to the traditional relational, row-based model.

So that’s my nine. As a bonus, five predictions for free and open source software:

FOSS Predictions

1. Usage of dual licensing will continue to decline, in part because of the Oracle and EU dispute over MySQL
2. FOSS advocates will increasingly turn their attention from licensing to the related mechanisms of copyright and trademark
3. Permissive licensing will continue to gain at the expense of reciprocal licensing, albeit slowly
4. The value of project code will be eclipsed, in a few cases, by the data the project generates
5. Open source, building from its mainstream acceptance, will emerge as the most credible alternative to proprietary cloud and mobile platforms

But that’s just what I’m seeing. What are your predictions for 2010?

Update: Nat Torkington’s done an excellent follow up that looks at the opportunity side of the above: highly recommend you go read it.

Disclosure: Basho (Riak), Canonical, Cloudera, IBM, Oracle, Sun (MySQL) are RedMonk customers. Apple, Google and Mozilla are not.

Assuming that people actually use it for piracy at all, which I personally haven’t seen. But hey, there are better than two million of us using the software these days, so statistically it’s probable that there are some bad apples.

For the rest of us, Dropbox is a drop dead simple, cross-platform application synchronization client. One that Just Works. Now, before you start, I know what you’re going to say. You’re about to say this:

For any advanced techie, the three main reasons (Backup, sync, sharing) for using DropBox are irrelevant. For ordinary users: sure! It sounds like a great solution.

Let me explain.

I don’t think anyone with valuable data would trust their only backup with an external “in-the-cloud” source. On top of that, most people’s upload capacity is severely limited.

Syncing is accomplished with rsync or a network share on your home network. Most geeks will SSH into their home computers, etc. Sharing via drop box cannot be any better than a personally managed web server. GIT/SVN on your server offers much more than drop box can. On the other hand, maybe I just like to hack and get my hands dirty creating my own solutions.

To which I would reply just as JesseAldridge did:

Have you tried DropBox? The app is so damn easy to use it’s ridiculous. Sure there are other ways to do it, but the absolute lack of headaches makes Dropbox way better than those other techniques you suggested.

No hyperbole involved. Seriously. Dropbox is stupid easy. I still employ rsync and related tools for odd jobs here and there, but Dropbox is so low effort that I honestly have to justify not using it. You can replicate the functionality, but you’re not going to match the user experience, let alone the speed, on your own. Watching the changes you make on one machine instantly reflected on another with zero intervention on your part is magical, I assure you.

Of the three core services, I don’t really use sharing, so I can’t comment on that. I’m sure it’s useful. Dropbox’s backup and synchronization, on the other hand, are fundamental enablers of my day to day technology usage. First, the simple stuff.

Backup

Backup is probably the most straightforward use case for Dropbox. You can take files or directories and either drop them into your Dropbox folder, or create symlinks out to them from there. Here’s how to do that. Items that I back up – using the term loosely, as there’s no versioning, etc applied: my Ubuntu repositories list (etc/apt/sources.list), a list of the packages I have installed locally, the directory containing my writing, a subset of my music, my Tomboy notes, and more.

But to be honest, backup just isn’t that interesting. Lots of services can do that. What’s compelling about Dropbox, really, is the synchronization element.

Synchronization

This is where things get cool. If you’re wicked geeky, that is. It’s nice, of course, to have web based backups of your files: it was a godsend the last time I fatally damaged my .emacs file. But it’s nicer to have the various configuration files that make your desktop your desktop seamlessly pushed to every machine you use. Which, in my case, include a Windows 7 laptop, an Ubuntu laptop and workstation, a Mac Mini and an iPhone.

To explain what I mean, here’s how you create and share a .bash_aliases file with all of your bash equipped machines. The following, please note, assumes that you have a primary workstation and secondary machines, as I do.

• If you have a .bash_aliases file already, great, keep going. If not, create one now on your primary workstation with something like nano ~/.bash_aliases (note: you have to activate this by uncommenting the three lines beginning if [ -f ~/.bash_aliases ]; then in the ~/.bashrc file).
• Change to your Dropbox directory: cd Dropbox.
• Create a symlink to the .bash_aliases file: ln -s ~/.bash_aliases .bash_aliases.
• Assuming that your Dropbox instance is active and that your network connections are good, it should only take a few seconds to populate that file on all secondary machines.
• Moving to your secondary machine, change to the home directory: cd.
• Create a symlink to the .bash_aliases file in the Dropbox directory on the secondary machine: ln -s ~/Dropbox/.bash_aliases .bash_aliases.

Congrats, you’re done. What you did was create a single real .bash_aliases file that gets symlinked first into Dropbox and then into the ~/ directory on the target machine. In practical terms, it means that any aliases you create on the master will henceforth execute perfectly on the secondary machines.

I use this for my .emacs and the requisite *.els, my .fonts directory, my Tomboy notes, and with the failure of Weave I’m even contemplating doing it to my .mozilla directory. And when it comes time to purchase a new machine, Dropbox will be the grease that gets me moved in and up and running quickly.

Security

Am I concerned, as some are, with security? Marginally. I don’t use it to store anything particularly sensitive, although I think that’s just common sense. The Dropbox folks have done a better job of late, I think, articulating just how they go about protecting your data.

What Would I Like to See?

Frankly, less of Dropbox. And I mean that in a good way. I’d love to see Dropbox baked directly into applications. Media players and photo managers would be logical first candidates, but how many applications would not benefit from fast, real-time file system awareness and synchronization?

Until then, however, I’m a very happy, paying customer of the service. It’s certainly come a long way from its days as a candidate for Y Combinator, and I wish it well in future.

It’s been a long time since I’ve had any real vacation, so as of tomorrow I’m on it. Tomorrow, the weather gods willing, the lawyer and I will be making a quick trip to Denver for a friend’s wedding, but as of my return Sunday, I’m going to be doing nothing for an entire week. Except for working on the wedding website, I mean. And, in all likelihood, spending some time on the water.

So while I scurry to tidy up a few loose ends before I leave you all to the dog days of August, here’s a grab bag of items that might deserve their own entries but aren’t getting them.

Backtype and the Extended Conversation

Backtype, for those of you that haven’t looked at it yet, has rapidly become one of the most valuable WordPress plugins I employ. By automagically identifying and integrating the linked mentions of WordPress entries on services like Identi.ca and Twitter, I – and anyone else visiting – get a much better sense of the tone and scope of a given conversation. There are some things that still puzzle me: the BackType link will often list more Twitter mentions than the plugin integrates as comments, but for the most part it works perfectly and without any manual intervention.

One of the least surprising insights gleaned from the usage of BackType? Pieces dealing with open source and related issues generate a far higher percentage of comments on Identi.ca than Twitter.

I, For One, Welcome Our New Facebook Overlords?

While we await the imminent arrival of the desperately needed iPhone Facebook app 3.0 – 2.0 is just abysmal – another, different application is giving us a glimpse of a more Facebook-centric web. The unfortunately named feX is simple in its ambition: it merely synchronizes your Facebook contacts with those held locally on your iPhone. Meaning that all of those “So-and-so has update their mobile number and it’s been added to your addressbook” messages aren’t so useless anymore. This is a win/win, right?

Well, that depends on what you think of Facebook. To some, they’re a necessary centralization for contacts; the inevitable critical mass that’s the 21st Century equivalent of the Whitepages. To others, like Val Aurora, they’re effectively setting up a second, walled off internet. Which is, to put it mildly, a problem.

Wired had a nice piece on the differing visions Facebook and Google have for the web, which included this snippet:

Today, the Google-Facebook rivalry isn’t just going strong, it has evolved into a full-blown battle over the future of the Internet—its structure, design, and utility. For the last decade or so, the Web has been defined by Google’s algorithms—rigorous and efficient equations that parse practically every byte of online activity to build a dispassionate atlas of the online world. Facebook CEO Mark Zuckerberg envisions a more personalized, humanized Web, where our network of friends, colleagues, peers, and family is our primary source of information, just as it is offline. In Zuckerberg’s vision, users will query this “social graph” to find a doctor, the best camera, or someone to hire—rather than tapping the cold mathematics of a Google search. It is a complete rethinking of how we navigate the online world, one that places Facebook right at the center. In other words, right where Google is now.

Personalized and humanized sound like such nice words, and there is truth to the assertion that in many cases I’d prefer to be directed by someone I know. But at the heart of the matter here are questions of ownership, privacy and economics: Facebook’s valuation, at least to some extent, is built on its collection of data. The trouble is that the users – quite understandably – tend to think of that data as theirs, not Facebook’s. My prediction, like many other’s, is that this is inevitably going to result in a showdown over user rights versus the economic model Facebook is built upon. We’ve seen signs of this already, with the user-photo-advertising controversy. But that, as they say, is just the tip of the iceberg. Wait till that extends to messages, news updates, and more. Hell, Facebook may even be getting its own browser soon.

In the meantime, feX shows what a Facebook backed future looks like, and to be honest – privacy and ownership questions aside – it’s pretty nice. No longer do I have to update phone numbers, contact photos and so on: all of that is copied direct from Facebook.

Personal Metrics

I mentioned previously that David Ascher – CEO of Mozilla Messaging – kindly took a few minutes at OSCON to demo for me a little Jetpack enabled plugin to Thunderbird that provided him with some basic, but singularly insightful, metrics on his usage of that client. Fortunately enough, I was recently pointed to the Firefox equivalent: the about:me plugin. Though it will only work if you’re on a Firefox >= 3.5, it’s a neat little automated way to learn more about how you use your browser, and thus about your daily habits.

“What would email look like if we set out to invent it today?” – Lars Rasmussen, via Tim O’Reilly

In spite of substantial evidence that it’s at best a mixed blessing, the world outside of technology largely celebrates tradition. Even as humanity moves forward, we actively look for ways large and small to anchor ourselves to our past. For better and for worse, the answer to “Why do we do things that way?” is usually “Because that’s how they’ve always been done.”

The technology industry, on the other hand, is far less warm and fuzzy about that idea, even as it is similarly beholden to that which came before. Tradition and related terms like “legacy” are little but a pejorative in our world, spat out about products that have, in their antiquity, become the the very burden they were designed to relieve.

All of which is a long winded way of explaining just why I think Google Wave is so interesting: it’s not legacy. Rather than mimic the traditional channels like physical mail or telephony, Wave is a deliberate and clean departure from the past: it’s a complete rethinking of the way we communicate today. Which is why it should fail, but might not.

When I took a look at IBM’s Jazz product a few years back, I said the following:

If application development had been invented after Ajax, Bazaar/Subversion and instant messaging it would look a lot like Jazz.

Whether you agree or not with that assessment vis a vis the Jazz product is immaterial here, because it’s the concept we’re after: the idea that it may periodically useful to fundamentally rethink the evolution of one product in light of the development or invention of other seemingly unrelated products. While I personally both hate and fear them, if evolution worked differently, bats would be excellent examples of this: what happens if you rethink what a small mammal can be, in light of the invention of wings and sonar?

For perhaps a more useful example, consider mobile phones, which become dramatically more interesting – and different – once cameras can be shrunk to a certain size, touchscreens are available, wireless data networks become broadband-like in their bandwidth, suitable processors reach reasonable speed thresholds, and battery life will support all of the above. What is a phone in light of those external developments?

We’re beginning to find out. Meanwhile email is, like sharks and crocodiles, largely unchanged from an evolutionary standpoint. Which is why Wave was built, of course.

We don’t see a lot of dramatic leaps forward in software, I’d argue, both because it’s exceedingly difficult to develop and launch revolutionary products and because the economics act against it. It’s difficult, of course, to produce them: how many vendors can afford the indulgence of turning high quality resources loose on a multi-year project with no clear revenue plan in place? But it can be even more difficult to market sell them, because, well, they’re not what people are used to and they take some explaining.

As the task of explaining new technologies is kind of our job, as analysts, let’s do a quick Q&A on some of the questions we’re getting about Wave. Because I was unable to do San Francisco/San Francisco/Alaska in consecutive weeks, I couldn’t make Google I/O and thus don’t have a Wave account, but I’ve been through enough of what’s available to answer at least a few high level questions.

Q: For those that missed it, what are the basics of the Google Wave news?
A: The Google folks, in announcing Wave, consider the product in three pieces: product, platform, and protocol. I’d probably collapse the first two, in that the product itself is inherently a platform, with all of the attendant benefits (and cautions). The protocol, for many, is the really interesting piece, in that it’s open in the sense that it’s documented, if not from a participation standpoint. In a manner of speaking, it’s a new hosted collaboration server product with a new documented protocol.

Q: Is Wave vaporware?
A: That depends on your definition, but according to mine it is not. The product is not publicly available, but it does exist and is supporting alpha users at present. Further, the protocol is both defined and documented. So this is more than smoke, mirrors and promises at this point.

Q: What did that mean above, “new hosted collaboration server?”
A: That’s the tough part to define. To help, I’d recommend checking out either the Google Wave keynote from I/O, or more simply, Andy Ihnatko’s piece, “Google Wave is genius, but will it work?”. Both will give you a hands on look at Wave, which collapses the distinctions between IM, email, and documents seamlessly. Indeed, it challenges basic conceptions of what’s a document and how it’s worked on, hence the invention of the new term “Wave,” which I, for the record, don’t love.

Q: How does it challenge ideas of what a document is?
A: Even absent Wave, the definition of a document is evolving rapidly. Simply put, the traditional notions of what consititutes a document are rapidly becoming obsolete in a variety of settings. Here’s how I’ve described the transition in the past:

Documents today can have, as IBM’s Doug Heintzman noted last Wednesday at IBM’s annual analyst event, more in common with a web page than the document you or I might have authored a few years – or a year – ago. Parts of it might be static, parts of it might be dynamic, but each of those parts might arrive from separate, external sources of record. The days of static documentation are drawing to a close, thanks to innovation – finally – in an area that should have seen it years ago.

While we at RedMonk are so far out on the bleeding edge that we can’t even see the mainstream when it comes to our own work habits (though not our coverage, hopefully), it’s nevertheless worth noting that I really don’t create documents at this point. Customer, expense and other operational spreadsheets are kept in Google Docs, and frankly they’re more webpage – even database – than they are spreadsheet at this point. At no point in their lifecycle, generally, are they transmitted as ODF, OOXML, or PDF: I can’t honestly remember the last time I exported one for the purposes of sending. When we need to collaborate with an external party, we simply share the asset. Even the pieces I author for this space are documents only in a nominal sense. Each is composed in emacs, then pasted to WordPress. There, it is reforged as an entirely different asset, pulling in pictures, videos, or other embedded assets, all while collecting comments, trackbacks, and revisions to become something new and distinct.

Is that a document? I’d argue not.

Wave, in many respects, can be seen as aggressive embrace of this transition. The word “wave” itself can be considered, in a sense, as a drop-in replacement term for the increasingly archaic “document.” As Google puts it, “A ‘wave’ is equal parts conversation and document.”

By exploding the notion of a document and how it’s created, Google frees itself from some of the strictures that traditional office productivity vendors must adhere to in service of their respective markets. Whether that will lead to market success is yet to be determined, but it certainly gives them more flexibility in attacking an increasingly dynamic space.

Q: And what of the document creation process? How has Google abandoned tradition there?
A: Google and other SaaS vendors like Zoho have long enjoyed an advantage in this space, in that documents hosted online are easier to work on in collaborative fashion. Anyone who’s coauthored documents using Google Docs realizes this. But Wave takes this concept further by eliminating the barriers between collaborative channels around the document; documents can be collaboratively constructed in real-time or asymmetrically using instant messaging like presence and commenting, all of which is captured and becomes, effectively, a part of the document…er, sorry, Wave.

Q: Doesn’t that introduce tremendous versioning challenges? Constantly updated documents are, after all, potentially problematic in real world settings, not to mention compliance?
A: There is no question that we’re all going to have to adapt to the idea that the days of static documents are, for all intents and purposes, nearing an end. We’ve seen this coming for years, of course, which is why we’ve seen the rapid evolution of everything from distributed version control systems like git and Mercurial to syndication formats designed to alert us to changes in content. So yes, versioning is going to be a challenge.

But there are two things mitigating the issue. One, Waves can, of course, be snapshotted into particular documents or formats. So you can, for example, produce from a collaborative process a one time report, memo, whatever that will have a predictable and non-dynamic lifespan. More interestingly, however, Google Wave understands inherently the challenges of this process and offers a Time Slider-like ability to walk backwards through the history, revisisting not just the changes and change history, but the evolution of the Wave itself.

Q: Is this type of group collaboration and multi-artifact incorporation a new concept in the collaboration space?
A: Very few things are developed in a vacuum, and Wave clearly is no exception. We’ve seen similar efforts like this from Groove – since acquired by Microsoft – and more recently IBM’s Lotus, with its notion of Activity-centric Collaboration. Wave borrows heavily, in my view, from both Groove/Microsoft and IBM in its reimagination of what the collaborative process should look like.

Q: So what’s the difference between Google Wave and those efforts? Groove never hit the bigtime and ultimately exited via acquisition, while the Lotus’ Activity-centric collaboration hasn’t exactly broken the hold of email centric workflows either?
A: Maybe nothing. But in a couple of key areas, Wave has some advantages:

1. The Cloud:
   One of the difficulties, at least in the last version of Groove that I used, was that the technology was ahead of the hardware. The type of seamless, multi-party real-time collaboration Wave aims to achieve is (or was) computationally challenging; even on brand new Thinkpads, Groove was borderline unusable for me prior to its acquisition. Google, as it has in other arenas, offloads this workload to the server, ensuring that the client hardware is not a limiting factor (and cementing its business model simultaneously).
2. The Cost:
   Unlike Groove or Notes, Google Wave will be free and therefore – by definition, will have the opportunity at addressing a wider market.
3. The Protocol:
   While both the Groove and Lotus products spoke in standardized protocols like SMTP, the secret sauce of their collaborative ability was never – to the best of my knowledge – fully documented and exposed, thereby opening opportunities for third parties and allowing at least for the possibility of a surrounding ecosystem. Not to mention the ability for enterprises to host their own implementations that don’t sit on Google servers.

   More, as Joe puts it:

   The difference is that the extension model with Wave is events over HTTP, which makes it language agnostic, a feature you get when you define things in terms of protocols. That is, as long as you can stand up an HTTP server and parse JSON, you can create robots for Wave, which is a huge leap forward compared to the extension models for Notes, Exchange and Groove, which are all “object” based extension models. [Note: Sam Ruby doesn't necessarily agree].

   Not that the protocol is perfect, of course.

Q: Let’s look at the protocol some more: is it really open?
A: The answer depends in part on where you’re coming from with respect to open protocols, but the short answer is no. It is open in the sense that it’s documented, but there are two primary issues which challenge that definition. First, there’s no external participation in the direction of the protocol at this point: “The committers for the Google Wave Federation Protocol project are currently all from the Google Wave engineering staff.” The plan is for that to change, apparently, but at the current time the development cannot be considered open. Second, there are – as is all too common – undocumented aspects to the API and the protocol itself. Much of the success or failure will depend on Google’s ability to make the entire stack as transparent as possible, top to bottom.

Those criticisms notwithstanding, is it a step in the right direction? I think so.

Q: Do you think that Google Wave is open enough to encourage third parties or competing vendors to participate?
A: It’s too early to say, and there are many variables that will play a role in the adoption of lackthereof of Wave beyond the Google firewall. But I did find Zoho CEO’s Sridhar Vembu’s comments from a piece talking about Google Wave and Microsoft Silverlight interesting:

That brings us back to Google: today, it is Google which is driving web standards forward. That is why we at Zoho are firmly aligned with them, even if they are our primary competitor. We believe in an open web, there is plenty of opportunity for all of us.

While not promising anything specific, they at least indicate a willingness to work with Google on the subject, which is quite the accomplishment, considering that Google aggressively competes with Zoho.

Q: What about the claims that Google Wave means that HTTP is dead?
A: Not sure I followed them, really, given that the Wave Javascript libraries, anyway, leverage HTTP pretty heavily, and that as Joe puts it, “the extension model with Wave is events over HTTP.” It’s true that XMPP is given a leading role in Wave, but as I have for some time, I see this as purely different tools/different jobs. And even if we forget all of the above, the fact is that HTTP is so fundamentally embedded into the fabric of the internet that its place is guaranteed for years to come.

Q: Is Google Wave open source?
A: Not yet, at least. As Lars Rasmussen told Tim O’Reilly, the intent is there: “To encourage adoption of the protocol, we intend to open source the code behind Google Wave.” But that hasn’t happened quite yet, so the answer at present is no.

Q: So considering all of the above: what does Google Wave mean for established office productivity vendors like IBM and Microsoft?
A: At present? Not much. Same for the near term. Considering how much pushback enterprises have had about a mere reskinning of an existing product in Office, the idea that Google will have substantial immediate success in pushing such a radically reshaped authoring proposition on a conservative market is laughable.

Over the mid to long term, however, it represents a potentially serious competitive threat. For years one or both vendors have effectively defined the office productivity experience, from collaboration to document authoring. And while, as discussed, both have experimented with radical reconsiderations of that experience, neither has had much success driving significant change into the mainstream. If Google Wave is successful, it will mean that Google will be the vendor defining the next generation experience for millions, potentially tens of millions of users, worldwide. Next to that prospect, the threat of Google Apps is but a trifle.

We’re already seeing enterprise collaboration vendors struggle to adapt to generational shifts in the workplace, as older retirees are replaced by young, tech savvy graduates. They’ve also grappled with the increasing importance of simpler, SaaS offerings and the threats that tools from Facebook to Twitter may pose. Wave, in many respects, is a far more grave concern than any of those, so fundamentally does it target what has traditionally been the province of high cost enterprise productivity tools.

So while there’s a long way to go between here and there, and success is far from guaranteed for Google’s latest product, Wave is one to watch.

Disclosure: IBM and Microsoft are RedMonk customers, while Google and Zoho are not.

So we had this ice storm you may have heard about. It was kind of a big deal, with hundreds of thousands of households without power and so on. But while not having power, heat or running water is what we in the business might term suboptimal, there’s always a silver lining to be found.

Quite literally, in some cases.

Besides that Big Picture rip off, however, there’s the opportunity to turn this storm into a learning opportunity. As was repeatedly stressed by Central Maine Power’s President Sarah Burns during her appearance on Maine’s NPR affiliate yesterday.

As a current CMP customer with some small expertise in the collaboration/social media space, and – as of Saturday – an expert in gasoline generators, I thought I’d post some public ideas on where and how new mechanisms could be employed alongside of or as a complement to the old to improve the process of information dissemination.

Because that was, to my mind, the real problem. The folks in Alfred that are still without power might beg to differ, of course, but the actual loss of power is like a sunk cost: it is what it is. Unless the entire power grid could be put underground, and lord knows this state could not afford that, you’re going to have outages. That’s a fact of life. It’s unfortunate, and the state and CMP need to do what they can to proactively minimize the damage – cutting back tree limbs and so forth – but there’s only so much you can do about an inch of ice.

While that’s outside of CMP’s control, however, how they communicate with customers is not. And while I give full credit to the CMP and other out of state crews who did magnificient work under trying circumstances, the communication process around their efforts was far less consistent.

Burns, in yesterday’s appearance, claimed that CMP’s position since Saturday had been consistent: the company was targeting a full restoration by midnight on Wednesday. Which is interesting, because in spite of the fact that I visited CMP’s website over the weekend, read the papers, listened to the radio and called CMP’s toll-free emergency service number, I never heard anything about Wednesday’s deadline. Nor had two of the other callers into the NPR program. Which illustrates the problem: communication.

CMP had information, many (all, in my experience) of those affected by the outage did not. This asymmetry is not, as I’ve heard it argued, due to the inevitable difficulties of predicting precisely when the power would be restored. No one expects that, particularly in the aftermath of a storm such as this one that left downed lines strewn all over the state like worms after a rain. None of the folks I spoke with were looking for restoration predictions accurate to the minute, the hour, or even – really – the day. But we were all curious as to the approximate timeframe: were we talking hours? days? weeks? what?

This information, apparently, was known as of Saturday, but no one I knew of had it. Nor, as nearly as I can determine, did the Portland Press Herald. Tracking the storm stories, I see no mention of a Wednesday date. So if we didn’t know, and the Press Herald didn’t know, who did?

Rather than beat this dead horse further, let’s simply agree that the communication process could stand for some improvement.

What would I do, were I working for CMP, to better communicate the status of restoration efforts going forward? Several things. Call it the shotgun approach: between downed power lines and uneven broadband and cellphone penetration, the key is reaching out through as many channels as possible. This ensures the latest information and data can make its way to the widest possible audience. You’ll miss people, of course, but that’s unavoidable: the trick is getting the word to as many as possible. Door to door, as we saw in this storm, is an adequate last resort, but it scales exceptionally poorly.

Particularly when the ground is icy.

Instead, each update – and if I were CMP, I would try to update hourly, or at least on a predictable, regularly scheduled basis every few hours, the following channels:

• 211:
  The informational equivalent of emergency’s 911 needs better visibility to go with more up-to-date information. This should be an alternative direct line to the latest and greatest information with respect to the outage status.
• IVR (AKA CMP’s Toll-Free):
  This was, sadly, basically unhelpful during the outage. Aside from the ability to report outages, the automated IVR system was as unable to connect callers to actual humans as it was to provide basic information on the status of the recovery efforts. The best you could get – at least as of Saturday – was an automated recording that would look up your account (by account or phone number) and provide you with a long list of the other towns experiencing outages. Which didn’t help much. Like 211, this should have included a predictably updated status report with a description of ongoing efforts as well as – as soon as it became available – expectations for outage lengths.
• General Stores:
  One suggestion I haven’t heard yet was to assemble a roster of the general stores, community centers or even coffee shops and bars that serve as the de facto town hubs in rural towns like Georgetown. Obviously it’s not going to be possible to call each and every resident affected with the news, but even the most rural of communities has some sort of establishment that links residents to each other. Providing these, at least, with up to date information on progress, estimates and so on would go far to addressing the problem of information dissemination. Assuming, of course, that you’ve created a roster of such facilities in advance of the storm.
• Radio/TV:
  I’m not quite sure how CMP worked with – or did not – the mainstream media outlets of both radio and TV during the storm, but the Channel 6 radio feed (88.7 FM, I think) was as uninformed of CMP’s progress as I was during the peak of the storm. They covered the total numbers of affected households, had comments from the Governor and so on, but nothing that I heard in the way of specific information for affected regions in terms of when they could expect their power to be returned. This seems like a major lost opportunity.
• Twitter:
  What use would Twitter have for a state that is heavily rural and non-technical, you ask? Well, perhaps little. But there is nonetheless a sizable contingent of Twitter users here in Maine – all the major papers including the Press Herald – are on the service, as is – shockingly – the Maine state government. The latter’s storm related Twitter output? Notices about the state offices being closed; nothing about services available to residents, nothing about recovery information, and nothing about alternative information sources. I’m not going to argue that Twitter is the avenue to reach the bulk of the Maine population, but as it’s so low effort, why not leverage it?
• Website:
  Much was made of the CMP website during the initial hours of the outage, but frankly I found it terribly uninformative. While it might not have been a high priority, given that most Mainers probably were not in a position to visit it without power, even had they been able to, it wouldn’t have told them much. As pictured, the primary information returned – just as with the IVR – was which towns were reporting outages. That’s not useless, but it doesn’t tell me much about what I can expect in my own town. In past years, when I’ve actually been able to speak with CMP customer service representatives during outages, they haven’t been able to promise exactly when my power would be returned, of course, but they could at least provide a timeframe. And during a storm like this, when it would be impossible for CMP to field all of the inbound calls, it would seem imperative that the organization utilize a scalable approach like the website to impart at least some of that kind of information.

Do the above channels carry risks and introduce new problems? Certainly, the “telephone” process of garbling messages being exhibit a.

But it’s hard to see how some information could be more damaging that the complete absence of information, which spawns rumors like the predictions of “two weeks” that I was hearing Friday night. No one is asking that utlities overpromise on restoration schedules that they may or may not be able to deliver to, but when they do have solid information to communicate to the public, it would be nice if they actually used all of the channels at their disposal for doing so.

Bad news being, in my view, always preferable to no news.

One of the most interesting byproducts of the transition, fully underway around the world, to XML based document formats from binary alternatives, is the ability to treat the asset as a container of items rather than a discrete item itself. Both ODF and OOXML allow applications to manipulate the contents of assets that were previously opaque at a minute, granular level, even as their respective proponents would doubtless argue their respective superiority at that particular game.

For those of you – and there are one or two at least, I’m sure – that are not office format wonks, here’s the English translation of the above: the files that you today produce in Excel, Powerpoint, or Word can now be carved up, dynamically reassembled and presented. Annual reports can contain continually updating economic data, mortgage applications real-time interest rates, or – nearer and dearer to my heart – baseball scouting reports, moving performance data.

Documents today can have, as IBM’s Doug Heintzman noted last Wednesday at IBM’s annual analyst event, more in common with a web page than the document you or I might have authored a few years – or a year – ago. Parts of it might be static, parts of it might be dynamic, but each of those parts might arrive from separate, external sources of record. The days of static documentation are drawing to a close, thanks to innovation – finally – in an area that should have seen it years ago.

While we at RedMonk are so far out on the bleeding edge that we can’t even see the mainstream when it comes to our own work habits (though not our coverage, hopefully), it’s nevertheless worth noting that I really don’t create documents at this point. Customer, expense and other operational spreadsheets are kept in Google Docs, and frankly they’re more webpage – even database – than they are spreadsheet at this point. At no point in their lifecycle, generally, are they transmitted as ODF, OOXML, or PDF: I can’t honestly remember the last time I exported one for the purposes of sending. When we need to collaborate with an external party, we simply share the asset. Even the pieces I author for this space are documents only in a nominal sense. Each is composed in emacs, then pasted to WordPress. There, it is reforged as an entirely different asset, pulling in pictures, videos, or other embedded assets, all while collecting comments, trackbacks, and revisions to become something new and distinct.

Is that a document? I’d argue not.

The closest I come to creating documents, at least in the traditional sense, is in Impress – the OpenOffice.org Powerpoint alternative. This I use to create the presentations I deliver at conferences, customer events and the like. The presentations tend to be discrete, unevolving assets that I “share” simply by posting them to the web. We do reuse presentations (occasionally) and slides (frequently) within RedMonk, but for the most part presentations are not living documents in the way that a customer spreadsheet is.

But that’s the exception to the rule, which is living assets, and it’s driven primarily by technical limitations. Limitations that I hope are removed. Soon.

For us then, settling on the definition of a “document” is problematic, because it reflects a lifecycle and a lifespan that are, at best, antiquated. Much, if not most, of our output is collaborative, rather than singularly authored, and most of it has a life expectancy far beyond any of the Word documents I authored in my capacity as a systems integrator. Particularly the content that lives on the web. A document, for me, has become a snapshot of the real, living asset, rather than an asset in and of itself. If our Google Doc’s spreadsheet is the Platonic ideal, the ODF capture of it is merely the shadow on the wall.

Which begs the question: are we creating documents, really, anymore? What does document mean in a networked, composable, and programmatically manipulable age? Or perhaps your natural inclination might be – like mine – to view the above as splitting hairs, a pointless, unresolvable debate of semantics.

Whatever my natural inclination might be towards such questions, however, my considered opinion is that the question matters. Maybe a lot.

Not to me, personally. First, because as mentioned, I live on the cutting edge and I’m not terribly relevant relative to the average office user of today, or maybe three to four years out. But more because I’m in a position to realize how documents are evolving, and what they might be capable of if we can get creative. The terminology is not going to have much bearing on what I think of a given technology.

Not everyone is so lucky, however.

As I see it, the danger in continuing to call the content we’ll be creating – using a rapidly evolving set of tools – over the next few years “documents” is that it will stunt the imagination. An example: when I was approached, years ago, about attending the ODF Summit, I had to explain in detail why I believed that messaging (email) and collaboration (wiki) vendors should be included in thee discussion. So tight was the focus on an “office productivity” format, it was non-obvious even to some ODF experts that wikis might, at some point, become consumers and producers of ODF.

The term document, in my view, is a legacy term, and as such, it brings with it preconceived notions of what a document is, should be, and can be. My concern, then, is that these preconceived notions end up predetermining the perceptions of what the assets are capable of.

To be sure, we should not – must not – try to reframe the traditional definition of a document. For those mainstream folks that will make up the bulk of the user population for the foreseeable future, their definition of what a document is is set, and it would be folly to try and change this.

But neither should we let that definition carry forward, tainting more capable formats with the legacy of its limited capabilities. No, we need a new definition or term, I believe. Something more accurately descriptive, and yet non-threatening. Database? Too intimidating, too misleading. Web page? Likewise. Container? I don’t love it.

So I don’t have the replacement term worked out yet: sue me. That doesn’t change the fact, in my opinion, that we’ll need one.

And if the format advocates have their way, probably soon.

cool sky

Originally uploaded by sogrady

Been a long, complicated week here at the home office. Some highs, some lows, the usual.

The good news is that it’s Friday, the Sox are on TV tonight, and I don’t have to get on a plane tomorrow morning. In other words, I have no complaints.

Baseball is Back

Per our original contract, the majority of my baseball related musings have been banished from this space, relegated to my own little Sox corner of the interweb (it’s hilarious to be back on a site that measures traffic highs in the dozens . As an aside, I’ve actually been a bit surprised at how much easier it is to maintain a second site. While I’m sure that resolve will be tested over the months ahead, it’s been fun so far.

But anyway, as documented on Twitter, yesterday marked the first competitive games for the Sox this season – using the term competitive somewhat loosely, as the opponents were Boston College and Northeastern, respectively. The second contest was broadcast via WEEI – available to me via the interweb at redsox.com – and was a soothing balm to an otherwise rough week.

Tonight, however, is the real deal: the Red Sox, on TV, versus some actual professionals. I’ll be at the Pour House for the ballgame; you should be too.

More on Twitter

The Times’ motto, as I learned at an early age, was all the news that’s fit to print. The implicit distinction, of course, being drawn between all the news that’s fit to print and all the news. As I’ve discussed before, while I’d never try and dictate how others use a service like Twitter, their views on what’s fit to print – or Twitter, as the case may be – invariably colors my own willingness to subscribe or not.

What’s interesting is that there are actually a few people that agree: I’d believed that I was a lone voice in the wilderness on the subject.

As Alex puts it:

Twitter could be vastly improved if they simply changed the question from:

What are you doing?

to:

Say something interesting.

A statement that I, personally, agree with. As does Rafe.

Again, the point is not to attempt to impose some half-assed form of censorship on Twitter or its users, but rather to explore the nuances of a flexible and widly divergent medium. Also, to explain how I personally determine the types of streams I choose to subscribe to.

To Lease or Buy?

In the O’Grady family, we were raised to own cars rather than lease them. My parents, and more or less all of my aunts, uncles and grandparents all bought cars and drove them until the end of their practical lives. Which often was years after the last payment had been mailed. At any given time then, only a couple of people in the family were driving new or nearly new cars, but the rest of us were free of the payments which characterize the first few years of ownership and the entirety of a lease period.

While I’m content to drive a car more or less until it’s on its last legs however (and, to own the truth, have a hard time giving them up even at that point), the same cannot be said of a laptop. At RedMonk, we try and target machines for something along the lines of two year lifespans.

This insistence on newer hardware made me consider something I haven’t before: should we be leasing our laptops rather than purchasing them? Eventually I’ll have my brother run the numbers and see what the math looks like, replete with fancy NPV calculations and so on, but in the interim I’m curious as to whether or not any of you would recommend one approach or the other. Are there significant limitations to leased machines that I should be aware of?

Whither Dodgeball?

One of the downsides to putting your audience before yourself while Twittering is the need to throttle entries that are pertinent only to a select audience. On an isolated basis, there’s no issue: like many, I regularly will reply to an audience of one using an @ tag. But it’s not something I’m comfortable doing multiple times per day, every day.

Thus potential use cases such as informing my Denver Twitter contacts that I’m having lunch at McCormick’s or beers at the Pour House can’t be anything more than sporadic mentions here or there, according to my self-imposed rules.

As a result, my initial inclination was to build a separate interface on top of WordPress just for the use cases I’m talking about, but then I considered the fact that Dodgeball was built explicitly for this purpose. Though neglected by Google and abandoned by its founders, the service is indeed still up – which surprised one of the folks I invited.

The early returns are not promising, though they’re unquestionably jeopardized by the fact that most of the Denver folks are out of town this week. It’ll be interesting to see, however, whether Dodgeball can pry its way into the behaviors of the Twitter addicted. Because I’m not terribly eager to wait for Twitter to add support for groups.

Anyone else using services to easily and frictionlessly connect groups, whether geographically colocated or otherwise?

Why SSD?

Upon hearing that I’m likely to purchase at some point in the future – whether it’s now or in the August timeframe – a Lenovo X300 – several folks have asked me why I intend to purchase a device with an SSD, which is not only a relatively new technology but one commanding a significant premium.

At this point, there are three reasons I think the expense is justified, at least for my requirements:

• No Downside:
  This is actually a lie, due to the one exception I’ll get to in a moment, but Flash technology is generally one with little to argue against it. No moving parts is good. As is the lower heat. As is the lower power consumption. As is the silent operation. As is higher performance. And so on.

  Flash drives will unquestionably evolve significantly in the years ahead, adding capacity and lowering prices, but even now they offer immense benefits to users.

• Ok, The Downside:
  I don’t mean price in this case, because that’s to be expected for a new technology in high demand. You can choose to pay the premium, or you can choose not to. No, I’m referring instead to the limited storage capacity of the drives at the current time. Come August, Apple, Dell, Lenovo and others may be offering models with SSD’s that exceed 64GBs in capacity, but right now that’s about as big as they go.

  But fortunately, I’m well prepared for that: my current machine – a Thinkpad X40 – features a 40 GB drive. Seriously. So the primary downside, to me, is quite manageable given the constraints I’ve been operating under for several years now. It won’t be for many, of course. But between my inclination to favor SaaS clients over client applications and the fact that my primary storage concern – music – has always been a desktop play, I could survive on 64 GBs with no issues whatsoever.

• The Performance:
  In the NotebookReview guys’ tests, the SSD equipped X300 was beaten soundly by a non-SSD MacBook Air model in a processor test that forces the machine through recursive mathematical calculations. As would be expected, given that the former features a dual-core Intel chip running at 1.2 Ghz, while the latter brings with it a dual-core 1.6 Ghz processor.

  What was interesting, however, was the subsequent benchmark that tests not just the processor, but memory, hard drive and OS. In that test, the X300 reversed the previous results, besting the MacBook Air by a significant margin. Largely due to, one suspects, the inclusion of the SSD (which, it should be noted, is an option with the MacBook Air). The question I’ve had, then, is not whether the SSD’s would be faster, but rather how much faster they’d be for real world usage.

  If Wil Shipley is to be believed on that point (thanks to Alex for the pointer), the answer is significantly. Witness the following:
  

  SSD’s love context switching, as well. Having an SSD is a lot like having 64GB of RAM in your machine. Sure, I’m going to lose in a Photoshop filter race with your machine, but I’m going to crush you switching between the 15 applications I have open right now. Again, it’s not a surprise to say that if video editing or cutting-edge video games is your primary purpose, you’ll probably find the MacBook Pro faster. But if you’re writing software or just snurfing the web and running lots of apps, this machine is faster.

  Given that I have a dual Opteron workstaion for the video encoding, but use my laptop primarily for surfing the web, writing, and having a dozen plus applications open at a time, the SSD certainly seems like a worthwhile investment.

Anyway, that’s my justification, so don’t burst my bubble.