Blogs

Redmonk

On GNOME: Gruber’s Wrong, But That Doesn’t Make Me Right

The Ubuntu Dust Theme

The big win is saying ’screw you’ to KDE and Gnome and all those crap Linux interfaces and APIs.” - John Gruber, Daring Fireball

Just last week, I mentioned that when it came to Apple, there was no one whose commentary I respected more than John Gruber’s. Ironic, then, as he made his commentary on everything else invisible to me the very next week. Sad, too.

But I digress.

As a full time user of a GNOME desktop, part time user of a KDE desktop (it lives in a Kubuntu virtual image I maintain), I take exception to Gruber’s characterization. And were I one of the developers, I would likely take strong exception. Not because I believe it’s the equal of his preferred Mac UI; it is not, for most users. Not because I think it can be, as pictured, a very attractive and functional desktop, though it is. Nor because, as Luis argues, it is decidedly unclear that the Android UI - which debuted to decidedly mixed reviews - could so suddenly eclipse the technologies Gruber dismisses with a single sentence.

I disagree with his analysis, rather, because it seems to contradict the available evidence. True, the APIs have their issues - ABI breakage, redundancy and so on. But what platform’s API story is perfect? Carbon vs Cocoa, anyone?

Besides, if the Linux desktop APIs were designed as poorly as Gruber argues, we would expect to seem a commensurate decrease in investments in them. Instead, I’m seeing the reverse. Though I beat them up about their inability to sim ship, Adobe is actively producing versions of AIR and Flash for Linux. Google releases versions of Desktop, Earth, and Picasa for Linux. Amazon’s MP3 store has a Linux front end. Intel bought our friends from OpenedHand for a reason. Hell, even IBM - as conservative a platform targeter as there is - is supporting Notes and Symphony on Linux.

Even if one agrees with the above assessment of the Linux desktop APIs, then, it’s difficult to conclude that the above energies would be likely candidates for a sudden redirection onto Android. Assuming, of course, that that platform is superior, which I’m very far from allowing.

Much as I disagree with Gruber on this point, however, I do believe that GNOME is missing an opportunity. As anyone who’s spoken with me on the subject of the Online Desktop will know.

I’m still catching up on the output from the GNOME Summit that I blew through on Sunday, but the fact that GNOME - like virtually every other desktop on the planet - still considers the network as an optional or edge condition smells to me of opportunity lost. As Ray Ozzie once put it:

The real question is (that) if you were going to design an OS today, what would it look like? The OS that we’re using today is kind of in the model of a 70’s or 80’s vintage workstation. It was designed for a LAN, it’s got this great display, and a mouse, and all this stuff, but it’s not inherently designed for the internet.

Precisely. And though he was speaking of Windows, presumably, the same might be said of GNOME. Or OS X for that matter, but that’s a discussion for another day.

GNOME still holds the network at arms length, declining to bake the network in at a low, API level. I’ve mentioned previously trivial examples like a “Change Desktop Background” that leveraged Flickr or a Banshee (or Rhythmbox, if you prefer) that stored music on the cloud and integrated eMusic. And now we have emerging services like Stitcho (Windows/Mac only, please note), described by (new Moz employee) Dion as “Growl for the web,” which aims to give web based applications a pipe back onto the desktop - making them first class citizens, in a sense.

Further blurring the line between web and desktop. Which GNOME isn’t, to my eye, doing much of - with the exception of, say, network chess (I’ve heard and seen little from GOD since Havoc left for Litl).

Network awareness need not be a dependency, as some fear, because no one’s arguing that GNOME should become a thin client front end. But it seems self-evident to me that the network could be imbued at the most basic levels of GNOME, in ways that Apple or Microsoft could not, or more properly would not wish to, match.

That GNOME developers are hesitant to embrace services like Google and Flickr so intimately should not come as a surprise: they are not - by and large - free and open in the way that GNOME is. But while we can debate whether or not it should be, the fact is that freedom simply is not the priority for users that it is for developers.

Which naturally might lead to this question: who’s right? Natural though that might be, that is also in my view a wrong question, mostly because it just as inevitably leads to a philosophical quagmire. Better to ask whether or not free and open alternatives to popular services like Flickr and Google are anticipated in the near future, and if not, whether GNOME is best suited by waiting for them to arrive, or building them an optimized desktop in advance of the day when they do.

