Once More unto the Breach

When NOT to Make Open Source Software

I've been working over the past month with Paula Hunter and the Outercurve Foundation on a short book to introduce executives to the fundamentals of free and open source software. It's based on writing she and I have done in the past with a few new essays. One of the last topics I wanted to tackle is the question of when not to publish software under FOSS licensing terms from the perspective of companies in a position to "make" FOSS software.

Many managers are concerned with creating and contributing to the open source ecosystem for two primary reasons:

• Losing control of the “value” inherent in the IP creation, and
• the liability risks of contributing to or publishing the software.

If liability risk is the real problem, then one needs to be sure that one is comfortable with the FOSS license terms, any terms of service that may be involved in the project’s web presence, and the IP management process in place to vet contributions, regardless of whether one is accepting inbound contributions to one's own FOSS-licensed project or outwardly contributing to another project. There’s not much more that can be done about such perceived risk. A company will either be comfortable with the benefits against the risk analysis or not.

A good measure of the risk however is the number of lawsuits that have happened in the open source space relating to copyright. The few that exist tend to be focused on a company using open source software in their products and services while blatantly ignoring the FOSS licensing terms. Openly and honestly participating in an open source community doesn’t appear to lead to lawsuits. Liability risk is probably not a good reason NOT to make FOSS software unless you have a particular risk profile.

The value of the software published is a very different discussion. People need to be very crisp when discussing value. One should never publish one’s core value proposition to its customers. Geoffrey Moore published “Crossing the Chasm” in 1991, and helped business managers understand the concept of their core value proposition. This was a very customer-focused “core” value. Everything else was a complement around the core. It related to the problem one solved for the customer. In later writings (“Dealing with Darwin”) Moore once again discussed core value, but here he was discussing core competency. It was an inward focused core value, and everything else a company did was context. It wasn’t what the customer bought, but rather how one solved the customer's problem.

Core competencies and core value propositions shouldn’t be published for all to use. If the software you have represents the core competency of the company, or generates a substantial competitive edge, it shouldn’t be shared under liberal licenses. The trick, however, is in understanding the truth about the core competency.

Google is an excellent example of this idea. Google consumes a lot of open source, and contributes back in a myriad of ways. But it hasn’t historically shared certain changes it has made to the Linux kernel, nor does it publish all the tools it uses to rapidly deliver software to customers.

Red Hat is another more interesting example. One could argue they simply publish a Linux distribution. The reality is that they dominate the space because they understand it isn’t the software asset that the customer is buying (and over which Red Hat has no particular ownership or control) but all the value around the software in services and risk mitigation and quality and ease-of-deployment that made Red Hat Enterprise Linux such a great replacement for expensive proprietary UNIX systems, and now an excellent server platform going forward.

There is a lot of software in an organization that isn’t in and of itself mission critical to the value they deliver to their customers. Modern Internet properties like Facebook, Netflix, Twitter, and LinkedIn all collaborate on software infrastructure and publish tools they use because it improves the infrastructure for all. Their value to their customers and their competitive business lock is the data, and in some cases the data in aggregate. Or it will be otherwise unrelated to the software platform, e.g. their ability to deliver customer value through a particular channel at a particular price point. These companies deliver a high-quality robust software-based experience to their customers that would make the average enterprise IT shop envious — and they do it on a software platform on which they’re happy to collaborate.

Software is valuable. It represents an investment in its creation, and delivering good software isn’t easy. But in relation to a business endeavour, the cost of creating it may best be shared through collaborative development because it doesn’t represent the core value of a corporation. It’s context in the business.

An interesting further observation from Moore was that a company’s core competency changes over time. They leave a growing pile of context behind them. Google also provides an interesting example of how a company’s edge changes over time. When they were a young company, the company’s ranking algorithms were critical and it would have been idiocy to publish them. At this point in time, with the value that may have been built up in their indexes, they might well be able to share the algorithm because it only works properly in conjunction with the rest of the structured data they have amassed.

Likewise, Microsoft originally needed to protect the Windows NT core competency at the software level. Now, their competencies may be more around the release processes and delivery channels. While there is a lot of third party software in the Windows product of today that cannot trivially be shared, the company’s value is likely no longer tied up in the kernel software anymore than Red Hat’s value is tied up in the Linux kernel that they don’t own and only influence.

Reliably developing robust useful software is hard work. Liberally sharing software and collaborating in open communities is an excellent way to distribute the costs and gain domain insight and knowledge, regardless of whether one is an individual or a corporation. For companies, the challenge is to understand their real and evolving value proposition to customers and the core competencies that enable them to best deliver to those customers. Everything else can be shared.

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