Once More unto the Breach

882 Patents

So I'm confused. (Not an unusual state for me, I know.) From the Novell acquisition 8-K as referenced in Andy Updegrove's excellent indepth analysis of the deal so far:

The Patent Purchase Agreement provides that, upon the terms and subject to the conditions set forth in the Patent Purchase Agreement, Novell will sell to CPTN all of Novell’s right, title and interest in 882 patents (the “Assigned Patents”) for $450 million in cash (the “Patent Sale”).

N.B. I'm presuming "Assigned Patents" in the above quote refer to the 8-K, and not the USPTO terminology below.

Taking a quick look at what the USPTO has to say about patents Novell owns as assignee, we find:

• Patents with Novell as Assignee Name or Novell as Inventor Name: 467
• Patent Applications [published] with Novell as Assignee Name or Novell as Inventor Name: 290

So 757 patents and applications. Even adding Attachmate's patent portfolio (14 plus two applications) doesn't really make a difference. I don't know how many "unpublished" patent applications exist in the mix. I don't know if there are a pile of provisional filings that don't show up in the list. I don't know if there are patents outside of the USPTO that are different (unlikely) or overlap in different jurisdictions (in which case one wonders at the import of them if only ~100 were cross-filed. Even doing a search through the USPTO "Patent Assignment Database (Assignments on the Web)" only brings up 775 patents with Novell's name on them.

So to me (naively) it looks like Microsoft vacuumed up the Novell portfolio because it could. I find it more interesting that US$450M was paid for the portfolio. That's about a half million dollars per patent. That seems like a rather large premium when the average patent is supposedly worth about US$75K to file and maintain over its lifetime. (Investors should be curious.) I'm betting it has more to do with Microsoft having a lot of cash and needing to make the overall deal terms palatable to all the partners. So as Brian Proffitt pointed out, I'm not sure things are any more dire today than they were a week ago.

Open Source Software Economics in Pictures

Updated [22-Mar-2010]: Added a little text around the Ohloh javascript widget so Google Reader sees a URL to follow.

Recently, I've encountered several technologists that still don't understand open source software economics and got suitably cranky about "people giving away software for free" and "destroying the value of innovation". I thought it time to try to reach for an easier way to demonstrate what's happening in the industry in pictures.

Everyone is familiar with the idea of a normal "bell curve" distribution representing R&D investment over time. As a technology is better understood and a product succeeds in the marketplace, R&D investment increases, and over time as new technologies advance, the R&D investment in the original technology and product wanes. The integral represents the total R&D investment over time. The function can also represent the "knowledge" gained or the increase in the intellectual asset base.

Good companies develop and invest in new successive waves of sustaining technologies. So, looking at Microsoft's success with PC operating systems, DOS was replaced by a greater investment in a more innovative Windows, was replaced by a larger investment in a more innovative NT.

This also fits nicely with Christensen's original observations about incumbent companies being good at sustained innovations and well run companies knowing how to jump from technology to technology along a sustaining innovation path. This all makes sense when considering a single company's R&D investment. It applies equally well to Sun Microsystems when considering that the steeper slope of successive sustaining innovations was on the hardware side versus the slower (but not inconsiderable) investment from SunOS (a BSD variation) to Solaris.

The investment curve for projects like Linux and Apache, with lots of individual and corporate contributors, still looks like a bell curve, but the contributions might better be viewed as a stacked bar chart. Individual contributors invest to meet their specific needs. Because there is enormous overlap in their common needs, they all share the overall investment.

Individual contributors get enormous return on their investment. (One gives a few bug fixes to the Apache httpd team, and in return one gets an entire HTTP daemon.) Corporate contributors give for the same ROI. They get enormous return on their investment in technology they use in a product complement space or as a component in their overall solution to the customer. (Before someone takes issue with my Red Hat example above below, understand the "solution" in the customers mind was "UNIX-like servers on inexpensive 'PC' hardware" and not "Linux".)

Christensen was careful in subsequent work to point out that the disruption wasn't about technology but about business model. The disruption often started when someone assembled standard cheaper lower performing parts into a solution that solved a completely different need with a very different cost basis. The new solution begins its own sustaining innovation curve until the new technology can compete with the incumbent compared against the criteria about which the customer/consumer cares.

The disruptive business model isn't about Linux so much as the ability for corporations to do collaborative development at the component/complement level in a "frictionless" well-managed Internet-enabled community. (The original OSF/1 shared-development of a UNIX-like replacement failed: too few players, too much politics.) Linux is a much stronger disruptive business solution as a way to handle a particular sourcing problem.

It would be interesting to consider the difference between projects with enormous inbound code contribution (versus all the other strengths a well run community brings to the table) distributed across a wide group of players like we see in the Linux and Apache projects, versus projects managed more tightly by a company like MySQL was. Another interesting attribute of this collaborative business model to investigate is how contribution mutates over time. Christensen's work demonstrated that an incumbent gets in trouble when they begin to over-deliver on functionality for attributes their customers consider important. The customer can't absorb the sustaining technology innovation any faster and literally won't pay for it. The slope of the sustained innovation of the competing technology is sufficient to cross into the space covered by the incumbent's solution.

In a shared collaborative development environment, however, because the technology isn't being driven by a single corporate entity, the community of corporations collectively contributes to their own needs and the technology may (i) stabilize where it needs to stabilize, and/or (ii) be taken in new and interesting directions. There is less pressure (if any) to over-deliver with new innovation. The consumers are the developers, but it's a very broad community indeed. This is what I believe just happened with the MeeGo announcement and the combining of the Nokia Maemo and Intel Moblin projects. This is a great inflection point for Linux into the new mobile Internet device space.

One only need read the report from the Linux Foundation charting the growth statistics in the Linux kernel to understand the enormous value generation happening release-on-release, four times a year. Using the Ohloh rules-of-thumb of US$55,000 per person year one gets US$142M of value creation in the 2.6 Linux kernel. The fact that some business models have been destroyed (Sun), or threatened (Microsoft) doesn't mean there's not enormous ongoing value creation in the technology.

Ohloh value chart for Linux 2.6 kernel.

Neither is intellectual property being "destroyed". Again, this is a disruptive business model discussion. Intellectual property is a business choice made on how a company will protect certain intellectual assets as legal property. Which assets to protect, and how, and which property to defend is a business choice based on the cost model a business uses with respect to turning assets into value propositions customers will buy. When a group of companies chooses to collaboratively develop a technology complement/component, they're making a business model choice on how they will selfishly share certain intellectual assets. Nothing was destroyed along the way.

IT Customer Buying Patterns and Vendor Competition

Tail light chasing your competition means you will NEVER own a concept in your customers's minds. Matt Asay recently blogged about Novell's continuing practice of chasing Red Hat in the Linux market rather than defining itself on its own strengths, (in this case offering support for Red Hat servers cheaper than Red Hat). He rightly addresses the woolliness of their thinking and closes by saying:

Instead, Novell should be focusing on the things it does really well, like its powerful SUSE Studio technology, which makes it super easy to build Linux-based appliances. Novell is never going to be a better Red Hat than Red Hat. It should focus on being a better Novell. That positive message is what CIOs buy.

The post also includes a fragment of a leaked memo from a Red Hat country manager crying foul against Novell in a memo to a customer. Some consider this a sign that Red Hat is beginning to misbehave in its arrogance.

Here's what I think Novell is up against: Is the customer "happy" with Red Hat is the wrong question. This applies equally to both pricing and arrogance issues. There are few inflexion points to grab. Novell's opportunities aren't around offering cheaper support, but have to be looking forward to the next ground they can grab in customers's minds.

From my historical perspective as a customer, (and this was confirmed in recent discussions with CIOs I trust), customers never "trust" vendors, and in fact expect them to misbehave to maximize their own revenue. Customer organizations manage their IT budgets as a portfolio (especially large complex organizations with lots of "platforms" to support). Switching solutions means retraining, instability in something complex that isn't "broke", and the savings would need to be enormous to consider the conversation at all. And it's not enough to save a lot on the specific vendor competitive situation because the customer is actually judging the savings against their entire portfolio.

Let me borrow an example from discussions and a blog post from three years ago. Saving even 50% per year on a Red Hat support contract by switching to Novell is irrelevant. The risk of instability isn't balanced against a commensurate savings in the overall budget (against say the IBM or Oracle annual spend), or new value-add to the company. It's not worth the conversation. Matt rightly points out that the savings of moving from Red Hat to CentOS is 100% and the form factor exactly matches Red Hat. Is the customer "happy" with Red Hat is the wrong question. They're not unhappy enough with the value-to-conversion risk to make the conversation interesting compared to all the other more interesting value generation projects they're undertaking or savings in the ugly parts of the budget.

What this means is that once established, there are few opportunities for the 2nd place guys to break-in. The market leader already owns a concept (or concepts) in the customer's mind. It's not about differentiation. It's about owning the differentiation in the customer's mind. ("We're cheaper" is already owned by CentOS.) You need to catch the next technology wave and own a particular definition faster at a time when the customer technology office is already at an inflexion point so a "new" vendor is an obvious part of the discussion. For Novell, this might mean positioning all the great technology in SuSE Studio on cloud appliances for the intranet. Today the message seems to be focused on getting more ISVs to compete with Red Hat's perceived success with ISVs. Positioning this technology to solve the ISV problem backwards is irrelevant. (Near as I can tell Red Hat and Novell each have roughly the same number of ISVs and I'm betting there's substantial overlap. Red Hat has again created the perception that they have more ISVs in a customer's mind. They were likely first to grab the ISV market, and they have entrenched the concept in customers minds.)

