I have an slightly different perspective on this. I hope it will be a 
bit useful

Background:
I'm a senior developer for a consulting firm. I too have experience with 
DB/2, Oracle, Sybase, Adabase, and M$ SQL.
In the last few years of work I've been moving from the technical side 
of things to be business side ( all together now: <eewwwww> ).

I've been following PostgreSQL for a couple of years now. Absolutely 
love it. I have never implemented it on a business project, though. Not 
by any personal desire to use or not to use it. Usually the db choice is 
out of my hands. I cannot say personally that PostgreSQL support is 
amazing - ( once again, no experience at all to draw on ), however, I've 
been following the lists closely enough over the last few years that I 
believe the statement to be accurate. I can say that support services 
from the other vendors really aren't all that spectacular.

Perspective:
There is one factor to database choice that I haven't seen listed here. 
Culpability & legal retribution. I'm not a lawyer, and don't claim to 
be - so I welcome any corrections to the accuracy of the following. 
Regardless of its' legal accuracy, I can vouch for the common belief in 
the following thought by corporate I.T. management.

Any corporation, whether privately or publicly held, has various legal 
obligations to it's shareholders. Executive officers share in both the 
financial rewards of a successful company and in the legal 
responsibility that the corporation has to it's shareholders.

If a catastrophic software failure results in a high percentage of lost 
revenue, a corporation might be able to seek monetary compensation from 
a commercial vendor. They could even be taken to court - depending upon 
licensing, product descriptions, promises made in product literature, 
etc. For cases like open source projects, like PostgreSQL, there is no 
legal recourse available.

So - in the extreme case, if commercial Vendor V's database blows 
chunks, and causes company B to loose a lot of money. If Company B can 
prove that the fault lies squarely on the shoulders of Vendor V, Company 
C can sue Vendor V's a** off. Executive management isn't at fault - 
because they have performed due diligence and have forged a partnership 
with vendor V who has a legal responsibility for the claims of their 
product.

If, however, the database was PostgreSQL, then Company C has no legal 
recourse. Executive management has personally taken all responsibility 
for any catastrophic software failures, and therefore have put 
themselves in quite a precarious situation. No one else to take the 
blame but them!

Now frankly I know that the above scenario is extreme. I was rolling my 
eyes while *writing* it. But the truth is that these are the kinds of 
things that technical auditors would report to a Board of Directors. 
There is nothing wrong with executive management choosing to assume risk 
(outside of corporate politics, that is ). Many savvy members of 
management realize that the real risk is quite low. Of course, the 
comfort level goes way up when the database is supporting a non-vital 
business process - or a process that is several steps away from the 
revenue stream.

