Re: What so special about PostgreSQL and other RDBMS?

"Volker Hetzer" <[e-mail]> wrote in message news:<c7t3p2$b15$[e-mail]>...

> > What cold comfort that is. I would prefer the right to make my
> > aplication work without their good graces.
> >
> > Before you consider suing them I suggest you reiview your contact with
> > an actual lawyer. So you can understand exactly how painted into a
> > corner you really are.

> Look, we've got about 50 people here dealing with
> exactly those questions, telling us what contracts to enter and what not.
> When we buy support, we *know* what we are in for and when and
> what to sue them for and how to deal with them before we sue them.

Your argument, as usual, is that I should just believe you, not
because you have explained yourself, but just because you *know*.

Wether you have 50 people or 100 people 'around there', the fact
remains that it is very unlikely that your investment can be saved by
a lawsuit, for every 50 you have, Oracle has more. And if you do have
more legal might than Oracle, you are the exception, not the rule.

For most organisations, sueng Oracle, or anyother major corporation is
simply not an option.

My orignal comments still hold true, the right to sue is cold comfort,
the right to pick up your pieces and try somewhere else, keeping your
application in tact as much as possible, is better.

> > > at least, the right to cancel the
> > > contract which hurts them way more
> >
> > How can you cancel the contract when your entire application is
> > dependanton there product? Can you afford to throw away your
> > application too?

> See my other posting. Compared to changing the application (replacing
> it with another), changing the underlying database is easy.

Even easier if you have abstracted your data access with a simple
function, and then used that function throught your application. I
have no idea why you find this so hard to believe.

And for what purposes are you bringing up changing the application?
How is this comparison relevent? I am trying to explain how to protect
your investment in your application; to change it as little as
possible.

You make so little sence I wonder what is motivating you to carry on.

Abstraction of your database access is a good idea. Why are you so
hell bent to dispute this.

> > > than if I go to a postgres developer
> > > and tell him I'm not interested any more. So, unlike open source developers,
> > > they actually have an interest in doing something.
> >
> > What on earth are you trying to say here? Why is a postgresql
> > developer any more or less interested in your contarct than one who
> > pedals proprietary software?

> A developer who does not earn mony by it is less interested in providing
> work than one who does.

Why would anyone provide work for you without earning money? Geez, I
feel like I should be earning a paycheque just for talking to you.

As I've said, their are many profesional developers who provide
support for open source products, or provide source licences for their
own.

>  Therefore, support contracts make sense.

Of course they do.

They make even more sence if you are not locked in to a single source.

> I was talking about the case where I go to the developer and ask him
> to do something for free.

Why would anybody do work fo you for free? Are you a charity of some
sort?

> > Why? What magic powers are possesed by the firm that holds the
> > copyright? Expcet the power to prevent anyone else from touching or
> > looking at their code?

> They developed it.

Not necessarily, they merely own the copyright. And even so, that
still does not mean that somebody else can't modify it, and do so
well, sometimes even better than the original developers.

> > > See my other postings and the reply about division of labour. You might
> > > also read up on Maos Great Leap Forward and north coreas policy of doing
> > > everything themselves.
> >
> > You're not seriously trying to draw me into to a discusion on
> > communist history are you? If so, please go ahead, it may be
> > intersting. I've been reading the Fabian writing of George Bernard
> > Shaw recently myself.

> Right. Mao wanted every village to be self-reliant and do everything on
> their own. I think the best published example was that more or less
> every village had its own steel factory, resulting in a very low efficiency
> and crap steel. If you read about north corea you will sooner or later
> stumble on something similar, called "Juche". A fierce desire to be
> independent, an inability to recognize you can't be a specialist of
> everything and, consequently, a desaster.

And the relevance of this is....?

> > By the way, I am _not_ arguing that one must do everything
> > themeselves, only that one should not get locked into being dependant
> > on a single provide.
> >
> > As I'v said, I'm baffled that this is so controversial that you all
> > expect me to defend my good name merely for saying it.
> >
> > > > I'm not sure what this example is supposed to illustrate. The vendor
> > > > failed to fix the bug originaly and ony did so under dures,
>  
> > > The point was that contracts work.
> >
> > It was quite a poorly demonstrated point, as they nearly did and could
> > well have lost their own customer under the arrangement.

> Not "nearly", the legal opinion was correct and therefore the only ones
> to worry were the sued ones.

If it did come to a dispute, they could not have supported there own
application, they where exclusively dependendant on an outside firm.

> > > > which only
> > > > shows how vulnerable you where to begin with,

> > > Why was he vulnerable if he had a contract that required the vendor to > > > > work?

Because he had no right to go elsewhere if the vendor failed to
deliver.

> > As the old joke goes: "if this fire alarm fails, and your house burns
> > down, we will refund the entire purchase price (not including the
> > battaries)."

> OTOH, "if you install this fire alarm, you will pay less insurance on
> the house".

Relevence? What insurance is provided in the case here? 
Fire insurance you can buy, I have never heard of application
obsoletion insurance.

The original point being, you can not recoup your own investment, just
the purchace price.

> > > > if you had the right to
> > > > say 'OK, were going to fire you and give someone else the contract'
> > > > they would have fixed your bug pronto with no back talk.

