Blogs

Redmonk

Things the Grandchildren Should Know

In the 36,393 tracks that Last.fm has listened to me play since I originally signed up for the service four years ago yesterday, the Eels are the second most frequently played act. A distant second to Pearl Jam, it’s true, but still: to be the second most frequently played act in better than 35,000 selections has to count for something.

I mention this because it might have bearing, as everything that follows is a commentary on the memoir recently published by the band’s lead singer, one Mark Oliver Everett, better known in some quarters as Mr. E, or just plain E. We’re big on disclosure around here, obviously, so should you choose to discount this review because you suspect I’m biased, well, I won’t hold it against you.

Promise.

Mark Oliver Everett, besides being the frontman for my second favorite band, is the son of Hugh Everett III, a theoretical physicist of some reknown. The originator of the Many Worlds interpretation of quantum mechanics (don’t ask me to explain it: as Niels Bohr said, “If quantum mechanics hasn’t profoundly shocked you, you haven’t understood it yet”), Everett the elder’s brilliance in his field of choice was, unfortunately, considerably offset by his deficiencies as a parent. And while his mother tried, the reality was that Everett the younger’s childhood was nasty, brutish and short.

Nor did things materially improve as time passed. His sister loving, but troubled and schizophenic, bounced from bad situation to bad situation, eventually dying by her own hand in 1996. To be followed shortly thereafter by his mother, who was felled by lung cancer in 1998. Which left Everett - fragile himself - the family’s improbable sole surivor.

Things the Grandchildren Should Know is at once his effort to document - in a modest, self-deprecating fashion - this arc and, I would argue, forgive his parents in the process. As a work of literature, it leaves something to be desired. As a triumph over circumstance, and an act of redemption, it’s profoundly moving.

As family histories go, Everett’s is tragic. Well this side of, say, Mikal Gilmore’s, as chronicled in his brutal work, Shot in the Heart, but tragic nonetheless. Like Eggers‘ manic magnum opus, A Heartbreaking Work of Staggering Genius, Things the Grandchildren Should Know tells the story of an artist robbed of even an average upbringing. But unlike that Eggers’ work - despite its brilliance - Everett’s own memoir is unrelentingly unpretentious and self-effacing.

While Everett’s prose cannot be compared to Eggers’, Things the Grandchildren Should Know resonated far more deeply with me in part because of its innate comprehension that pain and loss are merely the flip side of the coin that buys happiness and life. Tragedy may marked long stretches of Everett’s life, but he was successful in not allowing it to define him, or worse, sink him. Unlike some of his contemporaries - Elliot Smith most notably - Everett had just enough armor to transcend his scattered childhood and absent family to become one of the more successful, and yet independent, acts going. Not to mention one of my favorites.

Though it’s downplayed, Everett’s ability to see the silver lining is impressive: all the more so given his history. At times, as the Amazon review notes, the book is borderline mundane in its recitation of tour details, but the thread is never lost amidst the anecdotes of a touring artist. Nor is it self-indulgent; it’s an act of catharsis for the author, clearly, but readers are likely to find it as accessible and as important.

Still, the most touching aspect of the memoir might not be his ability to impart the unsourced optimism that ultimately eclipses his loneliness, but his capacity for forgiveness. While many of us will let the mistakes of the past poison the present, Everett successfully came to terms with his parents’ flaws, and Things the Grandchildren Should Know is as much an act of forgiveness as McCourt’s Angela’s Ashes or O’Neill’s Long Day’s Journey Into Night.

Don’t read Things the Grandchildren Should Know for the quality of the writing - Everett, in my view, is a better songwriter than he is an author - but do read it if you’d like to have your faith in humanity renewed. That Everett emerged from his childhood at all is playing with house money, that he can say that he’d do it all it again is singularly unique, in my eperience.

Popularity: 1% [?]

by-nc-sa

links for 2008-12-01

Popularity: 1% [?]

by-nc-sa

links for 2008-11-30

  • "The only reason I go after Christian fundamentalists and New Atheists is because they're here and I'm an American. Fundamentalism — whether it's Hindu fundamentalism or Jewish fundamentalism or Christian fundamentalism or Islamic fundamentalism — is the same disease. Karen Armstrong has explained that brilliantly. Fundamentalists, no matter what their religious coloring — bear far more in common with each other than they do with more enlightened members of their own religious communities. I'm an enemy of fundamentalism, period. "

