Once More unto the Breach

Ian Murdock Joins Sun

Ian Murdock announced yesterday that he has joined Sun Microsystems as Chief Operating Platforms Officer.  Ian describes his move on his blog.  Stephen O'Grady at Redmonk has a good commentary and summary of other blog commentary. 

This is a great move for Sun, the Linux Foundation, and Ian. 

For Sun:
Sun (as most UNIX OEMs through the 1990s) invested heavily in ISV relationships.  Sun was hit hard by the Bubble bursting.  Linux was cheap "UNIX" in the eyes of many customers, bought out of their PC hardware catalog as it were.    Gravity shifted for the ISVs away from Sun and over to the dominant Linux vendors through the excellent efforts of the Free Standards Group and others.  As Sun begins to reassert itself as a cool computing platform again, they need to re-engage with ISVs (both new and old alike).  Having Ian on board with his background in Linux binary compatibility opens up new opportunities for new discussions with those ISVs.  This doesn't mean that this is the strategy, just that it opens possibilities that wouldn't otherwise exist without the relationships and history that comes with Ian.

The Linux Foundation:
First, while they're losing a CTO, they're gaining a strong champion in a vendor that is on the rise again and has long supported UNIX standardization, and will remain LSB chair.   

Second, everyone always wants to understand why Red Hat plays so coy with the LSB.  As the dominant Linux vendor, the last positioning they want is "we're just like everyone else."  Solaris on Intel opens interesting new opportunities for Sun customers looking to transition to new less expensive hardware.  They didn't want rewrite costs to Windows (their backlog is growing not shrinking so re-writes are uninteresting) and were considering Linux.  Red Hat has interesting competition again.  If Sun starts to play well with the LSB, Red Hat will participate more.  They can ignore Novell et al.  It would be dangerous for them to ignore Sun the same way. 

For Ian:
Read his blog entry.  He's clearly excited.  Sun lost its cool for a while.  It's great to see it getting its game back.  While both Microsoft and Red Hat may scoff for various reasons, and wave market share numbers around as "proof" of its insignificance, what neither of them realize (or possibly want to admit) is it's about profitability and installed base, and not market share.  Sun is becoming cool again and Ian's in an awesome position to help it.

Congratulations!

Novell's Link to the Microsoft TCO Linux Message

Last week, Novell got caught in a press release with Microsoft in which an HSBC IT operations manager makes appropriate noises about TCO of Windows over Linux per the Microsoft messaging of the past 5 years.  This is too bad really.  It emphasizes the points Brent Williams made in his presentation with respect to Novell:

• Novell thinks the problem is catching Red Hat: They need to formulate a brand identity for SuSE other than "We're not Red Hat." (slide 14)
• Shows that even Novell believes it can't stop Red Hat alone. (slide 15)

Here's a slightly different way to look at the messaging:

Red Hat began messaging at least a year ago around the use of Red Hat linux in value creation.  Here's how the logic flows from a Michael Tiemann presentation at the 2006 Red Hat Summit:

• Companies spend on average 4-8% of income on IT (Financial companies 8-12%)
• So regardless of how you carve up the cost savings, you're messing around with something that will NOT move the stock price anytime soon.
• IT focusing on the value creation side of the bar can help by delivering better customer service (and retention), market growth, competitive advantage. 

This is actually backed up nicely by studies over the past couple of years around ROI and TCO, where executives are more interested in the ability of IT to improve customer satisfaction and business information access than ROI, and recognize that they can't measure TCO particularly well. 

So to bring it all home for Novell readers:  If you were a billion dollar financial services company, you're arguing over saving the customer some money on a $100M IT budget, BUT the sort of money you're really talking about is 10% (according to old IDC Windows vs. Linux numbers) over several years for particular workloads, so $10M, and the reality is it's smaller than that because they're running a heterogeneous environment and aren't about to swap it all out soon.  And that assumes you can accurately measure the cost savings.