Utilizing, obviously, the non-free alternatives in the meantime.

My words, I’m sure, betray my opinion on that subject, just as Gruber’s did his. Not that I expect either to have much impact on the GNOME community, of course; I periodically need to vent on this subject as a user.

In other words, it’s just my two cents.

Popularity: 2% [?]

by-nc-sa

links for 2008-10-10

Popularity: 1% [?]

by-nc-sa

Caution, Apprehension, and Suspicion?

Speaking of analysts/consultants, whatever comes from Redmonk ought to be taken with a level of caution, apprehension, and suspicion.” - Roy Schestowitz, Boycott Novell

Profoundly as I take exception to that statement, Roy and I might at least agree on one point: people should be skeptical of analysts. Much as they should bring a healthy skepticism to all of the sources they consider as input.

Particularly in an election year.

Regarding RedMonk specifically, this is hardly the first time this question has been raised. We’ve been asked about biases many times in the past, and I do not anticipate those questions being resolved as long as we are in this business, because consumers of research must, in my view, consider the source. That, in part, is why we include disclaimers on each piece of research we produce, which assists readers in determining which of the mentioned vendors support RedMonk commercially and which do not. The job of perceiving and detecting bias, then, is rendered a relatively simple task.

As I explained to InformationWeek reporter Larry Greenmeier in a now sadly unavailable piece discussing questions of analyst bias, we take the issue of analyst bias quite seriously:

When he interviewed me, Greenemeier asked whether or not being smaller and open rendered us immune to the types of the ethical and conflict of interest questions that they skewered the bigger firms for previously. My response was simple: not at all. If anything, we should be under more scrutiny since we unapologetically derive the vast majority of our revenue from the very vendors we analyze. How then, he asked, do you answer such questions - how do you inspire trust? By being open, I replied. Which is where blogs come in.

Unlike a research report that might be published behind a for pay firewall and thus be available only to a small subset of the technical community, our research is freely available to any and all comers. It can be and often is read and commented on widely, by those who agree and disagree with our positions and conclusions. In a transparent world, I asked, how long do you think we’d survive if we were nothing but shills for the firms that pay us?…We say what we like, and work only with firms that can respect that - turning down not insignificant volumes of business as a result.

RedMonk customers - Microsoft included - are frequently unhappy with our criticisms and research: just ask them. IBM was far from thrilled with James’ recent observations of their cloud strategy, Microsoft was at least mildly irritated with my analysis of their OSCON announcements, and so on. Which is not to argue that I few select datapoints may prove - nor disprove - our independence.

But Schestowitz, for his part, has offered up even less evidence. Essentially, Schestowitz would have us branded with a scarlet letter - S for sell-out, perhaps? - for the simple crime of agreeing to work with Microsoft. As he has, in the past, recommended that Raven Zachary of the 451 Group be similarly tarred and feathered because he had the temerity to actually visit the Redmond campus. Nowhere that I’m aware of does he point to an alleged example of said bias; it’s merely assumed because there is a disclosed financial relationship in place.

Which is his right, of course. While I have no respect for what is effectively fundamentalist position - or black/white as SJVN puts it - I do respect his right to hold it.

More, I welcome the oversight. With respect to Microsoft specifically, they have been sporadic RedMonk customers for much of our existence. If Schestowitz, or anyone else for that matter, can correlate the tone of our coverage of the firm with the time periods in which we were engaged financially, I would be most interested. Because while it is certainly not impossible for bias to creep up unaware, I am at present unaware of any such examples.

In the absence of such evidence, however, I would ask that readers bring only a natural skepticism to our past and future coverage, rather than an intrinsic assumption that working relationships with vendors must inevitably corrupt coverage.

Popularity: 1% [?]

by-nc-sa

links for 2008-10-09

Popularity: 1% [?]

by-nc-sa

OS and Virtualization or Virtualization and OS: Red Hat Analyst Day

red hat analyst day @ NYSE boardroom