Popularity: 1% [?]

by-nc-sa

links for 2008-11-28

Popularity: 1% [?]

by-nc-sa

links for 2008-11-27

Popularity: 1% [?]

by-nc-sa

links for 2008-11-26

Popularity: 1% [?]

by-nc-sa

What Would SOG Do?: Views on Sun

Following Sun’s announcement last quarter, the tenor of the inquiries we received about the vendor changed, and changed dramatically. Post-earnings, and subsequent to the announcement of a 18% reduction in headcount, third parties and media types alike shifted their focus from the firm’s products to the firm. What was to become of Sun?

The firm is no stranger to questions about its future, of course. As one of the beneficiaries of the dot com boom, it was punished disproportionately for that implosion. Until that point, the organization was a high flyer that could do little wrong, with its operating system the enterprise standard and its workstations - the basis for its old ticker symbol, SUNW - an iconic piece of technology.

That the road from there to here has been rocky goes without saying. The question now is simple: where does the organization go from here? This entry, like Tim’s that inspired it, is one attempt to answer that question. Given that I am not privy to the machinations of either Sun’s board or its large institutional investors - in whose hands the fate of the firm rests - the following should be considered an editorial, at best.

As is my wont, I’ll conduct this discussion in my typical fashion, as a Q&A. If there are questions that you think I’ve missed, feel free to submit them afterwards, though I may or may not be able to answer them.

Q: Before we begin, do you have anything to disclose?
A: Certainly. Sun is not only a RedMonk customer, they are one of our longest tenured clients, as well as one of the most committed - historically, anyway - to the RedMonk cause. I also know and respect many of the firm’s employees, from Jonathan Schwartz on down.

Q: Would you like to preface your remarks at all?
A: Indeed. There are several caveats to be aware of, among them:

  1. Context:
    While the following is obviously a commentary inspired by a series of poor showings from the firm, financially, Sun still has a few billion in the bank, and to take their run rate down, they’re losing almost one in five people. It’s also presumably the case they won’t be paying for MySQL and StorageTek every quarter. The following commentary, then, should be taken in the spirit it’s intended: as constructive suggestions for those mapping Sun’s future - not a sky-is-falling obituary.
  2. Cuts:
    I, like many others commenting on the subject, will recommend that Sun decommit from certain assets. This is, obviously, easier said than done. First, because some of the businesses are generating some cash and involve customer commitments. But also because some of the recommended activities - transitioning OO.o to a foundation, for example - are actually more expensive in the short term.

    You should read the below then as a set of general guidelines, rather than an “everything must go, and go now” mandate.

  3. Numbers:
    I don’t have them all, obviously. So it’s difficult for me to say with precision what Sun should and should not do with its various assets. That said, the following are what I believe to be reasonable assertions based on the available evidence and my experience covering the firm.
  4. Products:
    I’m generally in agreement with my colleague when he says that Sun’s product catalog is as strong as I’ve seen it. It probably sounds weird to hear that about a firm that is currently being bludgeoned by the market, but take a look around. MySQL is the volume database, the x86 line is a growing business, storage has been reinvented first with Thumper and now with Amber Road, and Solaris - still - is technically differentiated. Having good products is not Sun’s problem.
  5. Share Price:
    While many of the analyses I’ve seen of Sun recently focus on its share price - understandably, given its current levels - I believe that to be an extremely imperfect metric for the performance of a firm. As defense of that claim, I recommend checking out MSFT’s 5 year share price fluctuation: that, for a firm that is, effectively, a mint.

Q: On a macro level, what are the potential outcomes for the firm?
A: As with any entity in a similar position, there are multiple possibilities. The most likely, in no particular order, are these. First, they remain a viable, ongoing concern following the planned streamlining or rightsizing of their business. Second, they are acquired for their assets. Third, they are acquired by an entity strictly for the purposes of selling their assets. Fourth, they burn through their remaining cash and are no longer viable.

Q: Which of those possibilities is most likely? Can you provide odds?
A: That, in many respects, is the $64,000 question. Unfortunately, I’m in no position to collect the cash: I cannot predict with any certainty what the future holds for Sun. Not strictly because I abhor the business of prediction generally, but because the answer depends on data that I do not have at this time. We know they are cutting 18% of the workforce, for example, but I’m not privy to the details of where the cuts are coming from, and what if any products are being cut. Ergo, I am unable to speculate with any degree of certainty how the firm will perform going forward.