Red Hat is pitching value creation on the other $900M in revenues.  Moving the ball by 10% there (i.e. $90M) is a whole lot more interesting than 10% on the cost side.  As the CIO, do you want to help save a bit of money, or grow the business?  Which one moves the stock?  Which one makes you a hero and grows your bonus? 

The message is all about the customer as hero.   

"IT Departments Running on the Edge of Collapse"

There's a (short) interesting interview with Sun's James Gosling on C|Net today.  On the second page, discussing his desire to develop tools to help cut software development costs, he depressingly observes:

If you come up with a good software development tool, that makes life easier for the developers and they can get their job done quicker, then the first thing the manager says is "Oh you've got free time on your hands. Do this extra thing." ....

So pretty much every IT department will always be running right on the edge of collapse because if you ever get beyond the edge of collapse, you collapse, things fail, things fall apart. If you ever get on the other side, things get a little bit easy and people say "Oh we can do more."

In some sense I've resigned myself. In the land of tool builders like me, it's not about cutting IT costs as much as it is inevitably about enabling IT departments to do more.

He should be celebrating.  It's all about enablement.  Two ratios we seem destined to live since we started software programming are:

• The average number of lines of code written by an average developer per day
• The number of defects per thousand lines of code in a system

All our advances in languages and tools are about developing more (better) software by writing less code.   From higher level (compiled) languages, to modules, libraries, objects (and distributed objects), scripting languages, web services, visualization, configuration management, and automated build and delivery, it's all about enablement.  Every time we double the speed or transistor density of a chip, or the bandwidth on the Net, we come up with new and interesting applications to devour it.  So too with human capacity.

This is actually why free and open source software is such a fundamental software engineering friendly practice, and why sharing software (eventually through copyright) predates the FSF et al.  Good engineers develop systems to optimize for the scarcest resource.  The engineering efficiency and expediency of sharing known good building blocks and tools is obvious.  It's about preserving the value in the software, not destroying it.

Dr. Gosling is hopefully wildly pleased with his contributions! 

Seth Gottlieb Leaving Optaros

