Strategy is no longer a game of chess ...

HBR is rarely a publication I find to be of much use but occasionally it has articles which act as useful counterpoints. The latest of these is a post on 'Strategy is no longer a game of chess'

It's worth understanding the game of chess that is played between companies because it's a highly unusual game and one that I discovered after examining the level of strategic play vs action and impact on market cap (see figure 1).

Figure 1 - Strategic Play vs Use of Open as a means of changing markets and impact on Market Cap.

* The above is a bubble chart - the bigger the bubbles the more companies, from hi-tech industry in 2012. The conclusion was Strategic play had a stronger correlation with market cap change than action (e.g. in this case, use of open methods)

What was surprising from the study was :-

1) All  companies appear to be playing a competitive game (equivalent to chess)

2) The majority of companies had no effective way of visualising the "board" that they were playing on. This resulted in poor communication,  poor situational awareness,  a tyranny of action, unnecessary risks, poor scenario planning, disruption by predictable changes and weak 'why' in any strategic choice.

3) Without a means of visualising the environment, the majority of companies had poor mechanisms for organisational learning and hence understanding of basic economic changes.

4) The majority of companies seemed to rely on backward causality i.e. if company A does X and company A is successful then we should do X.

This study helped me finally understand why it was so easy to take over markets against well funded competitors as per the gameplay at Canonical vs RedHat. Yes, we were both playing a game of chess but only we could see the board - the battle was very one sided.

And hence to the HBR article. The conceit of the article is that companies know how to play chess and they've moved beyond this. Alas, for the vast majority, they have never been able to play chess. They have no way of visualising the board and are forced to simply copy others.

This is why when you compare strategy documents between companies that you'll find they contain almost identical terms - digital first, agile, cloud, big data, social media, insight from data, IoT, ecosystem, open, innovation, efficiency etc. These companies aren't moving beyond chess play, they're just scrambling to grab the latest meme because '67% of other companies do this'. Backward causality still rules strategic play.

Of course, some companies and Governments are learning how to play chess but there is little evidence to suggest that the majority of companies are moving up to a level of playing chess and certainly none to suggest the majority are moving beyond this.

Testing Yourself

If you want to test your state of strategic play, then you need to examine the level of situational awareness and gameplay in your organisation. The best way I know to do this is :-

1) Take your strategy document and rip out all operational, implementation, purchasing and tactical choices i.e. those things related to action - the how, the what and the when.

2) What is left should be the why. It's important to understand that why is a relative terms i.e why here over there. Hence 'why' should have been derived from an understanding of the landscape (situational awareness). Think of playing chess, you have multiple potential moves (the where) and why you chose one move over the others should be derived from situational awareness (understanding the board) and your gameplay. So, ask to see the board and ask 'why' this route was taken?

3) If no-one can show you the board nor explain clearly 'why' this route was taken nor explain what the 'why' is other than 'because our competitors are doing this' or 'because the CEO read an article in HBR' then you know you're playing a game of chess without looking at the board. In which case, you should just hope that your competitors are doing the same because if you're up against someone who can see the board then from experience they only need between 1/5th to 1/300th of your resources to take you out. Correctly used, the landscape is a massive force multiplier.

How much to pay for strategic advice.

I often get asked this, so I thought I'd add this as an aside. Good strategic play can be worth a small fortune but there are lots of variables such as the economic cycle, competitors gameplay etc. Someone who knows their craft is worth it though. However, the majority of large 'strategy' projects I've been exposed to are a complete waste of money.  I've seen million dollar projects I wouldn't pay tuppence for.

As a basic, any strategy project should first map out the landscape, compare the company with competitors on the landscape and identify opportunities, areas of efficiency and common approaches. This really must be done internally and it is nothing more than good house keeping. Any money you spend on getting outside help to understand your own landscape is pretty much a waste.

Once you have a good understanding of the landscape then it can be worth getting someone in to help advise on game play e.g. manipulation of markets through open means, building and exploitation of ecosystems, changing barriers to entry, tower and moat plays, use of regulations, uncertain changes etc.

These people aren't easy to come by - I've been doing this for a decade and I have a list of a dozen individual names, none of whom work for a big strategy company. Chances are, you won't find anyone better than yourselves at playing the game. Hence my advice is ... learn to play the game yourself.