Still - imagine a database system with data and transactional volume the 
size of Google. In this case the volume of updates & inserts is much 
higher. Now this database is a companies' main source of revenue 
( again, extreme, but we're talking examples ). Would you blame a 
corporate exec if he wasn't willing to place his own personal assets on 
the line by choosing PostgreSQL over Oracle?

BTW - Oracle & other commercial vendors handle these contingencies by 
buying insurance policies. If the above situation had occurred and 
Oracle was the vendor, then the two companies would most likely settle 
out of court by dealing with the insurer. I dunno exactly how the claims 
process works on such a beast, but I know that such policies are 
purchased ( and you thought the annual support fee was just to cover the 
support staff's salaries?). Maybe Oracle would file a claim, an adjuster 
would visit Oracle's customer, etc?

Closing:
I think PostgreSQL is a great database. I haven't explored it's good and 
bad points thoroughly enough to know what applications it serves best, 
and where it's weakest. I do hope to use it in enough scenarios to find 
out. I hope a lawyer reads this and tells me that regardless of what 
management thinks is true, the above is hog-wash. Until someone does, I 
can't ignore the fact that a commercial vendor has a legal 
responsibility to support the claims of their product, while an open 
source group does not. I think PostgreSQL specifically keeps all of 
their claims legitimate and reasonable, but that doesn't change the fact 
that if someone makes an honest mistake, there is nothing that can be 
done *legally* to make you correct your mistake or pay for the damage it 
caused.

Andrew Sullivan wrote:
> Followup set to -advocacy
>
>> On Wed, Jun 26, 2002 at 12:01:18PM -0700, Dann Corbit wrote:
>>
>> Customer support is also a big issue comparing free database systems
>> with commercial ones.  I know that there are a couple groups that do
>> this, but that genre of businesses do not have a good track record of
>> staying in business.  MS, Oracle, and IBM will be there five years down
>> the road to help.
>
> I normally wouldn't get involved in this one, since it's the sort of
> thing that turns into a flamefest.  And anyway, I'm not sure -hackers
> is the place for it (hence the followup).  But as a lowly user, I
> cannot let such a comment go unanswered.
>
> I've used several commercial products of different kinds.  I've
> supported various kinds of databases.  I've worked (and, in fact,
> currently work) in shops with all kinds of different support
> agreements, including the magic-high-availability, we'll have it in 4
> hours ones.  I've had contracts for support that were up for renewal,
> and ones that had been freshly signed with a six-month trial.
>
> But I have never, _never_ had the sort of support that I get from the
> PostgreSQL community and developers.  And it has been this way ever
> since I started playing with PostgreSQL some time ago, when I didn't
> even know how SQL worked.  I like to have commercial support, and to
> be able to call on it -- we use the services of PostgreSQL, Inc.  But
> you cannot beat the PostgreSQL lists, nor the support directly from
> the developers and other users.  Everyone is unvarnished in their
> assessments of flaws and their plans for what is actually going to get
> programmed in.  And they tell you when you're doing things wrong, and
> what they are.
>
> You cannot, from _any_ commercial enterprise, no matter how much you
> are willing to pay, buy that kind of service.  People find major,
> showstopper bugs in the offerings of the companies you mention, and
> are brushed off until some time later, when the company is good and
> ready.  (I had one rep of a company I won't mention actually tell me,
> "Oh, so you found that bug, eh?"  The way I found it was by
> discovering a hole in my network so big that Hannibal and his
> elephants could have walked through.  But the company in question did
> not think it necessary to mention this little bug until people found
> it.  And our NDA prevented us from mentioning it.)
>
> Additionally, I would counsel anyone who thinks they are protected by
> a large company to consider the fate of the poor Informix users these
> days.  Informix was once a power-house.  It was a Safe Choice.  But if
> I were an Informix user today, I'd be spending much of my days trying
> to learn DB2, or whatever.  Because I would know that, sooner or
> later, IBM is going to pull out the dreaded "EOL" stamp.  And I'd
> have to change my platform.
>
> The "company supported" argument might make some people in suits
> comfortable, but I don't believe that they have any justification for
> that comfort.  I'd rather talk to the guy who wrote the code.
>
> A
>
> --
> ----
> Andrew Sullivan                               87 Mowat Avenue
> Liberty RMS                           Toronto, Ontario Canada
> <andrew@libertyrms.info>                              M6K 3E3
>                                          +1 416 646 3304 x110
Thu, 27 Jun 2002 00:41:26 -0600
Tim Hart <tjhart@mac.com>
Re: Support (was: Democracy and organisation)
Hmmm...

I think this is a common fallacy.  It's like arguing that if windoze crashes
and you lose important data then you have some sort of legal recourse
against Microsoft.  Ever read one of their EULAs?  $10 says that Oracle's
license grants them absolute immunity to any kind of damages claim.

Chris

-------------------

Tim Hart Wrote:

If a catastrophic software failure results in a high percentage of lost
revenue, a corporation might be able to seek monetary compensation from a
commercial vendor. They could even be taken to court - depending upon
licensing, product descriptions, promises made in product literature, etc.
For cases like open source projects, like PostgreSQL, there is no legal
recourse available.

So - in the extreme case, if commercial Vendor V's database blows chunks,
and causes company B to loose a lot of money. If Company B can prove that
the fault lies squarely on the shoulders of Vendor V, Company C can sue
Vendor V's a** off. Executive management isn't at fault - because they have
performed due diligence and have forged a partnership with vendor V who has
a legal responsibility for the claims of their product.




Thu, 27 Jun 2002 15:08:14 +0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Re: [HACKERS] Support (was: Democracy and organisation)
On Thu, Jun 27, 2002 at 12:41:26AM -0600, Tim Hart wrote:

> If a catastrophic software failure results in a high percentage of lost 
> revenue, a corporation might be able to seek monetary compensation from 
> a commercial vendor. They could even be taken to court - depending upon 
> licensing, product descriptions, promises made in product literature, 
> etc. For cases like open source projects, like PostgreSQL, there is no 
> legal recourse available. 

That is only sort of true.  IANAL, though, so you should still get a
legal opinion.

First, read the EULA of the commercial packages.  I've never seen one
that didn't have something very similar to the following, which is
taken verbatim from the PostgreSQL license:

THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  THE SOFTWARE
PROVIDED HEREUNDER IS ON AN "AS IS" BASIS, AND THE UNIVERSITY OF
CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT,
UPDATES, ENHANCEMENTS, OR MODIFICATIONS.

Every company puts that in their warranties, precisely to head off
such lawsuits in the first place.

The problem is that (a) in some states or other locales, such
disclaimers are illegal, and (b) disclaiming an implied warranty of
fitness is tricky if employees of your company have made explicit
promises that a system will do such-and-thus (in casual parlance,
such promises are called "sales calls").

So you're right that it is sometimes possible to try to sue the
licensor of the software for damages.  Whether you have a hope of
winning, or (more importantly) winning anything other than a Pyhrric
victory, is another question.  I suspect that imagining one might sue
a software vendor is silly not because it is impossible, but because
it would almost always be totally impractical.  IBM fought the
Justice Department for 30 years.  Microsoft has been doing the same
for at least 10.  And they'd have _way more_ interest in fighting any
attempt to make them liable for flaws in their programs, and would be
being sued by people with much shallower pockets than the DoJ.  

It's also true that several bits of legislation (UCITA most
obviously) have attempted to protect software publishers from
_explicit malfeasance_, not just incompetence.  There is currently a
move afoot by some of the security community to make it possible to
hold companies legally liable for consequential damages of their
software's behaviour.  Both of these items suggest that a lawsuit
would have next to no chance of winning.