Q: How did Sun get here?
A: That’s a complicated question, one that cannot be answered simply, or in the context of an entry like this. I will say, however, that some of the difficulty stems from Sun’s culture, which is engineering driven.

Q: Can you explain?
A: Certainly. Engineers, as the cliche goes, are driven to innovate first, and seek markets second…if at all. This behavior, in many respects, has come to characterize Sun. Like the fabled Xerox Parc - though, fortunately, with more business savvy and commercial success - Sun’s culture is engineering dominated. Innovation is valued, to the extent that under McNealy’s watch, necessary headcount reductions were postponed in search of game changing innovations. This culture stands in stark contrast to other businesses in the industry.

IBM, for example, is in many respects the polar opposite of Sun. While it is no slouch in the area of engineering and innovation, the firm is intensely business model oriented - at the expense of engineering, if necessary. This approach has its costs: by prioritizing immediate profits, subtle or more difficult to perceive markets are either ignored or not properly leveraged. Think operating systems and web search, two markets that IBM could have dominated, but failed to demonstrate the opportunity for immediate profit.

Sun, on the other hand, has long funded innovation for innovation’s sake. When it appeared to everyone else - myself included - that further investments in Solaris were a waste of time and energy, the firm doubled down. And was rewarded, from this point of view, with a highly differentiated, if still regrettably inaccessible (though that condition has abated), product. Similar investments in tooling, on the other hand, have yielded innovation but little obvious opportunity. As we’ll get to later. Their valuation of their own technology, as well, has led to an occasional NIH complex, which poses its own challenges.

Q: So you believe that Sun should become more like IBM?
A: Based strictly on the financial performance of the two organizations, it’s fairly clear that Sun could learn something from IBM, yes. But frankly, so too could IBM learn from Sun. The point here is not to advocate one approach at the expense of another, but to recognize that both have their time and place, and that an organization that is dominated by either an engineering or business model culture is likely to be one sided. Ideally, both cultures are leveraged and applied in a balanced approach.

That’s the goal, anyway.

Q: Do you subscribe the conventional wisdom that assigns the blame - either all of it, or part - to Sun’s CEO, Jonathan Schwartz?
A: I do not. The first time I met Jonathan was in a Boston hotel room along with some of my ex-Illuminata colleagues, as he took the reins of the software organization. He impressed me then with his intelligence, insight and pragmatism, and I’m not of the opinion that his intelligence has declined since that time. I have not agreed with some - perhaps many - of his decisions, but I’m also cognizant of the fact that the firm’s portfolio at present - dire though the firm’s financial condition may be - is better than it was under McNealy’s tenure. Significantly so.

Does he bear responsibility for the firm’s decline? Of course. As any chief executive would, under similar circumstances. But I’m not sure who could have done better with what he was handed.

As an example, around the time Jonathan was ascending the ladder of Sun’s software business, James and I did an assessment of the software porfolio for Sun, and frankly, it was horrific. There were literally dozens of products strewn across the canvas of the organization, few of which had any consistency in terms of delivery, business model, compatibility, target platform, or otherwise. The story today is improved, if still highly imperfect.

The other question I think people don’t ask when they blindly advocate a replacement of the CEO: who’s your replacement?

Q: So what would you do if you were in Jonathan’s position tomorrow?
A: Everything for me would start with numbers. These numbers, specifically. The second slide, in particular, would dictate much of my approach.

As Cote has said, there are other businesses such as Adobe or Microsoft that can afford to subsidize significant, non-earning investments with franchises that print money. Sun does not, however, happen to be one of those businesses today, if ever it was one. Businesses that don’t make money or show at least the prospect of earning money, therefore, should be either cut or dramatically scaled back.

Regardless of how impressive the technology is.

Q: Can you provide examples?
A: Well, much of the impact would depend on variables that I do not have - specifically the headcounts of the various products, their expense structures and so on - but two that would seem to be luxuries at this point, to me, would be NetBeans and OpenOffice. Neither, you’ll note, appears on the Line Items spreadsheets linked to above, meaning they do not represent a potential source of income, meaning that they should be considered - in my view - a luxury. And Sun is not in a financial position, at present, where it can afford luxuries.

