Stuff Michael Meeks is doing

This is my (in)activity log. You might like to visit my employer SUSE which is an amazing company, and also Dell who in days of yore provided me with a free laptop for Gnome development / conferences. Also if you have the time to read this sort of stuff you could enlighten yourself by going to Unraveling Wittgenstein's net or if you are feeling objectionable perhaps here.

Older items: 2012: ( J F ), 2011: ( J F M A M J J A S O N D ), 2010: ( J F M A M J J A S O N D ), 2009, 2008, 2007, 2006, 2005, 2004, 2003, 2002, 2001, 2000, 1999, legacy html


2012-09-30: Sunday.

2012-09-29: Saturday.

2012-09-28: Friday.

2012-09-27: Thursday.

2012-09-26: Wednesday.

2012-09-25: Tuesday.

2012-09-24: Monday.

2012-09-23: Sunday.

2012-09-22: Saturday.

2012-09-21: Friday.

2012-09-20: Thursday.

2012-09-19: Wednesday.

2012-09-18: Tuesday.

2012-09-17: Monday.

2012-09-16: Sunday.

2012-09-15: Saturday.

2012-09-14: Friday.

2012-09-13: Thursday.

2012-09-12: Wednesday.

2012-09-11: Tuesday.

2012-09-10: Monday.

Linux on the (consumer) Desktop

Overview

Arriving back from vacation, I read Miguel's thoughts on the state of the Linux Desktop in the race for the consumer market; I happen to mostly agree with his conclusion - that we're still facing a huge up-hill struggle there. While I have huge respect for his experience and insight, I think the causes are larger. My punch-line is that the Linux Desktop faces a huge and multi-factored ecosystem challenge, there is no single simple issue to fix. Over the last decade I've been peripherally involved in trying to tackle many of the problems in this area, here are some of my random thoughts and open questions on the topic, there are no radical new insights:

Our attractiveness to ISVs

Clearly this is a significant factor in our problem. No matter how bad and limited our APIs are, if there is market pressure to port software to the platform - it will come; hacks and all. Yes, the Linux Desktop is a horrifying thing to deal with from an ABI stability / interface perspective. Aside from the diversity of pointlessly different distribution packaging details, the Linux Desktop stack (with existing frozen / back-compatible API/ABIs) is not profoundly different from other operating systems - indeed, arguably it is better for ISVs since we have access to open the lid on the box and work with each other as some are finding out.

Other's attractiveness to ISVs

Often the disguised thought here is that the competition are simply wonderful at producing clean, crisp, working, tested, performant implementations of everything, for which there are no compatibility problems, and life is wonderful. People then often point at Windows XP - perhaps the best understood mature operating-system ever, with a decade of workaround development and integration testing.

How do Windows ISVs get such a great deal ? one thing they do is to distribute much more of the system in duplicate with each application. So for example each app ships it's own libc and gets to try to install it somewhere. This is something that we typically don't do on Linux, but it could be done: some form of application virtualisation would help. Conversely Windows ISVs suffer a lot of performance, scriptability, and repeatability problems that are just not there on Linux.

How about other new successful platforms like iOS / Android which are loaded with ISVs - do they have the world's most beautiful development environments ? given that Xamarin are selling sexy tools to improve the ISV environment there my suspicions is that not all is perfect. Enjoying native code development on these platforms is like enjoying extreme DIY dental surgery - the Linux Desktop is infinitely preferable as an ISV platform. Why do ISV's put up with it ? in my view, it is driven exclusively by the large addressable market. You don't need an MBA to see the trends and opportunity there.

Questions around a better ISV story