In other words, I generally wouldn't pay a dime for outside strategy advice unless it helps you play a better game . The problem with advice is you're unlikely to get anything of real use and it won't help you develop your own internal capabilities. If you've never seen the documentary 'House of Lies' then can I suggest watching it before embarking on spending large amounts of hard earned cash on outside help. It's a pretty accurate reflection of what you'll be getting.

Who's up for a bit of Rackspace then?

We've all heard the news that Rackspace has hired Morgan Stanley to 'evaluate options' which is generally considered code for find a buyer ... soon. As I've said umpteen times before, Rackspace has been poorly advised in its cloud moves and it looks like it has got itself into a tricky corner being squeezed out of the future by Amazon, Google and Microsoft. This is a pity as I quite like Graham Weston but then the execs that were running the show have IMHO been out of their depth. It didn't have to be this way, alas it was.

Ok, as usual speculations are rife over who should buy and there's a bit of noise e.g. this thread on YCombinator. I thought I'd add a couple of comments to the suggestions.

1) RedHat acquires Rackspace: this is quite a popular one given both companies involvement in OpenStack. It is certainly possible for RedHat to raise any necessary debt to acquire Rackspace and there's been talk of RedHat becoming a service provider in some quarters.

My POV: Great for Rackspace if it happens and suicidal for RedHat. Neither Rackspace nor RedHat are well positioned for the future and so this is akin to a drowning man grabbing another drowning man in the hope of ... drowning faster? It certainly will concentrate a focus on OpenStack with RedHat able to promote a hybrid story but the debt burden, the integration costs, the liabilities, the conflict with any public providers and the make up of Rackspace's revenue are all going to be massively problematic. Despite the suicidal nature of such a move, RedHat has pretty much consistently shown itself to be devoid of good strategic play and so it's probably quite a likely move. I'd score this as possible and hilarious to watch.

2) CISCO acquires Rackspace: Cisco has been involved in OpenStack and has its UCS business to consider which Rackspace also uses. 

My POV: Great for Rackspace, foolhardy for Cisco. On the upside this will provide a good case example, help Cisco to promote a hybrid story and provide lots of opportunity for consultants to talk about synergies between the group. Unfortunately it again depends upon large future for private cloud (a suspect idea), fails to deal with the AWS threat in any meaningful sense, potentially creates channel conflict for UCS and is unlikely to turn around the fortunes of the group. On the upside, Chambers hasn't shown himself to be the great strategist of cloud and so there's a chance that he'll go for it. I'd score this as possible and even more hilarious than Cisco's recent $1 billion on Cloud over two years announcement.

3) Oracle acquires Rackspace:  Oracle has made recent moves towards OpenStack and certainly has the capital and a large enterprise base.

My POV: Great for Rackspace, not so hot for Oracle. Again this doesn't deal with the AWS threat and so is likely to end up a costly exercise. However, there's a lot of inertia out there in more traditional companies and Oracle could exploit this. Oracle is also still trying to find its future in cloud and whilst this won't buy such a future, it will give it some sort of story. Overall, a possible but a sad end to Rackspace. 

4) Amazon or Microsoft or Google acquire Rackspace: Oh, you have to be kidding. Why would they bother? I suppose they could always buy it for data centre floorspace, the existing customer base and some additional engineers. Can't see there being much of a premium on that.

... and on and on.

As for who do I think should buy Rackspace? Well, I suppose I should jump in on the game. There are some interesting names being discussed that have merit e.g. AT&T and Ericsson. But I'd look for the acquisition that is likely to make the most sense in the longer term. In my point of view (POV) that would be :-

5) Reliance Technology (RT part of RIL) acquires Rackspace : RT appears to be working on a public cloud effort in its local regions and this acquisition would provide it an opportunity to extend into the US. It has a fairly credible means for dealing with the AWS threat and every reason to play the game. There is a downside in the recent Oracle API case in the US which would need to be considered but this shouldn't prevent the move. RT has the right people, right mentality and capital needed and Rackspace would provide real estate, some credibility in the US and more engineers. Though the timing is not perfect it is not bad. Overall - well, I don't know if this would happen but it would be a positive and strong move. Though I'd be keeping the acquisition price low and negotiating hard. The current market cap seems much too high in my book given its position in future markets.

What if ... co-opting Amazon APIs

Back at OSCON in 2007, I talked about the necessity of creating a competitive market of multiple cloud infrastructure providers based upon the same open source technology in order to create a functioning free (as in unconstrained) market. This required co-opting the Amazon APIs.