We each behave according to our nature. It should come as no surprise, then, to learn that while a virtualization supplier believes that the operating system is, effectively, a feature, an operating system vendor would argue that the converse is true. The philosophical differences between Red Hat and VMware could not have been more apparent during their respective events - September’s VMworld gathering in Las Vegas and yesterday’s Red Hat analyst day held at the New York Stock Exchange.

VMware’s perfect world, as described at VMworld, would see the operating systems disintermediated and subordinated to the virtualization platform, which would become a platform in the Microsoft sense of that word. Red Hat, on the other hand, primarily messages enterprise grade platforms, constructed upon an open source development model, that are eminently capable of and/or friendly to virtualization. In Red Hat’s words, “We won’t be talking about hypervisors in a year or two, it’ll just be a feature of the operating system…The hypervisor only guys have to become an operating system if they’re to be successful.”

While it might seem as if these two views would be fundamentally incompatible, they are not. At least in the technical sense. RHEL will happily run VMware, and vice versa. Indeed, customers of one are like as not to be customers of the other, at least in certain market segments. But make no mistake, in terms of their strategic footprint and relevance, Red Hat and VMware’s ambitions overlap considerably.

Asked, yesterday, which view I subscribed to, I (predictably) equivocated. Much depends on the primacy of virtualization within the particular customer segment you happen to be curious about. For customers that heavily leverage virtualization as a strategic enabler, VMware’s perspective will be the most relevant, because of their feature/function superiority and management capability head start. For customers, on the other hand, who work backwards from applications or specific business requirements that are platform dependent, the operating system is the more pressing concern because of questions around compatibility, performance, resources and so on.

Ultimately which way you lean is likely to be determined by your answer to this simple question: do operating systems matter? We know, both from public statements and the past pushing of virtual appliances, what VMware thinks. And it’s probably not hard to guess what Red Hat thinks, given that they are the dominant supplier by marketshare of Linux to the commercial marketplace.

From my past answers to that question, you might conclude that I’m more inclined to see things Red Hat’s way. A conclusion that is mostly true.

Until such time as VMware is able to divorce the application development process - and more importantly the task of supporting the output of that development process - from the operating system itself, the latter will matter. Which is not to dismiss either the importance of VMware’s technology or their still dominant position in the marketplace. I just cannot agree with VMware CEO Paul Maritz when he says “the traditional operating system has all but disappeared.” Certainly Red Hat’s financials belies this claim, as do Microsoft’s though the mint that is Office complicates matters.

Like Winston Churchill’s democracy, the idea of the general purpose OS is the worst except for all the others that have been tried. There are a multitude of advantages to highly customized operating systems, as Google’s subsecond latency proves daily. But the cost is high: high enough, in fact, that economics have dictated the technically inferior approach of the general purpose operating system. Like a Swiss Army knife, or the jack of all trades, it may be the master of none, but it is unquestionably the dominant form of computing at the current time. And as discussed above, unless application development and support processes change monumentally, it will be for the foreseeable future.

Which is an exceedingly long winded means of explaining why I think Red Hat is important, rather than an account of yesterday’s agenda. I’m not entirely sure that VMware was mentioned at all, in fact. For those interested in what Red Hat had to say yesterday, here are some brief comments and notes.

On the Business Model

  • One trend worth noting was CEO Jim Whitehurst’s repeated defenses of Red Hat’s model as both sustainable and defensible. In light of both Red Hat’s sustained financial success and its overall size, I thought it odd that such a focused explanation would be necessary. In answer to my questions on the subject, one explanation offered was the audience, the majority of which were financial analysts that still might not grasp the concept of F/OSS.

On the Cloud

  • The Cloud got a surprising amount of attention. Surprising because I’ve struggled to get some vendors to perceive the size of the opportunity, and Red Hat spent nearly two sessions yesterday discussing it. Red Hat’s also got some very interesting plans vis a vis open source and the cloud, but I’ll save that for a post of its own.

On the Customer Portfolio

  • Reading between the lines, it appears that Red Hat feels that they are still in the midst of crossing the chasm from early adopter to mainstream users. Red Hat has many mainstream customers, true, but it remains underpenetrated still in mainstream markets - particularly those dominated at present by Windows. Which is why the ties being built to major systems integration firms are important - vitally so.