Q: What about the arguments in favor of those products?
A: Well, let’s take them in order.

So, NetBeans. It’s no secret - either within Sun, or to those that have spoken to me on the subject - that I’ve never understood Sun’s commitment to NetBeans.

In the early days it was, frankly, because the product was poor. But even as the offering improved to the state we find it today - highly competitive, even differentiated in certain markets - I remain convinced it’s a poor investment. Which is one area where Tim Bray and I apparently do not agree. Tim argues that Sun should focus on the a Web Suite:

Therefore, Sun should adopt a laser focus on building a Sun Web Suite and becoming the Web application deployment platform of choice. It’s a large space, a growing space, and one where we can win.

While I could quibble aspects of that claim, I think he’s largely correct: that is an opportunity, and one where Sun has interesting pieces. What I remain profoundly unconvinced of, however, is that tooling remains a critical portion of that opportunity. Where critical reads as “worth investing increasingly scarce resources in.”

Let’s accept as a given that NetBeans is profoundly improved from the Swing-slow toolset of a few years back. Let’s further grant that Sun has been market responsive of late, and gifted the toolset with some excellent dynamic language capabilities. My question is this: how does this make Sun money?

Is the attach rate for Sun infrastructure - the stuff that people actually pay for - that much better for developers that use NetBeans versus, say, Emacs? Because that is, in many respects, the competition. I have seen little evidence that - outside of Microsoft’s hermetically sealed environment - a tooling story is intrinsically complementary to an infrastructure story. Most of the web developers I know use text editors (BBEdit, emacs, TextMate, vi, etc), not IDEs. And those that do use IDEs tend to use Eclipse, not because it’s necessarily better, but - like Firefox - because of the ecosystem around the product.

No matter what they use, however, the tooling has little if any direct impact on the infrastructure that backs it. Many of the NetBeans users I know are writing to a LAMP stack running on Dell hardware, while back at Major League Baseball, the staff was using Eclipse to write to a Sun portfolio. And if the tooling is not a lead for revenue generating infrastructure commitments, where, precisely, is the return on Sun’s investment in the platform?

If you’re still unconvinced, consider that the dominant cloud providers of the present - Amazon, Google App Engine, and Salesforce.com - have no tooling story of their own, and yet are successful. Why then would - or should - NetBeans be predictive of success for Sun from an infrastructure perspective? My opinion is, obviously, that it shouldn’t, and will not be.

If NetBeans isn’t making money itself, and isn’t cementing sales elsewhere, what is its purpose?

Q: And OpenOffice?
A: OpenOffice.org is nearer and dearer to my heart, as I’m still a user of the product - though much of my office productivity time these days is spent in Google Docs - and 3.0 is a remarkable achievement, performance-wise. As I’ve documented elsewhere, OpenOffice.org 3.0 will cold-start open a document for me in just under 3 seconds; contrast that with IBM’s Symphony, built on an older version of the OO.o codebase, that takes just under 13 seconds on the same document.

But while Sun has fought the good fight with OpenOffice, and made possible a raft of new innovations by combining with IBM to champion the OO.o derived ODF format, the time has come to let the effort sink or swim on its own. Over three years ago, I called for for OO.o to be transitioned to a foundation, and was more or less dismissed. Here we are, in 2008, and the product is still funded - although at reduced levels, it must be said - and still not making money: note its absence from the Line Items spreadsheet.

What then is the benefit of the product? Convincing people that Sun is serious about open source? I think most people have gotten that memo. Visibility? Possible, if you think that people pay attention to splash screens.

Here’s Jonathan on the subject of OpenOffice:

As for other high value distribution assets at Sun? I just read one analyst report questioning whether anyone actually used OpenOffice. We happen to run Sun Microsystems on OpenOffice - more importantly, it’s used across the world, and we’re now commercially licensing it to brand name companies wanting to save big dollars on office productivity.

To put some data around its popularity, last week, we distributed more than 3,000,000 copies of OpenOffice 3. Downloads are accelerating, giving us a reachable user base we estimate to be between 150,000,000 and 200,000,000 users - a global recession will amplify OpenOffice adoption. And 100’s of millions of users drive a lot of foot traffic. An auction’s afoot (no pun intended) to see who we’ll be partnering with us to integrate their businesses and brands into our binary product distribution - the possibilities are limitless: people tend to print those documents, fax them, copy them, project them.