I repeated the same advice to Eucalyptus before they commercialised in 2008 and to Rackspace before the OpenStack project was created. Alas in the case of Eucalyptus they temporarily embarked on an open core route and OpenStack decided to differentiate (which led to the current prisoner dilemma and other issues).

Alas, it's impossible to roll the clock back and determine exactly what would have happened. However let us suppose that OpenStack had decided to launch as an AWS clone and that the vendors had realised that co-option was their route forward, what could have happened?

First, it's worth remember that AWS services have a long tail i.e. there are core services such as EC2, S3, EBS which are heavily used and then other services which are less well used. Hence in producing an  effective AWS clone you'd only have to produce the most commonly provided services - something which customers can tell you.

If, in early 2010, the main 'players' - e.g. IBM, Dell, HP, Cisco, Rackspace, Google, PayPal, AT&T, Yahoo etc had got behind an open source AWS clone effort with significant investment - say $200M each in the first year, doubling each year - then by end 2011 you would have likely seen the first public AWS clones. 

Ok, they wouldn't have all the features of AWS but it would be enough to start to form a competitive market and some authoritative mechanism for ensuring semantic and syntactic interoperability between providers. By end of 2012, the market would have had enough internal investment - with a run rate of $8Bn+ - to start to initiate a price war.  The purpose of which would be to increase demand (compute is elastic) beyond the ability of one provider to supply (supply is constrained by building data centres) and to naturally fragment the market.

This wouldn't have stopped Amazon's growth but simply accelerated the growth of the market, overcoming concerns over single supplier options and providing a vibrant market. By the end of 2014, the AWS clone market should have become larger than AWS itself with all the main players having significant public providers and a reasonable investment of $3Bn+ each year and a total AWS clone market investing $30 Bn+ a year.

The AWS clone market would in effect start to control the market and take ownership of the APIs i.e. if the clone market decided to move the APIs in a particular direction then Amazon itself would be under pressure to follow.

Of course, none of this happened. 

One of the reasons why, and probably the most ludicrous and naive reasons, is because of concerns over legal ownership of the APIs and concerns that a legal challenge could be mounted. First, APIs are principles not expressions and even if Oracle succeeded in changing this (with their battle with Google) by the time this would have happened the AWS clone market would have in effect controlled the infrastructure API space and could easily as a  single group changed this API base. 

Amazon, is a smart player and was always more likely to want a significant chunk of a huge pie rather than get itself cut out of the market. Had the AWS clone market grown, there is unlikely to have been any challenge on API ownership. 

Alas none of this happened. The numpties who raised concerns over legal status of APIs and the desire to differentiate won the day. No competitive market formed. OpenStack is suffering from a collective prisoner dilemma. The players are all a tiny fraction of the juggernaut that Amazon has created.

It didn't have to be this way but the past happened. However, there are some lessons for the future including :-

1) Never, ever rely on strategic advice from a lawyer especially an IP lawyer. Remember IP is just a tool, a tactic and not the end goal. It must be balanced with an understanding of the landscape and competing concerns.

2) Never, ever try and differentiate in a commoditising market. Accept it is commoditising and exploit this including co-option where needed. Avoid the epic CEO fails.

3) Learn to effectively use Open as a weapon.

As for anyone asking 'Is it all too late, has Amazon won it all?' - well, of course not. There are many ways that Amazon can still be outcompeted. However, those paths are complex and beyond the capabilities of most companies / execs given that even simple plays (such as adoption and co-option) have confounded many. So, they're not even worth mentioning.

Instead focus on moving the battle into the platform space (i.e. co-opt and build around CloudFoundry) and learn to play substitution games for the lower order systems.

Organisational Add Ons

Most organisations seem to be collating a never ending list of new strategies (cloud, social media, big data, insight from data, agile, digital first etc) and a never ending list of new roles and departments (VP cloud, VP social media, Chief Insight Officer, Chief Innovation Officer, Chief Digital Officer etc).

The reason why we have an abundance of these micro strategies is mainly due to companies copying each other i.e. if '67% of other companies do X then we need to do X'. This copying occurs because companies generally exhibit poor situational awareness and are effectively blind to their environment. In such circumstances then copying others is all you can do in the hope that backward causality - if A did B and A is successful then if I do B, I too will be successful - works.

The reason why we have this abundance of new roles and departments is because organisations are not designed to change and hence we have to bolt on new structures.

