Once upon a time when I was a systems integrator, I had the good fortune to work with a very talented (as in multiple PHDs) lead architect. Not only brilliant, he was a genuinely nice guy and often the first person I’d seek out to bounce ideas or problems off of. On one particular occasion, I headed over to his cube under the weight of a problem with so many facets I’d essentially lost any sense of perspective or context. After patiently listening to me fumble around trying to describe a few approaches and how they weren’t working, he pulled a Master Po. He simply leaned back and asked me a simple question: “What is the problem you’re trying to solve?”
I was initially a bit perplexed, because I’d just spent around 5 minutes trying to outline it, until I saw that that was his point: I no longer had any sense of what it was I was trying to solve. I’d gotten bogged down in a quagmire of details and technical issues which had little to do with the solution to my problem. That simple question certainly didn’t solve my problem, but it was just the sort of reality check that I needed.
Now without turning this into some pointless philosophical debate or a post on the Zen of management techniques, I submit to you that this problem – this loss of context – is far more common than we realize. Not only to most individuals in the technology industry at some point or another, but the majority of vendors and enterprises as well. It’s often described as a lack of focus, but the problem is to me is better described as forgetting what problem you’re trying to solve.
Which brings us to the topic of the day: Microsoft, Mono and patents. If you’re unfamiliar with the connections between all three, here’s the abridged version: Microsoft submitted C# and the CLR to the ECMA standards body, and the Mono project took those standards and ran with them, creating a .NET equivalent runtime environment that runs cross-platform. What is open to interpretation, however, is to what extent the Mono project might run afoul of patents that Microsoft holds, and if it does, when and how Microsoft might take action. This uncertainty is what leads open source luminaries such as Bruce Perens to decide that he will not work with Mono, for fear that his work will later be encumbered. For more on the subject, you can grab a paper I wrote on the subject here (PDF warning), and we subsequently released under a Creative Commons license.
Given the current state of software patents, I suppose this conclusion is not much of a stretch. After all, if Sun has to pay Kodak (Kodak?) $92 million for patent licensing, who is safe?
What’s more, conventional wisdom says that any official assurance from Microsoft that the Mono project will not be subject to patent infringement would be folly of the highest order; Microsoft, we’re reminded, makes the bulk of its cash from its Windows platform, which would be threatened by the legitimate availability of its .NET development paradigm cross-platform. But frankly, I think that convential wisdom in this case is just that: conventional. Not the sort of aggressive thinking that might allow Microsoft to perform a bit of Kung Fu of its own, by using open source’s momentum to its own advantage.
The real question in my mind, the important question, is not how or when Microsoft might sue Mono users, but why? To answer that, I think it’s important to look at what problem is Microsoft trying to solve.
Given the rise of genuinely useful network applications and the inexorable march of Linux, at least on the server, does anyone believe that the ubiquity of Windows is as guaranteed as it was, say, 5 years ago? I’m not writing them off, mind you; I still think that whenever Longhorn arrives it will be a phenomenal operating system, and they’re still dominant. But I also find it increasingly difficult to believe that the margins and marketshare that they’ve built their business on are sustainable and unassailable in the longer term. Nothing lasts forever, as they say.
If we accept – for the sake of argument – that the marketshare is at least potentially at risk, how might Microsoft best respond? Well, an ideal first step would be to try competing on the merits of individual products, not on a falsely homogenous architecture. Start with Firefox, if that’s the easiest concession to make, but any recognition from Microsoft that its clients do not want to be limited to purely Microsoft architectures would certainly be a step in the right direction.
Unfortunately, that won’t be enough. As more people are beginning to realize, developers are where success is lost or won, not CIOs. From Microsoft to Sun, this realization is driving corporate agendas the industry over. Why? Because no matter how big a technology vendor gets, it can never solve every problem, or supply every application. Even the absolute giants of technology are beholden to their developers; as my colleague quotes Kathy Sierra, technologies need to create a wake that picks up developers along the way.
To give credit where credit is due, this is no secret to Microsoft. Over the years, the the folks from Redmond have done a remarkable job of recognizing this; its developer tools have consistently set the bar for productivity, Visual Basic singlehandedly brought a whole new class of developers to the table (much to the dismay of IT staffs everywhere), and has generally enjoyed positive relationships with millions of eager developers. Hell, Steve Ballmer got so pumped about developers that he needed surgery on his vocal cords.
But despite the tools, despite the attention, one could argue that Microsoft’s committment to developers is mere lip service. Why? Well, what do developers want? In a word, volume. The opportunity to have their software – their creations, their work – used by as many people as possible. Microsoft, to date, has gotten by on this score simply by virtue of its ubiquity. Should that ubiquity subside, even slightly, Microsoft’s value proposition would be lessened – perhaps substantially. When Microsoft is everywhere, the developers needs and Microsoft’s needs are reasonably well aligned. When Linux and other platforms grow more common, how does Microsoft sell developers on the volume opportunity? Unlike Java, PHP, Python or other platforms that run truly cross platform, Microsoft has focused on delivering solutions for its own platforms, and therefore its sell is heavily reliant on not just good marketshare, but dominant marketshare.
So let’s take a step back, and ask ourselves what problem Microsoft is solving. The answer is their own, the one they are fixated on – how to protect the platform. With Google showing the world what thin clients can do, and IBM, Novell, Red Hat and Sun are focused on providing client alternatives, Microsoft is playing a defensive platform protection game, not a bold “we’re the best development shop on the planet and can compete with anyone” game. Microsoft developers are essentially coopted to further the advancement of Microsoft’s platforms. From a Microsoft financial standpoint, that argument is pretty straightforward. But Microsoft cannot afford to look at it that way, because the key to their success – the developers – certainly won’t. What’s more important: enlisting the most developers, or trying desperately to protect the platform any way you can? What’s in Microsoft’s best interest may not be in the developers best interests much longer. That – to me – is the real problem, the one that Microsoft should be solving.
How to do it? Well, Mono seems to me to be a pretty good answer. They’d be able to recruit potentially legions of open source, Linux-loving developers from rival platforms, indoctrinating them in C# development. Overnight they’d have an open source play – one that isn’t likely to be immediately competitive with their own commercial offerings (think Microsoft as WebSphere to Mono as Tomcat) – and a truly compelling, cross-platform message for their developers. Think for a minute about a Microsoft that could go head to head with BEA, IBM, Oracle or Sun with an open source, cross-platform play. Well, it could happen if Microsoft did one thing: grant Mono a patent amnesty. Microsoft would be using Mono, and Mono would be using Microsoft, but it makes sense for everyone involved. If, that is, Microsoft is content to have its platforms compete on their own merits, rather than “integrated innovation,” AKA virtual lock in. Either way, I think Microsoft would do well to take a step back and try and determine what the problem is they’re trying to solve. Being defensive, after all, isn’t what got them where they are today.