> No, they wouldn't, because first they would have to understand the code.

If they where a credible provider of support and development for this
particular product, they would certainly understand the code.

> > > Maybe, but in case of open source software they'd say 'Good luck
> > > working into our source code, see you in two years'.
> >
> > Were do you get this idea? You can contract many companies, large and
> > small, to support your open source product, the difference being that
> > you can hire another when when they fail, because you have a right to
> > the source code, where as you have no recource when the provider has
> > all the rights.

> Like, suse and redhat, each doing their own distributions?

Huh? No, like a competent development comany providing devlopment
services, exactly like Oracle does, but without trapping you into a
sole source situation.

> Could you provide a link where IBM actually provides support
> for mysql? The only thing I have found is them bragging that  MySQL AB
> (fully) supports the AIX port, not that IBM supports MySQL.

Your question is yet another fallacy, since you are responding to a
general statement, that many large companies, including IBM, support
open source applications or provide source licences for there own
applications,  but if you really want to hire IBM to support your
MySQL implemtation, you can, I would recomend you try MySQL AB first
though.

	IBM Application development and systems integration
	http://www-1.ibm.com/services/us/index.wss/it/bcs/a1000402

> > Yes, developing applications costs money, it is this investment I am
> > advising people to protect by not getting locked into third party
> > dependencies.

> I do get locked into a third party dependency, even if I can change
> the third party.

If you can change it, you are not 'locked in.'

> I agree, on the plus side, I can change support without
> changing code, so who actually owns the code and merges the
> fixes from the other guy, provided they don't want to keep them themselves
> because they want to keep the customers?

All these question depend on the case, and have nothing to do with the
topic, if you have a right to the source you are safer that if you do
not, if you have abstracted your access you are safer still. What is
it you can not understand?

This conversation is becoming surreal.

> > > > or negotiate access to source for the vendors
> > > > product, the only difference being that you then have leverage.
>  
> > > The access to the source means nothing, see above.
> >
> > It means everthing.

> Why? I can't change it.

You have the *right* to use it and have it changed for ever and ever,
not only by the permission of some outside company.

> > It means the difference being being the master of
> > your applications and contracts or being a slave to a third party
> > vendor.

> He's my slave because I pay him.

No, he can simply ignore you if he decides the relationship is no
longer profitable for him. You can do nothing.

> > Maybe not 'out of the hat' but with less expense and retraining that
> > having to reprogram the entire application which was programmed with
> > proprietary bindings everwhere instead of properly abstracted code.

> Abstraction can make the job easier, you are right here, but then
> changing a database is not that hard too, as long as both are relational
> ones.

That's all I'm saying, Abstraction is a good idea. I was giving some
simple, good advice. What are you saying?

> > > Including people who have been trained on it.
> > > In what way is a change from oracle to db2 easier than a change from
> > > postgresql to mysql?
> >
> > Well, for one, you would never have to change away from the open
> > source products because of a dispute with the developer.

> Yes, I would. Because I'm not going to maintain my own database
> distribution.

Nobody asked you to. You have the right to use the product and never
talk to the developer if you like. You don't need to change it to
enjoy the rights that source code gives, that is the right to use the
product for ever, and even have it changed *if you need to*

My advice is to abstract when you have no source code, and perhaps
even then, I have repeated this many times and am not sure what you
are even disputing.

> > But in
> > anycase, my argument is not, and never was, oracle and db2 versus
> > postgresql or mysql. But rather for abstraction when you do not have
> > source code, or sometimes then too.

> If I have abstraction it's even less necessary to mess around with
> the db because it's easier to change the db.

Yes, that's why I am *recomending* abstraction. Are you just typing
compulsively at this point?

> > I certainly would
> > not expect my clients or users to be satisfied when I told them, I'm
> > sorry the application I provided for you doesn't work, but you will
> > have to discuss this with Larry Ellison. Nor would I be satisfied
> > giving such an excuse.

> It's different for databases.
> A) the customer quite often already has a database and expertise
>      maintaining it. He has an interest not to have another.

Abstaction means your application can run for different clients with
different databases then. double plus good.

However if your application is tied to one database, then the very
client you are describing is the very client that you will not get if
they use a different database from yours.

> B) the customer may  trust Larry ellison, or IBM more than me.

But if they only sent there money to Lary because they purchaced your,
unabstracted application, they would be pissed off when it did not
work, and you blamed it on Larry.

> C) the customer may want a database that can do more than I could
>      implement or maintain, like incremental backups, logical/physical
>     standby databases or security.

Exactly, so how are you going to accomplish this with your
unabstracted application? Do you even remember what side of this
debate you are on?

> Another case where it's different would, for instance be the OS.
> How much linux maintenance do you think you can provide,
> compared to redhat or suse? Is this really your corebusiness
> or area of expertise?

Why do I have to? Since I can hire one of a million support providers
for any OS, however for OSes without source, they can't do much when
the problem is with the OS itself. Same with the database.

Again, my argument summerized for the millionth time: If you have no
source Abstract access for sure, and it's also a good idea to abstract
access even if you do. I'm baffled how you've turned this into such a
long conversation.