It has all gone a bit Wardley here

I've just been asked who invented the technique I use for mapping organisations. Hmmm ... Me! Back in 2005 (with a bit of help from James Duncan). One of the first maps I created was Fotango (see figure 1).

Figure 1 - A Wardley Map

It's based upon two axis - a value chain of needs and one for evolution. Anyway, from now on please call them Wardley Maps. I'm getting tired of people asking me who invented this technique and so I'd much prefer people to ask me 'Who invented Wardley Maps?' and then I can say ... go on, guess.

Also the evolution bit was a pattern I first noticed in 2004 and then managed to confirm in 2007 by plotting out ubiquity vs certainty of a large number of different activities. So from now, please call this Wardley Evolution so I don't have people coming up to me and asking where did I get that evolution curve from.

Figure 2 - Wardley Evolution

Finally, the whole bit on how properties change as things evolve (you can call this Wardley Properties) and how multiple techniques are required (you can call this the Wardley Method).

Again this is to stop people (especially consultants and academics) asking me who invented / discovered / created it - I did! Me! I'm the person who put in all the effort to catalogue this stuff.

So the Wardley Properties (circa 2008) are outlined in figure 3, the Wardley Method (circa 2008) outlined in figure 4 and  an example (by James Findlay) as applied to High Speed Rail 2 (circa 2013) is outlined in figure 5.

Figure 3 - Properties of a Wardley Map 

Figure 4 - Applicable Methods in a Wardley Map 

Figure 5 - Example Application of Wardley Map, High Speed Rail 2

Whilst we're at it, here's the bit about counting frequency of activities and determining a profile for an organisation and flow (circa 2009) - let's call that a Wardley Profile (see figure 6)

Figure 6 - Wardley Profile, Flow and Culture

Which was used to explain why the Pioneer, Settler and Town Planner structure (which was implemented circa 2005) works. Oh, we may as well call that Wardley organisation.

Figure 7 - Pioneer, Setter and Town Planners - Wardley Organisation

Then there's many dozens of economic patterns, tactical plays, ecosystem patterns and strategic games which have been described from punctuated equilibriums to inertia to ILC to how new organisations form to how major economic waves occur (circa 2007-2011) - we can call that Wardley economics.

Alternatively you can drop the Wardley term for methods, properties, economics, profile, organisation and evolution as long as you cite where you got the stuff from (i.e me) and don't ask me dumb questions like 'where did I get this stuff from?' ... me, me, me! Who do you think put the work in and collected the data? Oh, I know I should finish the book but alas work gets in the way.

I provide this blog and this work under creation commons attribution share alike to enable other people to use it, not to be airbrushed out of the picture. It's my way of contributing back but I've got no problem with crucifying people online who simply help themselves to my work and don't cite the source. Just simply add 'Courtesy of Simon Wardley' and I won't grumble at you.

You can guess, someone has really annoyed me. 

Why Microsoft should buy Canonical

When Satya Nadella became the CEO of MSFT there was oodles of advice for what he should do - the majority of which I consider extremely poor. Alas during today's lunchtime conversation with a financial analyst, the topic came up and my friend announced that he thought MSFT should buy Red Hat. [Apparently a view he shares with Barb Darrow on GigaOm which is worth reading to get a different perspective]

I tried to resist but my friend needled the point. My response was that there is a reason why he plays a poor game of chess, he rarely looks ahead and fails to understand positioning. This is why he thinks that RHT would be a good acquisition whereas the far better play would be to buy Canonical.

This was followed by the usual guffaws and references to open source and Wall Street articles. So, I explained my reasoning and thought I'd write down my opinions here on how I see the world.

First, I'm not saying that Microsoft will do this and Satya would have had a game plan before he took over. However, I find the topic interesting because in any gameplay it's important to understand the landscape and the potential plays.

The Landscape.

Red Hat has done extremely well in the past. It's a large organisation with a handsome revenue but its problem is the majority of this is associated with past models of working and naturally past models create inertia to change. Whilst Red Hat might be the giant in the linux server world, it's a minnow compared to Ubuntu in the public cloud computing space. The acqui-hire of CentOS seemed more about buying Red Hat relevance (RHEL was probably in the 3-5% MaSh space) in the cloud but even with CentOS the combined efforts are still a fraction of Ubuntu. You can argue over just how much dominance Ubuntu has, whether it's 60% or 70% of the public space is irrelevant. What matters is Ubuntu is by far the most commonly used guest operating system on Amazon and I would be surprised if this was not the case for Linux on Azure. 