Seth Gottlieb was one of the earliest employees at Optaros, running the Content Management Practice, and he developed the great in-depth "Content Management Problems and Open Source Solutions" report.  (Optaros is in the process of updating the orginal, so it's no longer on their site.) 

Seth is setting himself up in business as "Content Here".  He's deeply knowledgeable about content and document management systems, the open source CM space, and he's massively vendor neutral (to the chagrin of many vendors).  Seth is also a contributor to the CMSWatch Report, and a regular speaker at the Gilbane conference.  Look him up on his blog.

Good luck, Seth!

The Best Presentation on Software Business and Open Source I've Ever Seen

Brent Williams presented “Open Source Business Models: A Wall Street Look at a Wild 2006 and the Prospects for Even More Fun in 2007” at EclipseCon Tuesday.   Brent is a (temporarily) independent equity research analyst.  Unlike so many “Wall Street” types, he approaches the discussion from the economics of what people do, rather than what they say they do.  Similar to r0ml in content, there are always surprises along the along the way.

Brent has graciously allowed me to post the slides.  Brent's analysis and mine are congruent on many topics, but he brings clarity to the topic and a wealth of experience.  He starts with a tear down of the Oracle Linux debate and the Microsoft Novell deal.  I especially like his tear down of the commoditization myth and his observations around interface standards versus standards of implementation.  A couple of slides in the presentation don't quite stand alone, but for the most part the deck is brilliant. 

Enjoy!

Debating Open Source Software Definitions

Update [2-Mar-2007, 14:06}: Stephen O'Grady's great commentary is here.  (Admittedly, he's agreeing with me.)   Here's another way to think about the debate, and my contention that it's orthogonal.  If we were to try and name opposite ends of a spectrum, and I was to say "open", you'd probably say "closed".  If I said "free", you could say "encumbered".  As long as you place "commercial" on the other end of "open", you are:

• Allowing Microsoft PR to frame your market discussion.  It's their Shared Source framing afterall.
  
• If you're in business, you're blinding yourself to all the other opportunities, tools, and processes you can use to best engage with customers.  It's wearing similar blinders to when using the "stack" metaphor instead of realizing the "network" metaphor. 

It all started when a terrible article ("Ten Leading Open Source Innovators") prompted Nat Torkington to ask "Is 'Open Source' Now Completely Meaningless?"  (The article also provoked Chris DiBona's ire).  Enterprise Open Source Magazine jumped into the fray with an odd article grabbing sound bites from various people and going under the sensational headline "How Open Is 'Open'? – Industry Luminaries Join the Debate".  Michael Tiemann chimed in with an articulate response, Nat finished up a roll-up post, and it even provoked r0ml to blog again -- always a good thing.

Allison Randall chimed in her contribution discussing EnterpriseDB.  This provoked Matt Asay to fire back (fresh from Alfresco's fine second relicensing move to the GPL).   

So what's all the fuss about?

This debate actually started for me several weeks ago with a colleague at Microsoft when we got into the debate (yet again) over "commercial software versus open source software."  And herein lies the rub.  These concepts are orthogonal.

Here's how I try to explain things to customers so they don't get all caught up in these tempestuous confusing debates and stick to buying the same damned things they always bought because they understand the old.

First, software projects are interesting buckets of technology.  These projects have users and contributors, i.e. a community.  Open source has a definition.  So does free software.  If these projects are open source or free software, then they meet one (or both) of these definitions.  Pretty simple really. 

Second, products are packaged, installable, tested, documented, supported, and maintained for customers.  Companies build products as part of their value proposition to their customers.  Another way to say this is that customers buy solutions, not software.  Still pretty simple.

These two paragraphs are orthogonal.

I am not suggesting that a project's community does not build packages, test, document, support, or maintain their project software, BUT once a commercial transaction between a customer and an organization takes place, the customer's expectation needs to be met.  It requires a customer and a company and money to change hands. 

Until the buyer puts their money where there mouth is, they're not a customer.  For an open source project, they're simply a user.  Contrast customers with community (users and contributors).  Love them both.  Respect each of them for what they bring to your company.  Do not mistake one for the other.  [Insert my favourite Mårten Mickos quote here.]

Companies can use free and open source software as part of their solution.  To "build" versus "buy" in their product development processes, they can now add "borrow" and "share".  A company can use collaborative development as a community engagement technique.  Instead of traditional push selling they can hopefully develop a large user community (which has tremendous value in its own right) that they can then turn into customers.  It is a set of techniques (tactical or strategic depending upon the company's use).  Nothing more; nothing less.  Mike Olson is right -- there is no "open source business model". 

Customers care that they're buying "open source" and "free (Libre!) software" or that your product is "disruptive to the incumbent" as much as they care about how many patents you filed, the language you wrote the software in, or your accounting practices.  They do care that you provide value for money, and that the solution meets their needs.  Their needs may even include source access, but since most "open source" companies get concerned when customers touch the code themselves, crying support fouls and warranty violations, it would seem the "customer" really needs to be a project "user" for such things to work to meet their needs. 

Some customers may participate (as user or contributor) in your community or the communities in which you too participate (as user or contributor).  This is a great customer engagement mechanism, hopefully developing trust, demonstrating expertise, and exchanging ideas.  It's as important as the rest of your customer service practices. It may even be a better way to have conversations with customers (current and potential), than old style sales and marketing techniques. 

So does this mean we're now going to need to debate and define whether they're an "open source customer"?  Or a "free software user"?  Will that debate center on how much they use?  Or buy?  Or contribute?  Or whether they also bought and use closed source products?  What if they paid a consulting services organization to build a solution, and contributed some of it to an open source project? 

Tempest, meet Teapot.  Teapot, Tempest.