Re: What so special about PostgreSQL and other RDBMS?

"Quirk" <quirk_at_syntac.net> schrieb im Newsbeitrag news:4e20d3f.0405110143.3fba4756_at_posting.google.com...
> "Volker Hetzer" <volker.hetzer_at_ieee.org> wrote in message news:<c7o7il$u0k$1_at_nntp.fujitsu-siemens.com>...
>
> > "Quirk" <quirk_at_syntac.net> schrieb im Newsbeitrag news:4e20d3f.0405100025.fd32875_at_posting.google.com...
> > > edwardh_at_highstream.net (Edward Lloyd Hillman) wrote in message news:<109o67992jbs0c1_at_news.supernews.com>...
> > >
> > > > > You have no such right, ever, the only right you _can_ have is the
> > > > > right to modify it yourself or contract someone to do it. Please read
> > > > > your licence.
> > > >
> > > >
> > > > Got a news flash for ya...
> > >
> > > Oh boy, it's Seseme Street News, OK Kermit, keep talking.
> > >
> > > > If you have a maintenance contract with a vendor and something of
> > > > theirs' is broken, they must fix it if you need it.
> > >
> > > Perhaps, but when the product in question is proprietary you have no
> > > recourse when they fail, because no one else has any right to modify
> > > the source code.
>
> > I have, at most, the right to sue them,
>
> 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.

> > 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.

>
> > 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. Therefore, support contracts make sense. I was talking about the case where I go to the developer and ask him to do something for free.

>
> > > When you have a right to the source code you can sign such a contarct
> > > with any firm you like, and fire their ass and hire another when they
> > > fail.
> > But it doesn't make sense to use any other firm than the guys who wrote it.
>
> 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.

>
> > 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.

>
> 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.

>
> >
> > > 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 there is no such requirement,

See my other posting.

> 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".

>
> > > 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.

>
> > 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? 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.

>
> > > > The only way you can get that kind of support is with a maintance
> > > > contract. With Open Source we'd have had to spend many extra
> > > > man-hours trying to find where the problem was and how to fix it
> > > > without breaking anything else.
> > >
> > > Why? You could have the exact same contarct with a vendor supporting
> > > an open source product,
>
> > Yes, but then it would cost like any other product, right?
>
> 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. 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?

>
> > > 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.

> 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.

>
> > > Or
> > > failing that, your application could have been designed to to give you
> > > alternatives,
>
> > Right. And the customer throws away years of experience with one db system
> > and pulls a finished, reliable and maintainable alternative installation out
> > of the hat.
>
> 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.

>
> > 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.

> 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.

>
> > > But you put yourself in a position were you may have been unable you
> > > support your own customer _AT_ALL_ except for the good graces of your
> > > vendor.
>
> > Why? He doesn't support the db. The db vendor does that. All he has to do is > to show that it's othe db's fault, at which point
his customer's maintenance
> > contract with the db vendor kicks in. Normal business practice.
>
> Yes, passing the buck is unfortunalty the normal business practice,
> however good firms neither do it or put up with it.
And that is why special libraries, databases or servers exist?

> 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. B) the customer may trust Larry ellison, or IBM more than me. 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.
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?

Greetings!
Volker Received on Wed May 12 2004 - 07:02:41 CDT