Yes, it's true that Red Hat has cried 'Charge!' and stormed into the valley with an all out commitment to OpenStack. But there are several dangers here, not least of which is that OpenStack is focused on a private cloud market (a likely transitional space), that OpenStack suffers from a collective prisoner dilemma and has followed what I consider a daft policy of differentiation rather than co-option. Red Hat has also acquired Ceph (at what seems to be an extremely high multiplier and btw congrats to Ceph) and Gluster but as with the acqui-hire of CentOS then in my view of the world, these aren't great strategic moves but instead smack of desperation for relevance in the future. Even OpenShift looks a fundamentally flawed effort compared to Cloud Foundry - a system which Red Hat should have co-opted. 

On the other hand whilst Ubuntu has a growing OpenStack business it also has many paths to future success from dominance in public cloud use, to Ubuntu phone to its relationship with Cloud Foundry.

When it comes to positioning, then Canonical (a small and nimble organisation) occupies the future space and Red Hat (a large organisation) dominates the past. How Canonical went from minnow on the server to dominating the cloud whilst Red Hat went from dominating the server to minnow on the cloud is testament to the level of strategic play between the companies. To put it bluntly, IMHO the Canonical execs outclass the Red Hat execs at every turn. Whilst Red Hat might have great engineers, their execs can't play chess for toffee in my opinion. Having once run strategy at Canonical, I can say this from experience as well. For almost two years, I watched Red Hat fail to react as we positioned Ubuntu in the cloud.

Buying Red Hat seems likely an expensive proposition at any price because you're buying into a lot of legacy use (servers) with poor future use (cloud) and a large organisational structure (with all the liabilities that incurs). If I wanted to acquire the engineering talent at Red Hat (which is considerable) then I'd swoop in and hire them with large cheque books. I'd simply gut Red Hat for talent and leave the less savoury cuts behind. Buying Canonical however gives you future positioning and there's a lot that can be done with this.

The Play

Let us assume that you're the CEO of MSFT and you've just bought Canonical. What could you do with this? Loads.

First, the Nokia (now MSFT) Android phone is in my opinion a mistake and possibly a last gasp politically driven effort by Nokia to show its innovative prowess. At one point I would have said it made sense but this should now be reversed. There is a far better way of playing the game. 

Whilst mothballing the Android phone, I'd launch a Nokia phone built on Ubuntu. There is already a telecoms / carrier group building around Ubuntu and lets face it, the Android market is dominated by Samsung. There are many others who want a more level playing field and to get in on the action.  By not having an Android phone then MSFT can still exert its Android tax which becomes difficult if you provide an Android phone due to IP clauses in the license agreements. Along with exerting the tax, it could encourage the formation of a market around an open source Ubuntu phone and provide a real and open alternative to Android. There's a lot that can be done here but the obvious question is why not Tizen or Mozilla? Well, first Tizen appears more about buyer / supplier games between Samsung and Google. Secondly, Ubuntu provides leverage which Mozilla does not.

How do I mean leverage? Well Google wants in on the cloud market, hence kicking off the price war with Amazon. But Google came out with RHEL and bizarrely there was little noise about the lack of Ubuntu support though this noise is slowly growing. This is bizarre because Ubuntu dominates AWS guest operating usage and you'd expect many of these would be users of GCE and hence to kick up a fuss. So what does this say? Well, it probably indicates there's not a lot of volume around GCE. 

Whether Google likes it or not it will probably need to support Ubuntu to make a dent in this space, you can't simply ignore the dominant operating system for long.

However, if Google ends up needing Ubuntu to play its cloud game against Amazon (where the majority of guest operating system is Ubuntu) and if Microsoft owns Canonical then it's going to be more difficult for Google to counter Microsoft providing an Ubuntu phone whilst MSFT exerts an Android tax. Ubuntu provides Microsoft with leverage. If Microsoft owned Red Hat then there's little or no leverage as Google can simply adopt Ubuntu.

But what of Apple? Well, what of it? Apple needs Microsoft Office on its iPads to compete against Android tablets. Apple needs to promote itself as the more superior 'enterprise class' environment. It'll be tough for Apple to launch a patent attack against a Microsoft Ubuntu phone if Apple needs Microsoft Office on iPads to compete against Android tablets and in any case it'll be in Apple's interest for an Ubuntu phone to undermine Android's growing dominance in the space.

