Home Messages Index
[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index

Re: Investment in Open Source Seems Very Rational

  • Subject: Re: Investment in Open Source Seems Very Rational
  • From: "Rex Ballard" <rex.ballard@xxxxxxxxx>
  • Date: 18 Oct 2006 12:28:28 -0700
  • Complaints-to: groups-abuse@google.com
  • In-reply-to: <1161186086.043589.66840@h48g2000cwc.googlegroups.com>
  • Injection-info: e3g2000cwe.googlegroups.com; posting-host=; posting-account=W7I-5gwAAACdjXtgBZS0v1SA93ztSMgH
  • Newsgroups: comp.os.linux.advocacy
  • Organization: http://groups.google.com
  • References: <1161186086.043589.66840@h48g2000cwc.googlegroups.com>
  • User-agent: G2/1.0
  • Xref: news.mcc.ac.uk comp.os.linux.advocacy:1171706
Roy Schestowitz wrote:
> Why would anyone invest in open source? Part two
> ,----[ Quote ]
> | "The big advantage open source companies have over traditional
> | software companies is the ability to rapidly take unit marketshare
> | and create a new standard. The best example of this is MySQL.

Another way of looking at it is that companies can cooperate with each
other to implemente a common "core" standard.  Then they can focus
their development effort on elements that provide product

If everyone wants to implement the same standard so that the systems
can communicate with each other (or risk getting excluded from the
market if they don't), each company can try to do their own
implementation of the standard, and try to test their implementations
against the implementations of the other companies.  If there are
incompatibilities, it could take quite a bit of time to resolve and/or
correct these as well.

If we have 10 companies trying to implement this standard, and it takes
10 staff-years to implement each version, and it takes 1 staff-year to
resolve each inconsistency, you have 100 staff years being spent on
initial implementation, and worst case, another 100 staff-years
resolving the incompatibilities.  At 2000 per year and $200/hour,  200
staff years would be about $80 million invested in "getting it right".
This assumes that there were no actual changes in the standard.  Those
who are familiar with this process know that it can be an unending cash

If on the other hand, each company contributes 1 staff-year to a common
implementation, and everybody shares the exact same source code, the
cost to get the core interoperability drops.  Because each is less
committed to "protecting advantages", there is less friction, and
because there is tighter cooperation during implementation, integration
disappears.  It might actually take less than 10 staff years.  The
total cost, about $4 million, less than 1/2 percent of the cost of the
"proprietary" solution.

But assuming that each company had the $8 million each to spend on IT
development, this now means that this money can be used for other
purposes.  For example, implementation of other standards, or providing
"groovy user interfaces" to the core standard.  Let's take the most
aggressive approach and put all of it into standards.  This gives each
company the 'leverage' equivalent to about 20 times the "bang for the
buck".  In effect, the "pooled" resources could do the equivalent of
$1.6 billion if they were each "rolling their own".

> | "Who would have thought five years ago there would have been
> | another database to rival IBM DB2, Oracle, and MS SQL Server?

5 years ago.  2001, not that far fetched.  MySQL was widely used in web
sites for "read mostly" tables.  It was fast, it was easy to set up, it
was free, and it was close enough to standard to be likable, and there
weren't the common "per seat" royalty schedules.

DB2 and Oracle are "heavy iron" databases.  Companies put their
financial transactions, the "money shots", and the "strategic
transactions" into these databases.  On the other hand, using
federation and caching can provide a great deal of performance for the
accesses, while easing the load on the "heavy iron" databases.  For
example, put the zip code to city/state lookup on MySQL and leave the
customer transactions on the DB2 engine.

Using MySQL as a cache is also popular.  It's very easy to pull the
most current data, the information most likely to be received, into
MySQL databases, from Oracle or DB2 databases.  You can use cheap
drives, configured as RAID Zero, because if the drive fails you can
just take the bad one offline, and reload the table with a quick query.

> | By all estimates MySQL now has many more installations than IBM
> | or Oracle; some estimates show that MySQL has more
> | installations than SQL Server!

Not so surprising.  If you have a DB2 machine running on a 64 processor
P/590 server, with a 300 terabyte shark storage array, that's only one

If you pull cached queries out of that machine into MySQL running on a
blade with a SAN attached RAID-5 1 TB array, you might need 50-100 of
those little blades.  That's not too bad.

Microsoft bumped their count that way.  They served delayed quotes
(probably still do) for NASDAQ.  They would pull stock quotes from an
Oracle server that's actually doing the trades, into the SQL Server
tables.  The delayed quotes are then fed to customers who request it
via a web browser interface.  When I first read about it in 2000, the
first thought that came to my mind was "Why not use MySQL or PostGreSQL

Appearantly, NASDAQ got a very good price for those servers, probably
because it was so "high profile".  I suppose the details are out there

> | "Open source allows a company to completely change the rules
> | of the game. MySQL has over $40M in revenue the past 12
> | months and is probably valued at over $1 Billion. This is
> | an amazing company."
> `----

For over a decade, MySQL database benchmarks have not been published in
the TPM/C benchmark results because the "Big Iron" databases don't want
to have their $/TPM-C numbers ($2-5 these days), sitting on a sortable
spreadsheet next to MySQL's $/TPM-C (around $0.25 these days).

> http://www.businessreviewonline.com/os/archives/2006/10/why_would_anyon_1.html
> http://tinyurl.com/yb46rf

[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index