That analyst report, it should be noted, was not ours, because the one thing I would not question would be the adoption of OO.o. It is, frankly, everywhere. But unlike, say, an enterprise database (e.g. MySQL), the odds of most people paying for an office productivity product are slim and none. Meaning that the return on Sun’s investment (whatever that may be) in the product is, at best, problematic.

Like NetBeans, OpenOffice.org strikes me as excellent technology, but excellent technology without an immediate revenue opportunity for Sun. Meaning that it has to be cut.

Q: What else would you cut?
A: Like Tim, I am not a believer in the client-side Java technologies. JavaFX always struck me as an also ran in that market, particularly once I heard the story of its ascension. While Flash and Silverlight are guaranteed places at the table by virtue of their respective positions, Java simply isn’t a major factor in the rich client landscape.

Which may not even be that much of an issue, because - again like Tim - I am not a believer that the world is going to be all that rich. I’m an early adopter, and the only RIA that I regularly use is Twhirl.

So are continued investments in JavaFX worth it? Not in my book.

Q: What is Sun? A hardware company, a software company, or both?
A: Hardware would probably be the most defensible argument. For FY08, the Systems folks reported 6.5B in billings, the Services crowd 5.3B, the Storage guys 2.4B, with the software kids bringing up the rear at 644M. Assuming that I read the line items correctly.

Q: So should Sun spin out its software business and become a hardware company?
A: That’s for others to say, but that doesn’t make much sense to me. It’s easier - by far - for Sun to differentiate itself on the software side than the hardware side. Not to mention that hardware businesses are declining, generally. Meaning that the barriers to entry, even if they haven’t perfected the model yet, are greater for their software business than their hardware business - just ask the BTRFS and the SystemTap people.

The immediate concern, of course, must be revenue, and revenue generation. But spinning off a differentiated asset for a potential short term profit to preserve a difficult to differentiate hardware business represents a logic that’s hard for me to follow.

As product lines like Amber Road demonstrate, the firm is at its best when it’s leveraging the respective strengths of the different lines to innovate. Spinning one out would seem to preclude that as a straightforward approach.

Q: Speaking of combinations, what about the cloud? Do you believe that Sun can and should play there?
A: Can they? That remains to be seen. As to whether or not they should, I differ again with Tim, who said “I’m not convinced that Sun can succeed as a large-scale supplier of cloud services, and I’m not even convinced that we need to,” as well as with other Sun executives who’ve told me in the past that they didn’t intend to be “in the hosting business.”

True, the cloud margins are slim. Perilously slim, perhaps, for a company as market impacted as Sun happens to be.

But as I argued in February, I do not believe that Sun can afford to not be a player in the cloud market:

Will said future, for example, include a computing landscape largely dominated by four or five big computers - Amazon, Google, Microsoft, and so on? And if it does, will Sun be one of those big computers, or merely a supplier?

Narrowly focused efforts like Network.com aside, Sun has to date shown little ambition to be the former. Which would worry me, because success with the latter assumes to some extent a reversal of the general preference among the big computer folks for non-premium, whitebox hardware. If there are going to be four or five big computers, and you don’t have a history of selling into them at volume absent significant subsidies, I’d consider that an issue.

As I’ve been saying publicly and privately for some time, I think it’s important - vitally so, in fact - that the vendor that coined the “network is the computer” tagline offer a network of its own.

Put more simply, let’s consider two markets: the enterprise and the web/developer.

The former are buying from Sun, still, but at a declining rate: hence the challenging results last quarter. Adding insult to injury, it’s possible that - in a vicious cycle - the enterprise may become a more challenging market given those results.

As for the web/developer market, they have not, historically, been Sun customers, and while they’ve purchased Dells in the past, the trendline here is increasingly skewed towards cloud platforms such as Amazon’s.

So where’s the entrypoint for Sun to make money? MySQL, perhaps. OpenSolaris, if the technical differentiation is properly leveraged and the comfort level factor can be overcome. Glassfish, possibly. But just a minute ago we discussed that - from a revenue perspective - Sun was not a software company, but one driven by hardware.