So, how about Amazon? Well, the most popular OS on Amazon is Ubuntu and Amazon doesn't mind competing. In fact, whilst Amazon will want a big piece of the pie, it won't want all the pie because of monopoly commission issues. So if Microsoft buys Canonical and launches a Microsoft Ubuntu phone then it can still exert the Android tax, it can provide a way for carriers to compete against Samsung's dominance in the Android market, it can leverage Ubuntu's necessity for Google in its GCE race against Amazon, it can leverage Apple's need for Microsoft Office and Amazon EC2 users need for Ubuntu and hence MSFT can muscle itself a more respectable and powerful position in cloud. 

But there's more.

Ubuntu is supported on Azure but Ubuntu is also tight with Cloud Foundry. IBM and others seem to have realised that they've lost the IaaS game for now and need to build a market in PaaS and play substitution games to build their own positions. Cloud Foundry is the route for this game, it has strong strategic leadership in James Watters and if Ubuntu is supported on Azure, Amazon and eventually GCE then it makes the process of building Cloud Foundry environments across all of these that bit more easier - especially with technology like Ubuntu's Juju.

IBM can mix in its own IaaS effort and buy itself a space at the table with PaaS. The same goes for Dell, HP and others but Microsoft will gain influence in this space. It doesn't have to rely on the success of Azure's own platform play because Ubuntu's relationship with Cloud Foundry (the only viable route for these other companies) buys MSFT some positional power.

But what of OpenStack, isn't that going to change the world? Well, with a differentiation ploy, a focus on private (a transitional market) and collective prisoner dilemma then it has problems. Of course, things can change.

For example, what if Ericsson and Reliance Technologies get together with Canonical and some other players and fork the codebase, create a benevolent dictatorship, co-opt Amazon's APIs and with large enough wallets enable service providers to create a competitive market around an AWS clone (which is what Openstack was originally supposed to do). They could counteract Amazon's ecosystem advantage to some extent to provide an opportunity for service providers to survive. 

But wouldn't Amazon react? Well, Amazon likes to compete, APIs are principles and not copyrightable and it would be difficult for Amazon to take on such an effort if Canonical is involved given the dominance of Ubuntu on Amazon. In almost all scenarios, Amazon is more likely to settle for owning a huge bit of the pie (equate to $30 billion in annual revenues) and live with a competitive market rather than face potential monopoly issues. By owning Canonical, Microsoft can influence this whole game.

At the IaaS layer you'd end up with Amazon vs Google vs Azure with a market of clones around an AWS compatible OpenStack driven by Ericsson and Reliance Technologies. This would naturally push the market to consolidate on AWS APIs which after all is what almost every major company I've spoken to wants  - a market of AWS clones. 

At the platform layer, Cloud Foundry runs across all these environments and would enable IBM, HP and Dell to play a competitive platform game with substitution plays.

In the phone space, the telcos and carriers would get an alternative to playing second fiddle to Android / Samsung - a Microsoft Ubuntu phone. Google will need Ubuntu to be a player against Amazon and Apple will need Office to play against Android tablets. With the ability to exert an Android tax, provision of Ubuntu and Office then Microsoft gets to create highly competitive and open markets in all these spaces and take a chunk of the pie.

By owning Canonical then Microsoft gets influence and leverage across all these future fields. Yes, it would mean massive transformations within MSFT and learning how to use open source as a competitive weapon but MSFT is changing in any case. By owning Red Hat then Microsoft gets a chunk of the past.

For me, it's the obvious play but then I don't work as a financial analyst ... I do however play a mean game of chess.

--- Added 4th May 2014

I wrote the above post in response to the question 'Should MSFT buy RedHat?' for which I strongly view that Canonical is the better option for reasons of positioning and leverage. However, I've subsequently been asked whether 'MSFT buying Canonical is the best of all options?'.

My own view is that the best tactical choice for MSFT is probably not to buy either company but instead invest heavily in Canonical. The reason for this is to do with issues of stewardship and community response. Hence if I was running the game at MSFT, I'd be looking to invest $2-3 billion in Canonical in return for a 20-25% stake in the company. From a tactical stand point, I'd be wanting to demonstrate commitment and involvement in Open Source prior to any all out acquisition. However, that wasn't the purpose of this post. If you're going to buy one then buy the future ... which means Canonical.