Once More unto the Breach

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.

Open Source Business Practices and Conversion Rate Myths

[Update: 3 March 2009, 12:13] Added some more ideas here.

With the Sun Microsystem recent move to acquire MySQL AB, open source business models will be a topic of much discussion again. MySQL AB, like Red Hat, has always been one of the examples everyone points to for how an open source business should be run. One of the oft quoted statistics of the MySQL business is "one customer for every thousand users". This number is then quickly put into context as "probably too big" because MySQL is available in so many places that trying to count downloads and users becomes impossible. When JBoss was acquired by Red Hat, the publicly acknowledged conversion rates were 3% (JBoss) and 10% (Red Hat). People start making assumptions about business models based on driving downloads and user community size. And that's where the problem starts.

That's an order of magnitude difference. In a bricks-and-mortar world, business differences measured in a few percentage points are spectacular when comparing company ratios. In a digital world, where the cost of goods sold and marginal cost differences change, it doesn't seem right that we would be seeing orders of magnitude differences between companies for this type of ratio.

I participated in a recent informal (qualitative) survey around purchased support for Linux systems. [It was definitely NOT quantitatively or statistically significant. But anecdotal evidence can be interesting.] In operations of 100 servers or fewer, no one even considered buying support from their vendor for ANY of the servers. In operations of greater than 1000 servers, no one questioned buying support for ALL of their servers. Even "small" operations of 100 servers were still mission critical.

Somewhere in the order of magnitude difference in the server farm size, buying priorities change IT budget allocations. Maybe it has something to do with relative percentages of the budget spent on hardware/software/support versus headcount/expertise. Or with the cost of downtime to the business for a particular application environment. (A friend with a "small" server farm of ~100 servers told me recently they didn't hesitate to pay for JBoss support while migrating a critical application from a BEA Weblogic environment, but didn't consider paying support on the Linux servers themselves.) Or maybe it has something to do with the relative margins of the business. But I'm pretty sure the change in buying habit has more to do with the customers' business needs than the vendors' distribution practices.