That tells me that it cannot afford to cede the hardware market to the likes of Amazon, because few of those providers have demonstrated an affinity for premium hardware. Google and its brethren are content to assemble their own gear from whitebox hardware providers, leaving Sun to service the less capable providers. Being an arms provider in a market content to manufacture their own weapons is not a future that I would envy.

Meaning that I would invest - and invest heavily - in the cloud.

Q: What about the comments about the field sales force? Do you think Sun needs a change here?
A: Sun’s field sales force is, as noted, equipped to handle a very particular market: large enterprises. This they do reasonably well, or as well as can be done in a market like this. Having met with Peter Ryan last week, I feel reasonably confident in saying that Sales are in good hands, and that what can be done will be.

The reality, however, is that this market will be challenging for the next several quarters, and there’s a reasonable chance that it becomes significantly more so. There’s only so much a sales force can do, at this point: the market is what the market is.

Of interest will be how Sun does or does not adapt its sales process to sell to non-traditional customers. While it’s long been a goal of Jonathan’s to enable Sun to sell to customers it never touched directly - a goal that I applaud, incidentally - its execution on this aim has been, frankly, less than impressive. Startup Essentials has made progress in this area - they stopped calling me, at least - and programs like Try and Buy are very creative, but collectively it’s not enough. When I speak with startups today, Sun is not top of mind.

Amazon, on the other hand, is. Without a massive direct sales force. From that I conclude that you should leave the sales force to its prescribed job of selling to the big guys, and give the other market what they want: a no-barriers-to-entry cloud product. Maybe with the help of some Jeff Barr-like evangelists.

In other words, the problem with Sun sales is not - to me - a logistical problem, but rather an inability to provide the market what it wants. That’s where I would start.

Q: If all or most of the above is tactical, where would you place your strategic bets from a revenue perspective?
A: My strategic bet with respect to the software business - outside of the traditional markets - remains the same: network services. Maybe if I came up with a cooler name for that, people would pay attention…but I digress.

The fact is that many of Sun’s businesses - like other open source businesses - struggle to convert users to paying customers. Experimentation abounds with hyrbidizing the technology, blending free and proprietary software, but the long term play from my perspective will be value added services that are delivered via the network. You use some bits, and pay for the value added service that is delivered on top of them. Think Akismet.

Longer term, were I Sun, I would be scrambling for opportunities to layer for-pay network services on top of my heavily adopted open source platforms. That’s a logical buy trigger for users, and a potentially lucrative recurring revenue stream for Sun. I’m not going to pay MySQL to run RedMonk’s databases, because the software is well written and does what it is supposed to do. I would pay MySQL, however, to watch my database telemetry, give me reports on performance, spikes, pending problems and issues, and the like.

Q: What would you tell Sun generally?
A: Most obviously, go private if it can be arranged. Getting regularly flogged, publicly, for trends that will take time to revert is spectactularly unhelpful - as I’m sure everyone there is all too aware.

But more importantly, as Sun is an engineering first firm: that the best technology doesn’t always win, and that there’s no room for emotion in a market like this one. Determine a product’s strategic importance and future profitability ruthlessly, and then cut anything that does not impact the bottom line as expeditiously as can be arranged.

This is unpleasant, and will mean political infighting, but it needs to be done.

Q: What do you think Sun will look like, on the other side of the proposed changes, as a firm?
A: I’m less concerned with the overall picture of a firm than I am with the results. Ideally, Sun would be positioned as a leaner entity focused on profitable or potentially profitable businesses: whether those are perceived to be web, enterprise, consumer or whatever is less critical than its ability to perform for the financial markets at this point. Tim spoke in his piece of certain businesses being “distractions,” and there is certainly a risk that an unaligned portfolio of assets means that the big picture story is more difficult to relate. That said, I tend to think that some of that is the byproduct of an unnecessary coupling of the separate product stories. I also think that - just like in baseball - a little winning would cure a lot of ills.

Q: Do you believe the firm can survive?
A: Absolutely. I think it will be challenged to “stay the course” from a product portfolio perspective and succeed, but with the appropriate adjustments I see no reason that the firm can’t recover and emerge stronger for the experience.

Popularity: 2% [?]

by-nc-sa

links for 2008-11-24

Popularity: 1% [?]

by-nc-sa

What’s a Document?

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.

Popularity: 2% [?]

by-nc-sa

links for 2008-11-23

Popularity: 1% [?]

by-nc-sa
Close
E-mail It