On the Financial Crisis

  • Either because they are lucky or because they are good, Red Hat’s exposure to the commercial paper shortage is nill. Liquidity is not a problem operationally, with significant cash on hand.
  • Likewise, Red Hat’s exposure to the failing fortunes of financial customers is less than might be supposed. For all of their success on Wall Street, financials as a vertical place third behind telecom (1) and government (2). Analysts were told that while the economy was obviously a concern, Red Hat had no extraordinary concerns in that regard.

On the Market/Revenue Share

  • Though they didn’t provide specifics, Whitehurst informally characterized Red Hat’s marketshare as “high teens,” with a revenue share, however, in the single digits. Though that combination might strike many as problematic, Red Hat apparently is more sanguine, as its margins are claimed to be among the highest in the industry.

Disclosure: Red Hat is a RedMonk customer, as is Microsoft. VMware is not a RedMonk customer.

Popularity: 3% [?]

by-nc-sa

links for 2008-10-08

Popularity: 1% [?]

by-nc-sa

Is the Hourly Model Broken?

I can’t speak for James, but when he and I founded RedMonk six years ago come November (crazy, isn’t it?), I for one did not anticipate what we’ve become today. I didn’t even try, to be honest. My belief was that as most successful ventures will, RedMonk would evolve according to the rules of natural selection; in this case the needs of the market, our customers, and our competition.

Because there was always this: if we didn’t adapt, there was no point in worrying - we wouldn’t suffer that long.

But one thing we were jointly committed to from the first day was a rethinking of the traditional analyst model. We had - and still have, for the most part - significant philosophical differences with the models that preceded our own. The notion of “seats,” for example, was something we viewed as unnecessary friction and a barrier to entry. Obviously we had big problems with commissioned content, but even the way that the rights to publications were sold after the fact - web rights were one fee, print another, and so on - rubbed us the wrong way.

One problem we have yet to solve, however, and I don’t believe this is unique to our industry is the issue of hours. We, like many in our industry, work according to an hourly model. In theory, whenever you’re working with us, we put you on the clock, dock hours from your contract, and if you run out you can simply purchase more.

In practice, however, this model has issues.

  • It doesn’t reflect the way that we work:
    In a few ways. Generally, our client (and even non-client, to some extent) briefings include substantial feedback, reaction, and analysis. And yet we cannot typically “bill” for this value because it has been scheduled as a briefing rather than a consult. So we can either a.) withhold all useful feedback from our nice paying client, saving it for a scheduled follow-up call, or b.) deliver the feedback in the most convenient form possible - the call we’re already on - and trust that the value is understood and will be rewarded.

    Also much of the work that we do for our clients is non-consultative in nature. Whether that’s offline community interactions, event attendance and feedback, product testing and usage, client networking or any of the dozens of other behind the scenes services we perform on behalf of clients, these are not accounted for under an hourly model. Because…

  • It doesn’t handle (well) micro-interactions:
    The hourly model, venerable as it may be, does little to account for interactions like the emailed request for an immediate strategic response to a new threat that we received last Friday. Given that our priority is servicing our customers, we enjoy responding to these types of ad hoc, low friction inquiries. But they are not, typically, accounted for in an hourly model. Leaving us have two real choices: trust that customers perceive and appreciate that benefit (which, often, they do), or move to a legal-style billing-by-the-minute. Which brings us to.
  • It imposes an accounting overhead on both parties:
    One of the banes of my existence, before we brought the inestimable Marcia on board to help, was documenting, tracking and accounting for all of the analyst hours consumed. It’s a tedious, mind-numbing task with little obvious reward. And yet, because it’s the way that most analyst models work, it’s a real necessity. Neither side, in my experience - analyst nor customer - appreciates this chore. But both sides dutifully perform it in the hopes of documenting for accounting purposes, if nothing else, what precisely was done with those hours. And speaking of what was done with the hours…
  • It imposes a barrier to entry for interactions:
    This, frankly, is my biggest issue with the hourly model: it’s a massive barrier to entry. We frequently have employees within end user customers that would like to leverage hours that are available to them per the terms of a RedMonk subscription, but either are intimidated by the prospect of reducing the number of available hours even slightly (the hoarding problem) or uninterested in the occasionally cumbersome process of procuring hours (the process problem). This typically results in one of three outcomes: 1.) the original request is dropped and/or forgotten, 2.) a “briefing” is scheduled in which our “feedback” is heavily and actively solicited, or 3.) a back channel inquiry is made.