There is a lot more to say; but perhaps some of it belongs as questions. Let me frame them in this way; Question: is there something that we (as Free Software lovers) can do to make our ISV story sexy enough that it makes the Linux Desktop an attractive enough platform for developers that it overrides our lack of market share, and makes a Linux Desktop port of each piece of software automatic ? [ notice I'm abandoning the idea of a Free-Software killer-app that sticks to only our platform ahead of time, the market realities will bring it to Windows / Mac even against our will ].

What will attract ISVs to our platform ? what will make them feel at home, and productive producing software for the other major platforms ?

If we make it easy to purchase proprietary software, or to donate money to free software app developers and overcome our fragmentation to integrate this everywhere (a single 'App-Store'), will this bring us back to parity with other OS' or make us compellingly better ?

Attractiveness to (consumer) OEMs

It is often noticed that OEMs pay money to install Windows on their machines, and that the Linux Desktop is an apparently free alternative - so surely our zero cost should make us wildly successful right ? It seems to me there are a multitude of interesting problems here.

Zero is too inexpensive

One of the major business problems of hardware enablement is that it takes a constant investment of real cash to pay excellent engineers to make (brand new) hardware work reliably. Linux has more drivers working out of the box than any other OS - of course we rock; however - the Windows ecosystem distributes that cost among hardware vendors: who write their own drivers (subsidised by the hardware you buy), and the Mac ecosystem ships a very limited set of hardware. Unfortunately, the cost of the Linux Desktop to OEMs has been driven down to a marginal level by somewhat cut-throat competition. That makes enablement development hard to justify without enough volume. Substantially exacerbating this is the habit of consumer-grade hardware of constant switching of components. There is a silent, invisible, gigantic, cost-engineering war going on out there which squeezes cash out all along the chain. In the absence of good standard interfaces, this makes device support much harder for consumer hardware; a trivial but comic example is of custom tweaking batches of hardware to pre-define vflip states for built-in webcams, cf. the kernel.

Zero is not cheap enough

Unfortunately, even if hardware can be perfectly enabled, fully translated, with accurate manuals, support and update plans, integrated with OEM's imaging infrastructure etc. and at near-zero cost, this is still too expensive. Looking at other ecosystems there are substantial flows of cash to OEMs that are not obvious. There are a lot of these:

Channel issues

Even when the hardware is perfectly enabled, and there is an advertised Linux that works on this hardware - it is frequently extremely difficult to actually buy that model. Often these models are geographically limited, frequently the imaging process is done in the factory, and so the lower-volume Linux version you want is not in stock / is un-available on-line. Clearly by the time you head to an interactive shop display, the expensive (paid-for) display space is unlikely to be used for a little-known Linux variant of the hardware. So, all in all it's usually far easier to buy the device with Windows installed, and image it. Potentially there is a market for OS vendors to sell device-specific to-customer desktop O/S support but the transaction costs are likely to be high and the market small.

Zero can be much too expensive

The cost of supporting shipped hardware can be rather a large proportion of an OEM's expenses. That's particularly so if you image tens of thousands of machines with some crippling issue, or ship an update that breaks updating, or - any of the other software horrors you can imagine loaded on top of the inevitable hardware problems. I recall well being told by a nameless support technician to hold down 'QWER' while powering on a dead machine, not for some obscure BIOS feature - but to help re-seat the loose CPU immediately underneath the keyboard.

Perhaps here is somewhere we could excel - having ultra-robust, translated, cross-distro standardised recovery, re-imaging, disk repair, hardware diagnostics, incident reporting, built-in help-desk agents - which combined with relative virus-freeness could reduce consumer support costs. Re-installing windows is currently a routine lifestyle-choice for some people, nevertheless it is somehow a familiar and re-assuring experience - not something you send your netbook back for: just re-install. My hope is that the base-system consolidation around systemd might bring us some of this critical disaster recovery / re-imaging / rescue functionality in a standardized form.

Attractiveness to the Consumer

So perhaps the consumer is going to ride to the rescue, demand Free Software because it is better, and all will be well - the OEMs will respond to market pressure and produce what people want, and ISVs will respond to that.

If we build it, he will come

It is a nice dream. Clearly we want to make the best product possible for consumers. It is of course possible for an excellent product to spread virally by word of mouth, clever volunteer marketing, and more - but it is hard work. I often hear the idea that we just need to implement XYZ new feature, and people will flock to us. I'm always eager to see new features, but it seems to me that a feature-edge is rather a small part of the answer - we may well already be more secure, more manageable, more easy to upgrade, and lower cost: but unless consumers know about us - with the best will in the world, they can't choose us.

Making it easy to buy

Absent a near infinite supply of enthusiastic local hacker-types to install and maintain Free Software for everyone, your average consumer needs the ability to buy it. Unfortunately, the economics of encouraging high-street shops to position, and advertise it are punitive - a game for the very rich, and the results are not uniformly ideal - cf. Nokia's expensive Lumia displays in every mobile store window in the UK, and the resulting trivial market share. Potentially in an Amazon / web-purchasing world people can buy "one just like my mate has" without going into a shop, possibly media hype and brand loyalty can make people buy expensive new products on-line that they've never physically seen. On the other hand the experience of the rather cool Litl product - is not too encouraging.

Economies of scale in retail often lead to a few, large high-street vendors - whose appetite for across-the-board risk and experimentation with new software/hardware combinations is low.

Revolutionary technology improvement

There are two types of people: those who don't like to learn new things, and what was the other one ?. Persuading people to like change and new-ness is rather difficult - it seems to me, that the more humdrum and non-novel a product is, the more attractive 'new-ness' is as a marketing feature: "new ultra-squeeze toothpaste" turns out to be just the same old stuff in the same old kind of tube. Conversely - "new - radically different approach to keyboard key layout - up to 5x more productive" already doesn't sound like a winner. Apparently some new technologies are just so usable that people are willing to invest their spare time in learning them - perhaps that, or their brands, constructed by expensive marketing, are so powerful that people buy before they try, and feel they ought to catch up with their friends later.

Questions around Consumer demand generation

Can we create and retain a feature edge vs. other operating systems (who will relentlessly copy our killer ideas) for long enough, that we can create a marketing story that reaches enough consumers to build significant demand ?

Can we mobilise, motivate and inspire enough (tech literate) early adopters to evangelise, support and unambiguosly advocate the Linux Desktop ? Can we simultaneously please enough innovators such that they love using the platform to get their tasks done and let us capture a significant proportion of the leading edge of the adoption curve ?

Instead of targetting immediate ubiquity, could we find, and focus on a series of consumer niches which we can grow to become the de-facto solution, in turn growing a community of developers to sustain that niche ? Are there intrinsic strengths of the Linux Desktop that would stop any killer apps moving to other, existing platforms to avoid migration pain ?

Tentative Conclusions

While I've been hacking on and/or using the Linux Desktop it has improved in an simply incredible fashion. It is hopeful that on it's current trajectory it will continue to improve, assuming we can continue to (mostly) avoid the duplication, pointless re-writing, and un-necessary re-invention that plagues Free Software. However from a consumer adoption point I draw these hesitant conclusions:

Postscript - the Business user

So - perhaps focusing exclusively on the consumer desktop seems a bit depressing. It is interesting to consider instead the enterprise / business user. There are a number of factors here that make this a much more promising space, and one that I'd love to persuade more hackers to take seriously as they work. A note of self-interest, my employer SUSE happens to sell a fantastic Enterprise desktop SLED. A quick run-down of the salient differences are:

The net effect of the above is to make the economics far more favourable. Clearly there is still a co-marketing cliff of pain, the hardware manufacturers provide and debug windows drivers 'for free', etc. but the economics are much more tractable. So - what does a strategy for tackling business users look like ? What do business users care about that consumers tend to care less about ? I have a few thoughts, probably others have more:

In my view the most hopeful strategy for the Linux Desktop is to make it ideal for an enterprise, while not crippling it for consumers and very early adopters. It is perhaps not glorious - enterprises care little for the bling that doesn't have a direct, unarguable business benefit - and bling is fun to hack on; but surely creating real value, that allows people to work more efficiently, reliably, and speedily has to be a satisfying thing to do as well.

[ This is a live-ish post, that I'll try to update, correct, and cross-link better over time. ]

2012-09-09: Sunday.

2012-09-08: Saturday.

2012-09-07: Friday.

2012-09-06: Thursday.

2012-09-05: Wednesday.

2012-09-04: Tuesday.

2012-09-03: Monday.

2012-09-02: Sunday.

2012-09-01: Saturday.


My content in this blog and associated images / data under images/ and data/ directories are (usually) created by me and (unless obviously labelled otherwise) are licensed under the public domain, and/or if that doesn't float your boat a CC0 license. I encourage linking back (of course) to help people decide for themselves, in context, in the battle for ideas, and I love fixes / improvements / corrections by private mail.

In case it's not painfully obvious: the reflections reflected here are my own; mine, all mine ! and don't reflect the views of SUSE, Novell, The Document Foundation, Spaghetti Hurlers (International), or anyone else. It's also important to realise that I'm not in on the Swedish Conspiracy. Occasionally people ask for formal photos for conferences or fun.

Michael Meeks (michael.meeks@novell.com)

Made with PyBlosxom