Nobody knows what cloud computing will mean for the large organization IT shop. Positioning SuSE Studio as the perfect way to "build virtual internal application appliances for your internal cloud", with all the supporting materials, examples, tutorials and the like is a possible way to own "in-house application appliances" in the customer's mind before Red Hat or IBM or some clever start-up comes along and does so. Then Novell can talk about the value proposition of SuSE as a secondary complementary [larger] revenue stream. Following Red Hat means you'll always be second.

Acacia Patents, Red Hat, and Novell

Groklaw reports a patent infringement suit has been launched against Red Hat and Novell over Linux.

Take a deep breath. Be calm.

When the SCO Group suit was first launched, I was still at Microsoft. A number of people in the strategy team where I worked were excited because "finally the free and open source world was going to understand the importance of intellectual property." (These Microsoft employees didn't appreciate exactly how careful the community is about IP.)

I pointed out the following logic back then: IBM was investing a billion dollars in Linux. IBM could therefore allow a certain amount of legal debate to occur to determine how real a case SCO Group may or may not have had. A few millions in legal fees pales in comparison. In an absolutely worst case scenario, IBM could acquire SCO Group for O(US$150M) or less after a couple of years of legal punishment and the problem would go away. Again, a few millions in legal fees would be a cheap exploration. The SCO Group suit was NEVER a threat to Linux growth and deployment. Did the FUD slow the adoption curve, no doubt. But did it make any material difference in the use and growth of Linux? Hardly. And it's over now.

Microsoft should itself understand this business calculus around IP. They offered a lot of money to settle the Eolas suit. Eolas got greedy and refused the settlement. They "won" a half billion dollars in court. Now, when you're about to pay out a half a billion dollars, you can afford to spend a few millions more contesting the decision. Indeed, with that sort of money at stake you can afford to hire the cream of the graduating classes of Harvard, Yale, and Stanford Law to spend some time getting creative.

The U.S. Supreme Court continues to involve itself in the broken patent system. The Linux Foundation and the Open Invention Network are both geared for this particular fight. I have confidence that the Groklaw community will step into the breach of reporting and investigation again. IBM, Intel, and HP have a vested interest in the outcome, and nobody plays IP games the way IBM does. Over the next few weeks, lawyers will come together behind the scenes from all the interested parties on the defending side. Hopefully egos won't be too large, and a coherent plan of negotiation will emerge.

Some of the more interesting questions for me will be:

• Why Red Hat AND Novell?
• Why not Microsoft? (Acacia went after Apple who settled. Microsoft would seem to have deeper pockets than Red Hat or Novell. It would seem to be the more interesting business discussion.)
• If Microsoft is not involved, should they be? If Apple settled, and then this suit settles, Microsoft should know they're next on the list. Or are they trusting IBM et al to win this one for them?

To quote one of my favourite lawyers in this space:

“If the F/OSS community wants to be in commercial space, community members will have to learn to deal calmly with IP litigation. The F/OSS production model will work where it makes sense, and it will not work where it doesn’t. It’s really just that simple. Particular claims in individual suits—even one against a flagship program such as the GNU/Linux OS—will not determine the fate of the community. Such cases present factual issues that will get resolved one way or another; they do not represent a crisis for F/OSS production as a whole. Norm entrepreneurial rhetoric that plays off such cases should be treated as entertainment. Enjoy it if you like it, take inspiration from it if you must, but don’t confuse it with the way things actually get done.”

I'm sure some former colleagues at Microsoft are excited. Mr. Smith and Mr. Ballmer most assuredly. But just as with the SCO Group litigation, there is no reason to celebrate. They shouldn't confuse this with "the way things actually get done." Pax.

SCO Group Finale!

Stephen Shankland says it all. 

Copyright ©  Despair, Inc.

Update (24-Sep-2007, 19:35):  A friend pointed this comic out.  I got into this battle while I worked at Microsoft and SCO Group first sued customers.  I pointed out it was a suicidal thing to do if they were a "real" company, and not the anti-VC (i.e. a company that acquires old technology and litigates money out of the marketplace.)  Vendors will occasionally sue customers in 1:1 situations e.g. a license dispute, in a similar way that customers occasionally sue vendors in one off disputes for non-performance, but a vendor NEVER sues customers over general things like IP infringement.  It sets a tone for all customers that is ... suicide.  Your top sales people will simply leave.  They know customers are now viewing business with the vendor as possibly tainted by lawsuits.

I also pointed out that IBM wasn't going to let anything bad happen.  A company investing a BILLION dollars in Linux could afford to weather even a few tens of millions of dollars of legal debate over several years while they determined how bad it may or may not really be.  Frustrating and distracting?  Certainly.  So what?  The customer is king. 

IBM Joins OpenOffice.org (The Quick Analysis)

It's official — IBM has joined the OpenOffice.org project. [There's good reporting and analysis from Andy Updegrove and Redmonk's Stephen O'Grady.  Update (12 Sep): Here's Andy's interview with IBM's Doug Heintzman, Director of Strategy for the Lotus division.] 

Here's the back of the envelop analysis.

From the OpenOffice.org community perspective, I'm guessing Louis Suarez-Potts (OO.o Community Manager) is feeling good to get a new injection of code/energy.  This is great for the community.  The OpenOffice suite keeps getting better and better, but new blood with new code could provide a much needed boost.

Overall Sun Microsystems is probably [very] happy IBM is supporting OpenOffice.org directly.  This is a much better situation than IBM building some form of ODF development platform inside Eclipse.org to enable ODF over OOXML, with OpenOffice.org hit as collateral damage.  [This would be sort of ironic since Eclipse helped to pull the Java centre-of-gravity away from Sun, and Visual Studio was collateral damage (or icing depending upon one's perspective).]  Collaboration is the much stronger market play here for Sun and IBM, and most importantly OO.o users and customers.

From the IBM perspective, this is brilliant business as usual.  ODF is the global leverage they need to crack open the Microsoft Office marketplace.  (I've written ad nauseam that ODF and Microsoft Office is just another example of Christensen economics in motion.  Microsoft has over-delivered on Office.  They mistakenly think more innovation faster is the answer.  Let the chips fall where they may.)  IBM will likely use OpenOffice to front-end Lotus and the Domino server product lines, and anchor their business messages to their customers's needs around standards and open source software, much the same as they do with Eclipse and the Websphere developer world.  Their claims are that much stronger with this announcement.

Sun gave Gnome a huge leg up about four years ago when they contributed a wealth of their accessibility technology R+D.  IBM will now contribute the same into OpenOffice.org.  It means they can easily manage their way through U.S. government procurement regulation in this space.  Once again brilliant IP management from IBM, and good for OO.o users and customers.  [For those that have heard me present, this is exactly what I mean about having a mature intellectual asset strategy, and being generous exactly in order to play to win.]

A strengthened OpenOffice.org will help Novell immeasurably to keep their distance with Microsoft on the desktop.  Novell has done a lot of work with OO.o in the past.  They have a great desktop Linux product.  They can simply take a ride on this one and eat the benefits.  There's really nothing Microsoft can say here.  Regardless of any agreements around OOXML that Novell may have with Microsoft, Novell comes out clean on the ODF front as customers demand it.

I noticed the press release includes a quote from Beijing's Redflag Chinese 2000 Software Co., Ltd., the makers of Redflag Linux and RedOffice.  This is significant.  Apparently last November I was one of the first people to blog about the document format work in China that led to a Chinese national standard (UOF).  Redflag Chinese 2000 was implementing UOF in Red Office (the Chinese packaging of OO.o).  There is work afoot to harmonize ODF and UOF.  And clearly Redflag Chinese 2000 remains committed to the OO.o effort.

So despite the bluff and bluster, the OOXML camp inside Microsoft should not be sleeping well at this point. 

"Don't blink.  Blink and you're dead.  Don't turn your back.  Don't look away.  And don't blink.  Good luck!" — the Doctor

Microsoft, Moonlight, and Open Source Software (and Novell's Brilliance!)

There's been interesting news about Microsoft support for the Novell Moonlight project this past few days.  Miguel de Icaza as community leader around Mono and Moonlight best tells the news on his blog, and points to Scott Guthrie's supporting blog post from Microsoft.  Tim O'Reilly points out that Microsoft will (predictably) support open source software for competitive advantage, in this case against Adobe.  Matt Asay supports Tim with the observation that Microsoft will use open source "where it's weak" and chides the two companies to just consummate the marriage.   

All the Moonlight support from Microsoft is a Very Good Thing for Moonlight and Novell, but let's be clear: Microsoft's participation in Moonlight is NOT Microsoft doing open source software. 

No code has been contributed to a community under a liberal license.  (As Miguel says, "Microsoft will give Novell access to the test suites for Silverlight to ensure that we have a compatible specification.")  No IP has been contributed to a community under a liberal license.  ("The codecs will be binary codecs, and they will only be licensed for use with Moonlight on a web browser".) 

Novell is doing the heavy lifting with help from Microsoft.  And in return, Novell is actually being pretty savvy (despite Matt's regular swipes at them for a lack of open source creativity and strategy).

• Novell is anchoring itself rapidly as the other cornerstone for cross-platform programming between Windows and Linux.  This gives them a valuable community center of gravity with respect to the enterprise that is much more valuable with customers than "we're not Red Hat".  Miguel has demonstrated himself as a brilliant community leader over the years.  Influence and IP control — It's all good for business. 
• It allows Novell to move Mono beyond the patent FUD and "science experiment" label Microsoft has traditionally thrown at it.  [Mary Jo Foley correctly called this one out.]  For Microsoft to renege on this very public initiative, or to try to claim behind closed doors that they like Moonlight but not Mono will demonstrate to customers once and for all that Microsoft doesn't understand the customer cross-platform/interop needs.  While Moonlight may be a great desktop experience, Mono is also all about server-side applications. 
• Before Microsoft gets any [BROKEN!] ideas around trying to jam yet another unproved specification through the standards process, Novell is anchoring the specification with a second high profile external implementation on another platform.  [This is a Very Very Good Thing for everyone.]

Microsoft certainly gains in the bargain as well.  They get to maintain a position on a multi-platform field they would otherwise forfeit to Adobe's open source maneuvering and market history around Flex and Flash.  They get to be seen publicly collaborating on Linux-based technologies so as to foster the belief with customers that they do genuinely care about cross-platform interoperability (and anchored around C# and .NET technologies).  They may even be in a GREAT position with respect to some customers to be the single source vendor of platforms when one considers the other collaboration deals in place with Novell.  It's win:win for each of them. 

But it's not Microsoft doing open source.  When we start to see Microsoft developer participation in the public code contributions for Moonlight, then they can claim to be "doing open source."  Regardless of the open sourcery of it all, however, it will be fascinating to see where this initiative goes.

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.   

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!

Three Things Steve Ballmer (and Brad Smith) Get Wrong about Free and Open Source Software

Enough, Mr. Ballmer, please. 

There have been a rash of articles over the past week on Steve Ballmer's recent statements about open source software and intellectual property during the New York financial analysts presentation.  They follow on other recent related statements around the Novell-Microsoft deal by Brad Smith, and the Progress and Freedom Foundation.  Here's what Ballmer et al get wrong:

• Customers care about patents. (The corollary that vendors sue customers over patents, and that this is why customers need care is patently (sic) false.)
• Free and open source developers don't respect intellectual property.
• People think free and open source software is free.

Let's handle them in reverse order. 

Open Source Software is Free
Wrong.  And no one thinks this.  Mårten Mickos brilliantly observed two years ago that the early community is willing to trade time to save money, and the later community is willing to trade money to save time.  But neither the do-it-yourself users or the pay-as-you-play customers thought anything was "free".   They each made an economic decision based on their particular needs in context.  Anyone that ever paid for a Red Hat Advanced Server installation or a Novell SuSE desktop or MySQL Network knows that the solution isn't free, even if they didn't pay a software license fee.   

Microsoft continues to think that free and open source software sits at one end of a spectrum that has commercial software at the other end.  They apparently still don't realize these two ideas are orthogonal.  Really. 

Free and Open Source Software Developers Don't Respect IP
Wrong.  First, F/OSS licensing is completely dependent on strong IP (copyright) law.  Second, key projects generally have contributors license or assign the rights of their contributions to the project owner.  This is no different than Microsoft licensing third party code for inclusion in Windows or Office.  The terms and conditions bar might be higher for Microsoft because of the business and litigation risk they take, but the legal concept is the same.  Brad Smith suggesting otherwise is disingenuous at best for a lawyer.

Mr. Smith would obviously point out that the sort of licensing Microsoft does includes discussions around patents, something most (but not all) open source software licenses do not discuss.  This is because patents are a vendor-to-vendor discussion, and not all open source software projects are necessarily run by commercial vendors.  (This may explain why vendors with patents also make interesting patent grants to open source projects in which they participate.)

This discussion also flies in the face of the reality of vendors with more mature IP strategies than Microsoft's contributing heavily to free and open source software projects.  These other players seem to be extremely respectful of IP, yet they find their business strategy includes F/OSS.  Makes you wonder more at the lack of imaginative asset strategy at Microsoft. 

Customers (Should) Care about Patents
Wrong.  Patents are tickets to negotiations in vendor-to-vendor discussions.  Customers could care less.  I started this blog two years ago with a short essay titled "When are you going to sue your customers?"  In it I use the following example:

Legal IP tools are important for vendors and certainly relevant in vendor-to-vendor discussions.  The idea that customers care about patents, however, would seem counter-intuitive.  Consider the following: when you last bought an automobile, did you pick the “Honda” over the “Toyota” because the Honda had more patents in it, or more patents per ton of vehicle, or maybe because Honda's intellectual property practices were “better” some how?  Of course not.  You bought the product that met your needs.  It may well have even been the more innovative product by your own subjective measure, but whether or not the manufacturer chose any number of legal tools to protect the innovation wasn't part of your buying consideration.  How the vendor's business process works is of no interest to the customer beyond the actual customer-vendor interface so to speak.

Whether the vendor has a mature IP strategy, applying for patents, trademarks, and copyrights appropriately, choosing to keep some ideas trade secret protected, sharing selected IP with partners or competitors through patent pools and cross licenses, or aggressively publishing some ideas in the face of their competition is of little interest to the customer. The customer only cares that the product serves their needs and provides the value they paid for it.

Next scenario:  you are happily driving your Honda when you receive a letter from Toyota one day telling you that you're infringing their patents. They give you the choice to (a.) cease driving your Honda, or (b.) pay them a license to their patents.  You can essentially “pay twice” for the privilege of driving your car, and for some small sum you can feel free of any concerns that you are infringing Toyota's patent claims ever again.  On this vehicle.  Or for your household.  Or maybe it will be offered to you the customer as an annual license calculated by the number of drivers in the house and the number of Honda vehicles you own, pro-rated over certain uses, unless the patent applies to certain other manufacturers as well. What do you do?  Do you even waste time calling your lawyer to figure this one out?  Or do you call the Honda dealership and tell them quite simply to “fix this.”

Of course this assumes you don't also receive letters from General Motors for their patents (frustrated that North Americans are buying foreign vehicles), Daimler-Chrysler, and Hyundai, so you have the opportunity to “license” your Honda vehicle from many companies and pay for it numerous times. [srw -- this is WHY patents are a vendor-to-vendor discussion.]

The reality, however, is that Toyota is not going to threaten to sue Honda's customers.  They would like the opportunity to switch those Honda customers to Toyota's products, not upset them to the point that no Toyota dealership ever gets a chance at that Honda customer again. 

If anyone sued a customer company for patent infringement over its use of Linux, the company being sued would find a lot of "friends", starting with the Linux Foundation.  One might even imagine the company having a negotiation with IBM over opportunities for IBM to sell in other unrelated areas in return for help on the Linux litigation front.

Jeremy Allison recently mentioned in an interview that "I have had people come up to me and essentially off the record admit that they had been threatened by Microsoft and had got patent cross license and had essentially taken out a license for Microsoft patents on the free software that they were using, which they then cannot redistribute. ... But they’re not telling anyone about it. They’re completely doing it off the record."

This is hugely disturbing.  It means these companies are essentially giving into a market bully.  They certainly aren't serving their share holders.  If Microsoft is so gung-ho on the idea that this is a good thing, then THEY should come forward with the who and the how so we can all take a look.  The fact that this may be happening in secret does not put them in a good light at all. 

The Novell-Microsoft technical co-operation agreement around virtualization, web services, and document formats is no different than any other vendor-to-vendor tech co-op (marketing) agreement.  It's business as usual. 

The Novell-Microsoft "agreement to provide each other’s customers with patent coverage for their respective products" is no different than any other vendor-to-vendor cross license deal at the end of the day.  Microsoft wants to message it around open source software (Linux specifically) and IP and customers, but that's actually irrelevant. 

What other patents do these two companies have?  As much as Microsoft loves to maintain ambiguous IP messaging around Linux and patents or the Novell sponsored mono project and patents, the more interesting question is what historical patents Novell may have that might read on operating systems or file systems.  This scenario would be far more damaging for Microsoft than for Novell in a patent injunction shoot-out on revenue streams.  Cross licensing is just good business for two such vendors.  And customers could care less.

Culture comes from the top.  For all the good work that Bill Hilf's team may be trying to do, Ballmer's message is damning.  Ballmer's is the message that will be carried by the Microsoft field organization.   He's the CEO.  And it's doubly damning because Ballmer's message on this issue has no credibility anymore.

If Microsoft really wants to prove once and for all that customers should really care about paying for patents separate from their solutions, then Microsoft should go sue a customer over Linux systems that allegedly infringe their patents.  It would need to be a customer that clearly has a large installed base of roll-your-own-Linux systems.  They should go sue Google.  Or Bank of America.  Then we can all see how important this really is.

Of course Google may well have interesting patents on things like "search", so it would become a negotiation again.  And Bank of America probably spends a lot of money with Microsoft for other things, and it's unclear Microsoft would want to risk such a revenue stream (since they clearly wouldn't be worried about customer opinion at that point). 

At the end of the day Steve and Brad need a new strategy.  (Or a new PR firm.)  This message is growing old, and makes them look unimaginative (or worse, sneaky) in leading a modern high technology company.  Microsoft continues to stand alone in this space.  It's really too bad.