These are far from the only problems I have with the analyst hourly model, but the most obvious from my perspective.

Common courtesy would seem to demand that after presenting a list of problems, some ideas regarding potential solutions would also be put forth. But the superior achievable model is non-obvious to me.

Consider the difficulties of a non-hourly model such as a (virtually) unlimited subscription. In removing barriers to entry, it might do so so effectively that clients gorged on hours, unbalancing their consumption and our ability to service them and other clients. Plus, the complete absence of documentation is probably not a great idea.

Answers, then, I don’t have for you. It’s something that we continue to try to evolve and improve internally at RedMonk, but there may be aspects of the model that we are quite unable to resolve. But should any of you - and we have folks from the customer, analsyst, and analyst relations areas in the audience, I’m sure - have opinions or suggestions on how we could address some of the mentioned issues, we’d be all ears.

Popularity: 1% [?]

by-nc-sa

links for 2008-10-03

Popularity: 1% [?]

by-nc-sa

The Forecast? Way More Microsoft

and without

Leave it to the folks from Amazon to make a liar out of me. Tuesday night around 9:00 PM I wrote the following:

In the cloud, F/OSS is at present the rule, rather than the exception…Amazon? Built on Xen, hosting only (to date) open source operating systems (Linux and, in alpha, OpenSolaris).

Less than four hours later, Jeff Barr and the gang over at Amazon announced the forthcoming availability of Windows on EC2. Not to be outdone, the folks from 3tera announced the immediate availability of virtual appliances based on Windows server. And that wasn’t the end of the cloud news.

Steve Ballmer, the same day, let drop word of the “Windows Cloud” operating system, which apparently is not Windows 7, but something else entirely. Presumably something else that’s designed and optimized for the cloud.

None of this, precisely, qualifies as news. Or if it’s news, it’s not surprising news. We’ve known for a while that the folks from Redmond were planning a cloud based offering; as I said back in August, “Microsoft will not willingly cede such a crucial market to a rival platform.” In other words, we knew this was coming. Not precisely when, it’s true, but that this day would come. Even if, technically, the day hasn’t actually arrived yet. At least for Amazon and Microsoft, whose offerings aren’t generally available at present.

What people are asking us now is what, precisely, does this mean?

The answer is that it means that we may see the dynamics of the server market made manifest in the cloud at some point the future. Open source platforms - Linux, primarily - have the clear head start, and some intrinsic advantages (specifically in licensing). But nothing approaching a sufficient barrier to entry to preclude Microsoft from making a tremendous impact on the cloud in terms of marketshare.

Much, of course, will depend on the logisitics and execution. How are the offerings structured and priced? Will customers, for example, need to concern themselves with CALs? On the execution front, how seamlessly has the Windows experience been translated to the cloud, an environment with significantly different requirements relative to on premise datacenters? Has Microsoft adapted its operating system technologies successfully to the cloud? This might be an easier task, counterintuitively, than Windows 7 development due to the reduction in hardware types, use cases and so on. But it’s still a significant - possibly monumental - challenge for a firm that spent the better part of a decade building an operating system that debuted to poor reviews.

At the time the specific services become generally available, at least in beta form, I’ll have a significantly more detailed reaction for you. But it’s difficult to argue that this week’s spate of announcements will have an impact on the adoption of the cloud generally, and the platforms within it specifically. Still, it’s far too early to conclude that Microsoft has pulled an get-the-internet style 360 and adapted simultaneously its technology and model for a world in which local infrastructure is - if only slightly - of diminished importance.

Either way, Amazon looks like a winner here. But more on that later.

Disclaimer: Microsoft is a RedMonk customer, while Amazon and 3tera are not.

Popularity: 1% [?]

by-nc-sa

links for 2008-10-03

Popularity: 1% [?]

by-nc-sa
Close
E-mail It