Once More unto the Breach

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

Oracle Linux: Novell or Red Hat? (Hopefully neither!)

Updated 18-Apr-2006, 13:30: Added the postscript on the Boston Globe quote. 

This morning saw reports in the Financial Times that "Oracle considers venturing into Linux".  This was picked up by CNet (via Reuters) which set up the discussion about Oracle's desire to deliver a entire stack of technology to customers, and then drew attention to the quote that Oracle has even "considered buying Novell."  And thus are rumour mills fed.  Let's actually look at the discussion in a business context:

In an interview with the Financial Times, Mr Ellison said that Oracle wanted to sell a full “stack” of software that, ... included both operating system and applications. “I’d like to have a complete stack,” he said. “We’re missing an operating system. You could argue that it makes a lot of sense for us to look at distributing and supporting Linux.”

Not an unreasonable opinion.  Go all the way back to Geoff Moore and Crossing the Chasm (1991).  You want to present a "whole product" solution to your customer, i.e. your core revenue driver and all the complements you can reasonably provide that your customer perceives as the complete solution to their problem.  If to sell an Oracle "solution" today means Oracle licenses and Oracle vertical specific applications, AND an expensive operating system on expensive hardware, AND an expensive application server, then reducing the overall cost to the customer while driving the core revenue generators would seem to be A Good Idea. 

As part of a recent study of the open source software market, Mr Ellison said that Oracle had considered buying Novell, which after Red Hat is the biggest distributor of Linux. “We look at everything, play this thing out,” he added.

This statement should not surprise anyone that has worked in a large enterprise with a view of the executive offices.  Companies explore ideas on paper constantly in their corporate/business development offices.  Lot's of "what if" scenarios are played out, and numbers crunched without anyone ever committing to doing something.  Companies even pay good money to the McKinsey's of the world for this sort of analysis even if they have their own inhouse "business consulting team". I'm sure Oracle has also run the numbers on Red Hat and SuSE (before the Novell acquisition) and developing their own distribution at various times in the past, and will do so again.   

“Now that Red Hat . . . competes with us in middleware, we have to re-look at the relationship – so does IBM,” he said.

This last quote is the troublesome one (or maybe it's a misquote without context).  Oracle is the enterprise relational database company.  It's been expanding its brand with vertical specific Oracle applications.  It needs middleware (i.e. an app server), like it needs an operating system on which to run, but it isn't a middleware company. 

Go back to the original business goal expressed in the article, that Ellison wants to provide a complete stack or solution to his customer.  Good idea, but he has better ways to spend shareholder dollars to solve customer problems than acquiring the stack outright, and then living with the cultural consequences and long term engineering expenses of becoming an "operating system company" and an "app server company" as well as their primary focus as the enterprise database company.  Spending good money to get into other rapidly commoditizing businesses, rather than serving your customers needs by supporting companies like Red Hat with its JBoss acquisition that already know how to make money in a different margin business seems a waste.

As I suggested Friday, Oracle should be hammering down Red Hat's door to expand the relationship with all the money they saved by not acquiring JBoss, or in this case (hopefully) Novell.

P.S. You have to love news editors.  I was interviewed by Hiawatha Bray from the Boston Globe yesterday.  The quote as it appeared:

But Stephen Walli, vice president of Optaros Inc., an open source consulting firm in Cambridge, said buying Novell or Red Hat would be a mistake for Oracle.

''They would have to carry all that cost on their balance sheet," Walli said. ''I think it would be a really bad idea."

This is why I blog the whole idea.  While accurate, the quote could mean it was a mistake for Oracle's business to carry the engineering expense compared to the value to their solution to their customers (which was meant), OR that Novell or Red Hat are dogs that one wouldn't want on one's balance sheet (which wasn't meant).  Maybe I'm being overly sensitive. 

 

Post to del.icio.us
digg it

Oracle and the Red Hat JBoss Acquisition

The other day I offered up my opinion on the Red Hat pending acquisition of JBoss.  One of the things I discussed was the "what if" scenario if Oracle had acquired JBoss instead.

"If Oracle had acquired JBoss, it could have been an opportunity for Oracle to have grown its core business and revenue streams by making an inexpensive app server available as part of the mix, creating a better overall solution for their customers that need a database, apps and app serving infrastructure.  This is similar to what SAP did a number of years ago with SAPDB (now MaxDB from MySQL).  Oracle could have also used such an acquisition to begin the long and necessary cultural evolution to learn about open source as a supporting development, marketing, and delivery strategy, similar to Novell's long road with the Ximian and SuSE acquisitions.  Or they could have made a complete mess of it, ...."

The Red Hat acquisition is actually the best of both worlds for Oracle:

• Oracle and Red Hat have a long standing relationship.
• The only open source messaging Oracle delivers well is around Linux.  They always fall down when they get caught between praising open source in a Linux context, then denigrating open source when asked about the myriad open source database engines.
• Oracle needs to reduce the complement costs in their overall solution pitch to their customers to better serve those customers against the competition from BEA, IBM, and Microsoft.  (Maintaining the engineering development expense of delivering your own app server with its own support and maintenance burden when you're a database company isn't a great way to do this.) 

Oracle can now deliver the same less expensive overall app serving solution to their customers on a JBoss Red Hat bundle for their Oracle Java app world, through the existing relationship, and consistent with their open source messaging, without having eaten the financial and cultural pain of a US$350M+ acquisition, and its attendant business risks.

Hopefully Oracle is not simply ecstatic — but aggressively ecstatic and hammering down the door at Red Hat to expand the relationship with all the money they saved. 

Post to del.icio.us
digg it