Re: OT: SCO Extortion - Mailing list pgsql-general

This is still marginally on-topic because it does have to do with PostgreSQL
and competitive issues with proprietary RDBMS ;-)
----- Original Message -----
From: "Jim Wilson" <jimw@kelcomaine.com>
 > Yes but the philosophy behind RHEL support is precariously close to that
of
> the gatesist shrink wrap model.  It is about getting paid for nothing (or
to
> buy the right to use an IP which is the cumulative skill of the phone
staff?).

Not necessarily.  You have to understand that there are several markets for
services.  RedHat is targetting the enterprise mission-critical market where
service-level agreements etc. are important.  From RedHat's perspective, it
is important that they don't get cheated in a support shell-game.

Red Hat has, for the time being at least (I hear rumors that this will be
changing) abandoned the SOHO (Small Office/Home Office) and SMB (Small to
Midsize Business) market, where support fees are much more of an issue than
the interruption of business.  They are doing this because this is a market
that they can penetrate that will give them the best return for their money.

>  Per incident charges with hourly rates past a time limit would make more
> sense.  A support provider could hedge their overhead against variations
in
> call volume by negotiating flat rate contracts with large users, based on
> faster response times and discounted hourly rates.

Sure.  And for some businesses, this is what they will want to do.  For
others, RHEL is a good solution.  This is likely to be more prevalent, IMO,
in the SMB market.

> The RHEL strategy pushes the limits of the intented flexibility built into
GPL
> for distribution and added value costs, especially in the way it extorts
the
> user into the all or nothing deal.  Does this mean that if you use White
Box
> on one server you void the whole contract?

This is a very valid critique of RHEL.  The real problem with it for many or
most business customers is that it limits the flexibility of implementation,
and increases the overhead of additional implementation (because contract
seats must be accounted, planned for, and budgeted).  A business must
ballance this tradeoff with their migration plan (how often do we want to
upgrade?), exposure to downtime costs, etc.  I think that for most
businesses, RHEL is not the appropriate solution, and I expect their
workstation market to be especially small.

However, for a few environments, RHEL is a very good deal.  I think, for
example, their advanced server product has great market potential for
mission-critical enterprise servers.

> The whole RHEL concept is doomed to failure anyway.  The main thing that
Red
> Hat has had going for it was support from the closed source vendors. As
those
> applications are replaced with opensource alternatives and as more closed
> source applications vendors support running their applications on other
> distributions, Red Hat's value will erode.  It already has somewhat.
There
> was once a time that many of the oss projects would release redhat binary
rpms
> for the last few RH versions on or near the first day of a new source
release.
>  Not any more.

In general, I am inclined to agree that RedHat's decision to ditch Red Hat
Linux in favor of Fedora was a mistake, though I can see why they did it.  I
don't release RPM's because the system seemed more trouble than it was worth
to learn (I use Red Hat, though I install most software from source because
I find that is more flexible and less trouble over the long run).  Red Hat
is now finding that they have to backpedal and find something to offer in
the midrange.  In other words, simplifying their product line didn't
accomplish the task at hand.  Without the midrange and hobbyist products
being as pervasive as they have been, they may find it hard to continue to
penetrate the enterprise.

I remember how Red Hat came to dominance-- that they saw the value of freely
redistributable Linux CD's, and their principle competitor, Caldera, did
not.  THier current strategy seems a retreat from the source of their
success.

I actually think that this is relatively on-topic for the PostgreSQL-General
list for 2 reasons:
1:  This does have an impact on how we recommend OS's for the RDBMS and more
importantly
2:  This is a great example of greater issues regarding open source software
which can be directly applied to PostgreSQL and its proprietary offshoots.

Regarding #2, I hypothesize that those vendors who take PostgreSQL and turn
it into a proprietary product are selling:
1:  A different product which has different advantages than PostgreSQL from
a business perspective but
2:  One which loses important advantages of the open source varient.

Best Wishes,
Chris Travers