Finally, I note that, in spite of the suggestions of a lawyer back
when Great Bridge was starting up (see
<http://archives.postgresql.org/pgsql-general/2000-07/msg00024.php>),
the "exculpatory language" of the PostgreSQL license never was
extended to the PostgreSQL Global Development Group.  Therefore, it
strikes me that PostgreSQL developers could still be sued under the
current license, but I haven't read through that whole thread again
(I remember when it happened the first time, and I've little wish to
re-read all the UCITA arguments again), so maybe there was some
conclusion that the exculpatory language was extended by implication.

A 

-- 
----
Andrew Sullivan                               87 Mowat Avenue 
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M6K 3E3
                                         +1 416 646 3304 x110




Thu, 27 Jun 2002 10:41:00 -0400
Andrew Sullivan <andrew@libertyrms.info>
Re: Support (was: Democracy and organisation)
Tim,

> If a catastrophic software failure results in a high percentage of
> lost revenue, a corporation might be able to seek monetary
> compensation from a commercial vendor. They could even be taken to
> court - depending upon licensing, product descriptions, promises made
> in product literature, etc. For cases like open source projects, like
> PostgreSQL, there is no legal recourse available.

Well, there's the perception and the reality.   I can't argue that
company lawyers and auditors will *not* make the above argument; they
very well may, especially if they are personally pro-MS or pro-Oracle.
  You may be on to something there.

However, the argument is hogwash from a practical perspective.  In
pratice, it is nearly impossible to sue a company for bad software
(witness various class actions against Microsoft).  SO much so that one
of the hottest-debated portions of the vastly flawed UCITA is software
liability and "lemon laws".  Plus in some states, the vendor's EULA
(which always disclaims secondary liability) is more powerful than
local consumer law.

Or from a financial perspective:  An enterprise MS SQL 2000 user can
expect to pay, under Licensing 6.0, about $10,000 - $20,000 a year in
licnesing fees -- *not including any support*.   Just $2000-$5000 buys
you a pretty good $10 million software failure insurance policy.   Do
the math.

As I said, I don't disreagard your argument.  Just because it's hogwash
doesn't mean that people don't believe it.

-Josh Berkus




Thu, 27 Jun 2002 09:07:30 -0700
"Josh Berkus" <josh@agliodbs.com>
Re: [HACKERS] Support (was: Democracy and organisation)