Regular readers of this blog have heard me rail against the idea that open source is some sort of different business model. (Again, I'm not talking about collaborative software development in community here, but rather businesses that use such software.) It's definitely an area we need to go think about some more, figuring which software business ratios are significant and which practices to encourage.

Open Source Business Innovation and the Subscription Model

Stephen O'Grady has a great post (as always) on how companies using free and open source software in their customer solutions can make more money for their investors.  Companies like MySQL, JBoss, and Red Hat, and now Canonical have all developed subscription offerings based on value added networks.  There's good commentary from Javier Soltero (Hyperic CEO) and Zack Urlocker (Product VP at MySQL) as well — companies that are exactly engaged in this business.  One of the business model innovations from the FOSS world that often goes unsung is exactly this subscription network model. 

Traditional software companies have dreamed of "subscription revenues" for at least the last 7-8 years.  These packaged proprietary software companies all claimed to want the smoothing of their revenue curves and its attendant predictability.  They all speak in terms of "regular utility payments like your cable or phone or water", as if they actually want to be treated like commodity regulated utilities.  Of course they don't want to be REGULATED like essential services.  Of course they also don't want their pricing structures to reflect commodity pricing because of the unique value their technology represents.   ("Commodity software?  That's what open source is!")  So they're left innovating small variations on maintenance and support agreements marketed as "Enterprise Agreements".  And in large enterprises, these often end in Faustian deals negotiated with the friendly Draconian procurement departments.

Companies using FOSS in their solutions are delivering on a real subscription for value model.  In each case they make it easier to use their solution (convenience = value) and easier to derive more value out of the solution (better ROI and better enabled new business opportunities), not simply easier to pay for it.  Their networks each provide unique product related service beyond "support and maintenance". 

These network subscription models also have another side that perfectly fits the "conversion problem" faced by so many open source software providers.  [Insert classic Marten Mickos time/money trade-off quote about the early/late community here.]  Subscription services are something that might scale well in the DOWNWARDS direction to enable more community users to become company customers.   

Traditional packaged proprietary companies invariably end up caught when trying to reach new "low end" markets.  (And that's when they even perceive they're missing a market opportunity that will evolve into their technology space or profitability profiles over time.)  Their only perceived option is to hobble existing functional products, but there's no easy way to do this from an engineering perspective (most of the time), and there's invariably an internecine war fought in product marketing over market cannibalization and lost profits.  See any of the struggles Microsoft has gone through in emerging markets or in the Vista menu of price/function options for examples of this. 

By designing the network offering with a little forethought to this problem, a branded scaled set of offerings can be put into place that may well serve the low end user today to gain a small value add revenue stream scaled across the thousands of users that are not yet customers, will scale as these new customers evolve, but can also serve the existing larger enterprise customer base.

It's not that traditional packaged/proprietary companies couldn't think about such businesses, but their existing margins and profit profiles don't typically allow them to work this way.  New companies with open source software focused solutions have the advantage here, necessity being the Mother of invention and all. 

Open Source Business 3 + 3

Mikko Puhakka began a challenge on his blog yesterday to list three success factors and three things to avoid when building businesses using free and open source software.  He then tagged five of us to jump on. (Mårten Mickos has already responded.)  So, here goes based on what I've seen and done: 

Three ways open source software can benefit your business:

• Open source software is a great way to enable innovation on your platform.  We all know there are shrinking orders of magnitude differences between the number of people that use your software, to the number that report bugs, down to the number that deeply contribute BUT those contributions can be golden in keeping the creativity and ideas flowing, as well as just plain brilliant direct additions to your product space.  There is no predictability as to when such contributions arrive, but they won't arrive if you don't make the software available. 
• Your community of users is an incredible asset to spread the word.  It's not just about people using your software for free and telling other people about it, but rather the fact that developers will start taking it to work and it will sneak in under the floorboards.  This is how the PC revolution started.  It's why Visual Basic is still huge.  It's how the Linux revolution happened.  So too with MySQL.  And then the CIO discovers it and they need to treat it as a proper product asset just like any other asset on which the business depends.
• Use open source software to rapidly develop new product complements for your solution.  It helps amortize the cost of development/support/maintenance across the community of developers/users/customers/partners/competitors.  You must, however, be a good community player. 
  

And three "ideas" to avoid when thinking about open source software and your business:

• Just because you published the source code does not make your product any more remarkable to your customers.  At the end of the day, you have a business to run, and that means customers need solutions to their problems.  A mediocre solution won't become "better", or the wrong solution won't suddenly fit the situation, because the source code is now available.
• Understand your value proposition and your core competency, and choose your license wisely: if your entire core competency that enables your core value proposition to your customers is embodied in the software, DON'T publish it in such a way that you give away the company.  I have seen a situation in the security world where the software solution was everything.  If they had made the software available under the wrong license, they would have essentially given away their future growth.
• Just because you published the source code does not mean the world is going to work for you for free.  It's been a while since we saw this level of naivety with the original Mozilla launch from Netscape, but I'm betting there are still a lot of business people that don't understand open source software economics that still have old ignorant opinions. 
  

So whom to tag next?  I'll reach for:

• Michael Tiemann (an early and original player),
• Manel Sarasa, OpenBravo CEO (keeping with growing interesting companies in other parts of the planet meme),   
• Jonathan Schwartz (because a big company opinion is always good to have, and Jonathan is nothing if not original in his thinking and his willingness to push the envelop),
• Stephen O'Grady (to get the analyst opinion in early), and
• David Skok (to get an interesting investor opinion)

Okay.  I can't stop here.  Three more opinions I think would be important to have:

• Javier Soltero, Hyperic CEO (because like Manel he too is in the throws of carefully building a company),
• Taiwen Jiang "D.J." (because China is coming)
• Amy Jiang (because China is coming, and Ubuntu is just plain important)

And Christopher Kuhn at OTRS jumped on board as well. 

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!

Oracle and Red Hat Redux

I've been asked several times since arriving in Beijing what I think about Oracle's recently announced move to support Red Hat linux cheaper than Red Hat prices it. I've certainly been vocal in the past about Oracle and their possible Linux distro.  Dave Gynn and I were having this discussion before I flew to China.  So here's how it lays out.

It's Good for Customers:
It is certainly going to create some perceived competition for Red Hat.  r0ml has told the story of his time at Merril Lynch and his frustration with Red Hat's support and maintenance pricing.  He was happy to pay maintenance on each and every machine in his server cluster.  However, paying for a fixed number of support calls on each and every machine in the cluster rather than a cluster wide number of calls was a little frustrating.  With competition comes creativity, and I have confidence that Red Hat will meet the pricing challenge with an appropriate customer valued offering. 

It's Good for Oracle:
I was pretty vocal in the Spring and Summer about how it would be engineering inefficient for Oracle to eat the cost of maintaining an entire "forked" distro themselves.  Ellison was pretty clear back in the Spring, however, that Red Hat wasn't meeting the needs of his customers with updates, etc. 

Instead of living on a complete fork, Oracle will now ensure the stability of their offering to their customers by supporting them directly with the necessary patches.  This is certainly less expensive than running their own distro.

It's Not Necessarilly Bad for Red Hat:
There's certainly been lots of doom and gloom voiced about Red Hat's future and speculation about whether or not Oracle wants to weaken Red Hat to acquire it.  There's been lots of had wringing about the future of open source software businesses as more "big vendors" get involved. 

Piffle.

First, Red Hat's business continues to grow at a nice pace.  There are lots of new Red Hat customers (and existing customers expanding) that are not Oracle users and that still want the level of service and support provided by Red Hat.  These types of customers aren't going to flock to Oracle for "cheap" support, because that's not what Oracle is actually going to be good at.  As MySQL and Postgres deployments continue to grow (possibly on Red Hat linux), Oracle will also have a different set of things to worry about.   

Second, it's actually an opportunity for Red Hat to re-open discussions with Oracle about providing support for Red Hat Linux that meets Oracle's needs.  It would still be more engineering efficient (likely) for Red Hat engineers to do the work for Oracle.  So Oracle would win, and Red Hat would continue to reap the back end (reduced) revenue, as Oracle continues to drive deployments. 

Lastly, Oracle is participating in the open source community, just like IBM, Sun, Novell, and every other vendor of note.  Each participates to their own needs, contributing appropriately in community.  Saying that "open source software" is at risk suggests that each of these vendors has the same motives, to somehow bring down open source by turning it back into a proprietary world.  That's just clearly not true, even if it were possible.

Post to del.icio.us
digg it

Oracle Linux Rumours Continue

Rumours began in the Spring around Oracle delivering it's own Linux distribution and resurfaced this week during LinuxWorld on Jeff Nolan's blog, where the rumour suggests the Oracle version will be based on Red Hat's distro.  The fun bit was Jeff's update to his entry:

UPDATE: Oracle’s investor relations group is now saying that the announcement will be pushed out possibly past OpenWorld in October.

So apparently Oracle remains coy about the rumour.  My opinions haven't changed from the blog posting I wrote in the Spring.  Oracle taking on its own distro rather than continuing to contribute to the community is engineering inefficient and a waste of shareholder money, and it doesn't solve the customer's problem any better.  If Red Hat  is unreasonably behind in delivering the platform to Oracle's needs, they could better invest in the relationship than in undertaking to take on their own distro based on Red Hat. 

Dave Gynn and I were part of an email discussion, and he gave me permission to share his ideas as well: 

Creating a distro based on Red Hat ties Oracle to Red Hat's release cycle and roadmap.  It will be difficult and expensive to offer support for Red Hat that can compete with Red Hat's own Red Hat Network offering.  Oracle is just an expensive middleman whose value is unclear.

If anything, this only makes Red Hat stronger.  Oracle will be required by the GPL to make available any modifications they make.  So the Red Hat codebase will benefit.  Developers will continue to target Red Hat since applications that work on Red Hat should work on Oracle's derivative distro.

With their own distro, Oracle will neglect support for the Oracle database and other applications on other Linux distros.  Open source databases like Postgres and MySQL which run well on all distros will continue to be a more flexible solution.

There is no reason to believe that an Oracle Linux distribution would be compelling or successful. 

Well said.  Oracle is still very like some other software companies, praising open source on the one hand around Linux, but with contradictory rhetoric on the other hand around such things as Postgres and EnterpriseDB and MySQL.  Oracle Linux, or Oracle Red Hat Linux, would be bad business for Oracle. 

The Spring posts:

• Oracle Linux: Novell or Red Hat? (Hopefully Neither!)
• Oracle and the Red Hat JBoss Acquisition

Post to del.icio.us

Patents, Red Hat, and Hibernate

Updated [30-June-2006, 14:45]:  Jan Kechel has created a website which is dedicated to collect prior art against this patent, but I didn't want his work lost in the comments. Please see: http://helpredhat.dyndns.org

News is breaking on claims by Firestar Software that JBoss (now Red Hat) infringed a particular patent in the Hibernate 3.0 software release.  Hibernate is an open source project started by JBoss and forms part of their JEMS product suite. 

• There's a good summary here with reference to the tactical timing of Firestar's attacks, and appropriate pointers to the claims and prior art debate that will rage.
• Bruce Perens has commented here, and once more argues that patent reform is the only thing that will save software from software patents. 

I participated in a panel discussion on the future of open source and IP hosted by SDForum in January.  The consensus of our group (mostly lawyers with a lot of experience in IP law and open source) was that the business economics of the situation would actually prevail before legislative change in a system constrained by deep pockets in other industries with different dynamics and entrenched views.  A few messy law suits, and rulings similar to the recent U.S. Supreme Court decision on damage and injunctions, and companies will begin to realize that software patents make bad business investments, and they will spend their dollars on more urgent and important things. 

This current lawsuit will run its course.  The other organizations that have open source patent protection mechanisms (e.g. The Open Invention Network, and the Patent Commons Project hosted by the Open Source Development Labs) will get to test and tune their organizational responses.  Microsoft will make statements about the value of intellectual property, and quietly fret about the lawsuit's outcome. Stories and counter-stories will be told. 

The most important thing to remember is that a patent is just a ticket to a negotiation.  Firestar may have thought it was going to be clever and make some quick cash on this suit in its timing.  One doesn't even need to ascribe malice and malevolence (or Microsoft as was suggested in one report) to the plaintiffs. 

I've been in enough executive meetings to virtually hear the discussion that would of ensued over whether or not this investment (i.e. the patent) was or wasn't viable, and whether or not it should or shouldn't be used and defended, and where the (fiduciary) responsibility lay.  Lawyers would be hired (increasing the investment) and the decision made to "see what happens."  Especially if Firestar's business is in a bit of a slump.

As was pointed out, however, Oracle and BEA and possibly even IBM and Sun (through the effects in the Java Community Process and the Java Persistence API) may have an interest to defend here.  Certainly IBM and Oracle would like to see Red Hat continue to thrive and prosper, even if BEA and Sun interests are merely defensive. 

These other companies need not even name themselves to the suit, but may start quietly helping in the background. Firestar's legal team may discover it is up against a far nastier negotiation than they anticipated, and regardless of their belief, opinion, and advice, the Firestar executive team may not have the stomach to fight if it means throwing considerable more money at the "investment" in the patent, or the negotiation.  SCO Group's "business" might be a law suit, but Firestar's may actually still be software, and their responsibility to invest in customers and products may quickly become more clear. 

Depending how creative Firestar's executive team is and how the product is structured, they could even turn this into a PR win by joining the community and broadening their customer engagement through selective participation in open source projects, rather than spending money on litigation.  This of course makes huge assumptions about how much imagination is left at Firestar. 

In all of this I remain fond of David McGowan's quote from the end of his May 2005 presentation (and paper) at the University of Toronto:

“If the F/OSS community wants to be in the 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.”

Other patent related posts on this blog:

• A patent is merely a ticket to a license negotiation (Feb 2005)
• Corwin's Razor and the OASIS IPR Policy (Feb 2005)
• An Interesting Juxtaposition of Microsoft and Patents (Mar 2006)
• Massachusetts, Microsoft, and Open Document Format Standards (Sep 2005)
• IBM, Patents, and Open Source Software (Jan 2006)
• More on Open Source Risk Management and Licensing (May 2006)
• Open Source Software Business Models at USENIX (Jun 2006): This is the audio from the panel discussion with comments on software patents by myself, Mike Olsen (Oracle/Sleepcat), Miguel de Icaza (Novell/Ximian), and Brian Aker (MySQL) in the middle MP3.

Post to del.icio.us