Обсуждение: Pseudo-Off-topic-survey: Opinions about future of Postgresql(MySQL)?

 Now that CA has open sourced Ingres what future do
you guess to Postgresql and MySQL?

 Don't missunderstand me, I have been using Postgresql
for more than 3 years and developing apps against it
and all I got is possitive impressions, but comparing
the upcoming 8.0 (7.5) release with Ingres, it looks
that Ingres is much more advanced (clustering,
load-balancing, XML, ...) and the main advantage
Postgresql had in its open source nature looks to be
vanished. More one, CA looks really serious about
Ingres that now is a core tool in more of 100
derivates CA products, and it's said they had doubled
the number of Ingres developers. Also the new version
provides a great compatibility with Oracle and
"easify" Oracle to Ingres port. Is there any OBJETIVE
reason not to change to Ingres?

 Thanks in advance for your comments!

 Enrique Arizon Benito,

 Software developer and Network Administrator
 Daratel SL, http://www.daratel.com

e_arizon_benito@yahoo.com (Enrique Arizón) commented:
>  Now that CA has open sourced Ingres what future do
> you guess to Postgresql and MySQL?
>
>  Don't missunderstand me, I have been using Postgresql for more than
> 3 years and developing apps against it and all I got is possitive
> impressions, but comparing the upcoming 8.0 (7.5) release with
> Ingres, it looks that Ingres is much more advanced (clustering,
> load-balancing, XML, ...) and the main advantage Postgresql had in
> its open source nature looks to be vanished. More one, CA looks
> really serious about Ingres that now is a core tool in more of 100
> derivates CA products, and it's said they had doubled the number of
> Ingres developers. Also the new version provides a great
> compatibility with Oracle and "easify" Oracle to Ingres port. Is
> there any OBJETIVE reason not to change to Ingres?

Let me point to an article just released in InfoWorld, directly
addressing this issue:
<http://www.infoworld.com/article/04/08/13/33OPcurve_1.html>

Check out the second paragraph:

  "Then there are vendors that open up software, usually vintage code
  that has no commercial value. IBM opened its Cloudscape Java DBMS, a
  move that's a little late compared to Borland's opening of InterBase
  and a little irrelevant next to powerful and widely used open DBMSes
  such as MySQL and PostgreSQL, the latter being my current
  favorite. Computer Associates' qualified open sourcing of Ingres is,
  like Cloudscape and Microsoft's restrictive Shared Source Initiative
  opening of parts of .Net and other properties, an apt illustration
  of how selective corporate code charity is."

I have been watching different parts of the "computer biz" for
_years_, and I have seen plenty of projects using databases.

Oracle?  Plenty.  Microsoft SQL Server?  Lots.  Informix?  Sure.
Sybase?  I saw it chosen once, and I know one fellow who is presently
consulting at Morgan Stanley that tells me they are a big customer of
Sybase.

But in the last ten years, I have never once heard mention of Ingres
in a commercial context.  I was aware of it via "University Ingres"
and because of knowing a little history, both of which came from
academia, not from the commercial world.

Consider:
- Monster.com shows 13 jobs mentioning Ingres;
- PostgreSQL gets you 55 hits.

I have to concur with Yager's characterization of the release.

SAP's release of SAP-DB last year is another pretty evident case of a
vendor opening up "vintage code with little commercial value."  They
acquired it from Software AG a couple years ago, more than likely to
get them some leverage when negotiating licensing fees with Oracle.

They couldn't attract significant quantities of outside developers to
work on the "open source" release even though it has considerable
maturity and functionality.

Back to the Ingres question, it is _possible_ that the Ingres code
base may be usable / maintainable / improvable.  It is by no means
guaranteed that this is so.

It seems much more likely that CA has concluded that they can't make
any more money off of Ingres, and that they're essentially providing a
way that any remaining shops that are _heavily_ invested in it have
some capability to self support if CA stops doing maintenance.

For all of the vendors that have been doing this sort of thing, there
is also likely some notion of "scorched earth" policy in mind.  If
they can't make any money off their products, well, if they can do
something that can injure earning potential on the part of the the
leading vendor (e.g. - Oracle), they at least get _something_ out of a
retreat from the marketplace.

Note that, historically, a "scorched earth" policy probably most
notable as being the strategy Russian defenders used to fight back
those notable conquerors, Napoleon and Hitler.  They didn't have the
military might to directly fight off the conqueror, so they burned
everything as they retreated.  This left Stalingrad pretty much in
ruins, but the attacking armies were, shortly thereafter, nearly
destroyed by famine and frost.

I somehow doubt we'll see Oracle sales managers falling to quite that
kind of destruction, but it sure can't be enjoyable for them to see
others' database software getting steadily cheaper.

I wouldn't be shocked to see still more database products falling in
similar manner, although I don't expect to see many more closed source
DBs entering "open source form."  If you watch carefully, you'll
notice that every one of the recently "open sourced" databases has
emerged from a company to whom they represented a secondary sort of
product.  SAP _mostly_ sells R/3.  CA sells plenty of other software
as does IBM.

Companies like Oracle, Informix, and Sybase, where the _only_ product
is the database, have no room to do this.  If sales falter, the
company would fail before they could ever get a vital product "given
away."
--
output = ("cbbrowne" "@" "ntlug.org")
http://cbbrowne.com/info/sgml.html
"Purely applicative languages are poorly applicable." -- Alan Perlis

Christopher Browne <cbbrowne@acm.org> writes:
> e_arizon_benito@yahoo.com (Enrique Ariz�n) commented:
>> Is there any OBJETIVE reason not to change to Ingres?

> Back to the Ingres question, it is _possible_ that the Ingres code
> base may be usable / maintainable / improvable.  It is by no means
> guaranteed that this is so.

We were asked exactly this question when Borland tossed Firebird (nee
Interbase) over the fence.  I mind at least one prediction that Postgres
and MySQL would soon be, er, toast.  Curiously enough, we're still here,
and Firebird has had only the most marginal uptake among those who
weren't already users of the commercial version.

Maybe the story for Ingres will be different, but I bet not.  Keep in
mind that Ingres is a commercial derivative of the system that Prof.
Stonebraker abandoned when he decided to create Postgres.  Sure, CA put
lots of development effort into what they got from Berkeley ... but a
lot of development effort has gone into Postgres since it left Berkeley,
too.  There isn't any credible reason to assume that Ingres is a better
development foundation than Postgres, nor that it will attract more
development manpower than Postgres has.

> It seems much more likely that CA has concluded that they can't make
> any more money off of Ingres,

This is the absolute, undisputable, unvarnished bottom line.  If they
thought they could still make a dime off it, they'd have kept it.
Since they don't think they can, what is a rational assumption about
the value of the code to the rest of us?

            regards, tom lane

Personal opinion here:  Software packages like MySql and Ingres in the open source world are doomed to obsolescence.
Reason,they are released by a for profit company that is trying to play up to the open source market.  In MySql's case
they'repouring all of their talent into MaxDB. Why, because SAP is backing that and their making money.  Give MySql a
couplemore years and it will become stagnant.  MaxDB will probably fall off the open source world at about the same
timeinto closed source.  CA, which is a four letter word around here, is trying very hard to come back from the media
messthey've just been in.  They've torqued off way too many CIO's and techies, yours truly included, to do otherwise.
I'msure business practices have not changed, they still have investors to satisfy, so support for an open source Ingres
willwane and probably fast. 

Dick Goulet
Senior Oracle DBA
Oracle Certified 8i DBA

-----Original Message-----
From: Christopher Browne [mailto:cbbrowne@acm.org]
Sent: Saturday, August 14, 2004 12:23 AM
To: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Pseudo-Off-topic-survey: Opinions about future of
Postgresql(MySQL)?


e_arizon_benito@yahoo.com (Enrique Arizón) commented:
>  Now that CA has open sourced Ingres what future do
> you guess to Postgresql and MySQL?
>
>  Don't missunderstand me, I have been using Postgresql for more than
> 3 years and developing apps against it and all I got is possitive
> impressions, but comparing the upcoming 8.0 (7.5) release with
> Ingres, it looks that Ingres is much more advanced (clustering,
> load-balancing, XML, ...) and the main advantage Postgresql had in
> its open source nature looks to be vanished. More one, CA looks
> really serious about Ingres that now is a core tool in more of 100
> derivates CA products, and it's said they had doubled the number of
> Ingres developers. Also the new version provides a great
> compatibility with Oracle and "easify" Oracle to Ingres port. Is
> there any OBJETIVE reason not to change to Ingres?

Let me point to an article just released in InfoWorld, directly
addressing this issue:
<http://www.infoworld.com/article/04/08/13/33OPcurve_1.html>

Check out the second paragraph:

  "Then there are vendors that open up software, usually vintage code
  that has no commercial value. IBM opened its Cloudscape Java DBMS, a
  move that's a little late compared to Borland's opening of InterBase
  and a little irrelevant next to powerful and widely used open DBMSes
  such as MySQL and PostgreSQL, the latter being my current
  favorite. Computer Associates' qualified open sourcing of Ingres is,
  like Cloudscape and Microsoft's restrictive Shared Source Initiative
  opening of parts of .Net and other properties, an apt illustration
  of how selective corporate code charity is."

I have been watching different parts of the "computer biz" for
_years_, and I have seen plenty of projects using databases.

Oracle?  Plenty.  Microsoft SQL Server?  Lots.  Informix?  Sure.
Sybase?  I saw it chosen once, and I know one fellow who is presently
consulting at Morgan Stanley that tells me they are a big customer of
Sybase.

But in the last ten years, I have never once heard mention of Ingres
in a commercial context.  I was aware of it via "University Ingres"
and because of knowing a little history, both of which came from
academia, not from the commercial world.

Consider:
- Monster.com shows 13 jobs mentioning Ingres;
- PostgreSQL gets you 55 hits.

I have to concur with Yager's characterization of the release.

SAP's release of SAP-DB last year is another pretty evident case of a
vendor opening up "vintage code with little commercial value."  They
acquired it from Software AG a couple years ago, more than likely to
get them some leverage when negotiating licensing fees with Oracle.

They couldn't attract significant quantities of outside developers to
work on the "open source" release even though it has considerable
maturity and functionality.

Back to the Ingres question, it is _possible_ that the Ingres code
base may be usable / maintainable / improvable.  It is by no means
guaranteed that this is so.

It seems much more likely that CA has concluded that they can't make
any more money off of Ingres, and that they're essentially providing a
way that any remaining shops that are _heavily_ invested in it have
some capability to self support if CA stops doing maintenance.

For all of the vendors that have been doing this sort of thing, there
is also likely some notion of "scorched earth" policy in mind.  If
they can't make any money off their products, well, if they can do
something that can injure earning potential on the part of the the
leading vendor (e.g. - Oracle), they at least get _something_ out of a
retreat from the marketplace.

Note that, historically, a "scorched earth" policy probably most
notable as being the strategy Russian defenders used to fight back
those notable conquerors, Napoleon and Hitler.  They didn't have the
military might to directly fight off the conqueror, so they burned
everything as they retreated.  This left Stalingrad pretty much in
ruins, but the attacking armies were, shortly thereafter, nearly
destroyed by famine and frost.

I somehow doubt we'll see Oracle sales managers falling to quite that
kind of destruction, but it sure can't be enjoyable for them to see
others' database software getting steadily cheaper.

I wouldn't be shocked to see still more database products falling in
similar manner, although I don't expect to see many more closed source
DBs entering "open source form."  If you watch carefully, you'll
notice that every one of the recently "open sourced" databases has
emerged from a company to whom they represented a secondary sort of
product.  SAP _mostly_ sells R/3.  CA sells plenty of other software
as does IBM.

Companies like Oracle, Informix, and Sybase, where the _only_ product
is the database, have no room to do this.  If sales falter, the
company would fail before they could ever get a vital product "given
away."
--
output = ("cbbrowne" "@" "ntlug.org")
http://cbbrowne.com/info/sgml.html
"Purely applicative languages are poorly applicable." -- Alan Perlis

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

DGoulet@vicr.com ("Goulet, Dick") wrote:
> Personal opinion here: Software packages like MySql and Ingres in
> the open source world are doomed to obsolescence.  Reason, they are
> released by a for profit company that is trying to play up to the
> open source market.

Seems fair.

> In MySql's case they're pouring all of their talent into MaxDB. Why,
> because SAP is backing that and their making money.  Give MySql a
> couple more years and it will become stagnant.

Are you certain that's what is taking place?

Consider it stipulated that what people say on web sites may be mere
marketing fluff, but consider that the things that have gotten added
to MaxDB(tm) are pretty limited:
  a) They added the ability to use the same network protocol used
     by MySQL(tm);
  b) They introduced a way to replicate between MySQL(tm) and
     MaxDB(tm) databases.

They make _no_ claims about there being any future to MaxDB(tm),
whereas a big chunk of the marketing of MySQL(tm) discusses
enhancement plans.

It seems more likely to me that the opposite is taking place, namely
that MySQL(tm) is the product getting all the "talent," whilst
MaxDB(tm) is stagnating.

> MaxDB will probably fall off the open source world at about the same
> time into closed source.

That assumes it starts selling heavily.  I see little reason for
people to suddenly wake up and realize that they want to pay $1500/CPU
for something that _isn't_ Oracle or DB2.

MySQL(tm) got its initial "market penetration" because it got promoted
by free software advocates as a "free" database, and because it was
freely usable for web hosting.

In contrast, MaxDB(tm) simply hasn't got that "buzz" behind it.  MySQL
AB will have to spend heavily on marketing and sales reps in order to
get sales, and with Oracle and IBM being billions and billions of
dollars more entrenched, I just don't see that going anywhere.

The risk factor is also pretty bad vis-a-vis the classic "It's free
software, so you might be able to fix it yourself" thing.  That notion
is pretty illusory even for PostgreSQL, as there are lots of bits of
the "guts" of the system that require pretty deep understanding.
MaxDB(tm) is _way_ worse, in that regard, because it combines an
oddball set of custom build utilities (Make just wouldn't do) with
source code that combines German+Mainframe-abbreviated inscrutibility
with, if I recall right, some macrology where some of the code is
written in something _resembling_ Pascal.  (No offense intended to
Germans :-).)

That points to why I find it unbelievable that MySQL AB is throwing
all their talent at MaxDB(tm).  I can't imagine that a company whose
own "flagship" is as leaky a product as MySQL(tm) could expect to turn
around a piece of software that SAP AG, with _enormously_ greater
resources, found it futile to continue maintaining.  There are
scenarios that make sense, but not that one.
--
(format nil "~S@~S" "cbbrowne" "acm.org")
http://cbbrowne.com/info/multiplexor.html
"What did we agree about a leader??"
"We agreed we wouldn't have one."
"Good.  Now shut up and do as I say..."

Chris,

    To each his own opinion.  Take one very striking item in this message.  I'm a certified Oracle DBA, yet I'm working
withPostGreSql?  Sounds odd doesn't it?  The reality is that Oracle's pricing is SOO outrageous that some shops, like
ours,are starting to switch rdbms platforms to save a few bucks.  Looks at MaxDB vs. Oracle.  Maxdb $1,500 per cpu.
OracleStandard $15,000 per cpu, Enterprise $40,000 per cpu.  The figures make sense on their own.  And yes I agree
MySqlis a Very leaky and under functional product at any price.  Either way, I can't see MySql AB leaving it in the
opensource domain forever.  People LIKE to make money, especially those who "loan" you money to be share holders, and
youdon't make money on open source very well. 

Dick Goulet
Senior Oracle DBA
Oracle Certified 8i DBA

-----Original Message-----
From: Christopher Browne [mailto:cbbrowne@acm.org]
Sent: Saturday, August 14, 2004 12:22 PM
To: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Pseudo-Off-topic-survey: Opinions about future of
Postgresql(MySQL)?


DGoulet@vicr.com ("Goulet, Dick") wrote:
> Personal opinion here: Software packages like MySql and Ingres in
> the open source world are doomed to obsolescence.  Reason, they are
> released by a for profit company that is trying to play up to the
> open source market.

Seems fair.

> In MySql's case they're pouring all of their talent into MaxDB. Why,
> because SAP is backing that and their making money.  Give MySql a
> couple more years and it will become stagnant.

Are you certain that's what is taking place?

Consider it stipulated that what people say on web sites may be mere
marketing fluff, but consider that the things that have gotten added
to MaxDB(tm) are pretty limited:
  a) They added the ability to use the same network protocol used
     by MySQL(tm);
  b) They introduced a way to replicate between MySQL(tm) and
     MaxDB(tm) databases.

They make _no_ claims about there being any future to MaxDB(tm),
whereas a big chunk of the marketing of MySQL(tm) discusses
enhancement plans.

It seems more likely to me that the opposite is taking place, namely
that MySQL(tm) is the product getting all the "talent," whilst
MaxDB(tm) is stagnating.

> MaxDB will probably fall off the open source world at about the same
> time into closed source.

That assumes it starts selling heavily.  I see little reason for
people to suddenly wake up and realize that they want to pay $1500/CPU
for something that _isn't_ Oracle or DB2.

MySQL(tm) got its initial "market penetration" because it got promoted
by free software advocates as a "free" database, and because it was
freely usable for web hosting.

In contrast, MaxDB(tm) simply hasn't got that "buzz" behind it.  MySQL
AB will have to spend heavily on marketing and sales reps in order to
get sales, and with Oracle and IBM being billions and billions of
dollars more entrenched, I just don't see that going anywhere.

The risk factor is also pretty bad vis-a-vis the classic "It's free
software, so you might be able to fix it yourself" thing.  That notion
is pretty illusory even for PostgreSQL, as there are lots of bits of
the "guts" of the system that require pretty deep understanding.
MaxDB(tm) is _way_ worse, in that regard, because it combines an
oddball set of custom build utilities (Make just wouldn't do) with
source code that combines German+Mainframe-abbreviated inscrutibility
with, if I recall right, some macrology where some of the code is
written in something _resembling_ Pascal.  (No offense intended to
Germans :-).)

That points to why I find it unbelievable that MySQL AB is throwing
all their talent at MaxDB(tm).  I can't imagine that a company whose
own "flagship" is as leaky a product as MySQL(tm) could expect to turn
around a piece of software that SAP AG, with _enormously_ greater
resources, found it futile to continue maintaining.  There are
scenarios that make sense, but not that one.
--
(format nil "~S@~S" "cbbrowne" "acm.org")
http://cbbrowne.com/info/multiplexor.html
"What did we agree about a leader??"
"We agreed we wouldn't have one."
"Good.  Now shut up and do as I say..."

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faqs/FAQ.html

> But in the last ten years, I have never once heard
> mention of Ingres in a commercial context.  I was
> aware of it via "University Ingres"
> and because of knowing a little history, both of
> which came from academia, not from the commercial
> world.
>
> Consider:
> - Monster.com shows 13 jobs mentioning Ingres;
> - PostgreSQL gets you 55 hits.
>

 Curious, my first post was in part motivated because
I also use Job Searching engines to calculate the
success of a product and I found Ingres was much more
used in comercial deployments than Postgresql. In
Jobserve.com:

 - Postgresql related jobs:  5 vacancies
 - Ingres related jobs:     55 vacancies
 - SAPDB/MaxDB related jobs: 0 vacancies

 Jobserve.com concentrates in European countries, and
mainly around "London financial World", so it looks in
Europe Ingres in much more widely used while the
opposite is true with Postgresql in the USA.

> Back to the Ingres question, it is _possible_ that
> the Ingres code base may be usable / maintainable /
> improvable.  It is by no means guaranteed that this
> is so.

 I think you are completly wrong in this point. One of
the great things of Ingres with respect to its
near/far future is that is a core element in more than
100 CA applications, where it comes blunded. So it
makes lots of sense for CA not to drop it and continue
to improve it so they don't get dependent on a Oracle
48.000$ licence/CPU that obiosly will more than double
the final cost of many CA products. CA has nearly
doubled the number of Ingres developers since it was
first planned to opensource it (that's at least what
CA proclaims) and they are working to port many of its
products, right now tied to Oracle databases, to
Ingres. That will means for CA dramatically reducing
cost, and an instant grow of its client base.

 When I go to the Ingres website it gives me the
impression is a project really alive, and of course I
downloaded the Ingres documentation and found it
better documented and up to date than the Postgresql
one. A thing I really liked is that they constantly
compare Ingres to Oracle and DB2 in the docs,
emphasizing the points where Ingres is not yet as
mature as their rivals (XML support for example). This
is not a tipical behavior of a company that drop away
a product in the opensource just because they make no
more profit.

...and on Sat, Aug 14, 2004 at 12:21:57PM -0400, Christopher Browne used the keyboard:

<snip>

>
> > In MySql's case they're pouring all of their talent into MaxDB. Why,
> > because SAP is backing that and their making money.  Give MySql a
> > couple more years and it will become stagnant.
>
> Are you certain that's what is taking place?
>
> Consider it stipulated that what people say on web sites may be mere
> marketing fluff, but consider that the things that have gotten added
> to MaxDB(tm) are pretty limited:
>   a) They added the ability to use the same network protocol used
>      by MySQL(tm);
>   b) They introduced a way to replicate between MySQL(tm) and
>      MaxDB(tm) databases.
>
> They make _no_ claims about there being any future to MaxDB(tm),
> whereas a big chunk of the marketing of MySQL(tm) discusses
> enhancement plans.
>
> It seems more likely to me that the opposite is taking place, namely
> that MySQL(tm) is the product getting all the "talent," whilst
> MaxDB(tm) is stagnating.

FWIW, I attended this lecture from Patrik Backman of MySQL AB in november
of last year, and given the fact not much has changed since then in terms
of their release schedule, I dare assuming their strategic plans, which
were the main topic of that lecture, weren't that fluctuous either.

What they explained about MaxDB was the following: they took a vow with
SAPDB to continue developing MaxDB under the MySQL AB standard dual license
model, which means they can't really simply "take it off the opensource
shelf", because they have contract issues to deal with. Namely, the dual
license model was one of the terms under which SAP would provide them with
all the intellectual and material rights to SAPDB.

Their long-term development plan is as follows:

    1.  first of all, port the feature set that enables protocol stream
    feed from MySQL to MaxDB, in order to enable smooth migration and
    replication (including some features and concepts from MySQL
    gutter to make interoperation really nice) - this is the phase
    we're currently in

    2.    port the missing functionality from MaxDB to MySQL in order to
    enable creation of a "MySQL proxy for MaxDB", which would make
    it possible for one to communicate with MaxDB using standard
    mysql client tools, such as mysql, mysqldump, mysqlimport and
    mysqladmin; this would in turn make it trivial for existing
    SapDB/MaxDB customers to migrate between the products

    3.    now, as they're definitely not stupid, they realize maintaining
    two products would be an overkill, so their end goal was set to
    be one single codebase, which would then be used (in a manner
    similar to their MySQL/MySQL-Max/MySQL-Pro fork) to create a
    number of "products" with different feature sets, segmented to
    potential markets they targetted at that time

This one single product would brobably be based on the existing MySQL
codebase with features incorporated from MaxDB, as it's clearly suicidal,
thinking that they would be able to "fix and arrange" something as big
as SapDB and all of its legacy code.

Their basic philosophy regarding their existance in the market of open-
-source databases doesn't change too much though - see below.

> MySQL(tm) got its initial "market penetration" because it got promoted
> by free software advocates as a "free" database, and because it was
> freely usable for web hosting.

> In contrast, MaxDB(tm) simply hasn't got that "buzz" behind it.  MySQL
> AB will have to spend heavily on marketing and sales reps in order to
> get sales, and with Oracle and IBM being billions and billions of
> dollars more entrenched, I just don't see that going anywhere.

MySQL AB realize that the VAST majority of their market exists for one
simple reason - the MySQL server is deadbeat simple to install and configure,
and their basic feature set is large enough for most of the users that need
only the most basic functionality in a database server. And that is also
what helped them in being able to focus primarily on performance of simple
queries: they never had to deal with concurrency, cross joins, foreign key
constraints, hell, even subselects, much less all of the "fancy features"
as Patrik called "the stuff our users don't really need".

They do realize they can't just change brands because it would eventually
kill the gravity MySQL already has in the market, so they set MaxDB as
being sort of an "intermediate" product, which is probably going to be
made obsolete by the growing MySQL server.

> That points to why I find it unbelievable that MySQL AB is throwing
> all their talent at MaxDB(tm).  I can't imagine that a company whose
> own "flagship" is as leaky a product as MySQL(tm) could expect to turn
> around a piece of software that SAP AG, with _enormously_ greater
> resources, found it futile to continue maintaining.  There are
> scenarios that make sense, but not that one.

Indeed, that is what seems to be the case.

Cheers,
--
    Grega Bremec
    Senior Administrator
    Noviforum Ltd., Software & Media
    http://www.noviforum.si/

               e_arizon_benito@yahoo.com (Enrique Arizn) writes:
>> But in the last ten years, I have never once heard mention of
>> Ingres in a commercial context.  I was aware of it via "University
>> Ingres" and because of knowing a little history, both of which came
>> from academia, not from the commercial world.
>>
>> Consider:
>> - Monster.com shows 13 jobs mentioning Ingres;
>> - PostgreSQL gets you 55 hits.
>
>  Curious, my first post was in part motivated because I also use Job
> Searching engines to calculate the success of a product and I found
> Ingres was much more used in comercial deployments than
> Postgresql. In Jobserve.com:
>
>  - Postgresql related jobs:  5 vacancies
>  - Ingres related jobs:     55 vacancies
>  - SAPDB/MaxDB related jobs: 0 vacancies
>
>  Jobserve.com concentrates in European countries, and mainly around
> "London financial World", so it looks in Europe Ingres in much more
> widely used while the opposite is true with Postgresql in the USA.
>
>> Back to the Ingres question, it is _possible_ that the Ingres code
>> base may be usable / maintainable / improvable.  It is by no means
>> guaranteed that this is so.
>
>  I think you are completly wrong in this point.

Hmm?  What could conceivably have been wrong about what I wrote?

I didn't say that the code base was unmaintainable; I intentionally
waffled about the matter, so I _couldn't_ be wrong.

 - It's _possible_ that the Ingres code may prove to be fairly easy to
   maintain and enhance;

 - It's also possible that after a dozen years of past optimizations
   and people hacking on it, it is almost impossible to do so.

The latter was the case for Adabas-D, when it got "open sourced," so
there certainly is precedent.  And the "tough learning curve" property
has been true for numerous software packages that have been released
in "open source" form.

I think it took about a year before people were able to do builds of
Mozilla, and even then, it was _seriously_ feature deficient because
"open sourcing" it required stripping a lot of stuff out, and there
was a hefty learning curve.

I would find it surprising for a "mature" software product like Ingres
to NOT be a challenge to would-be newcomers.

> One of the great things of Ingres with respect to its near/far
> future is that is a core element in more than 100 CA applications,
> where it comes blunded. So it makes lots of sense for CA not to drop
> it and continue to improve it so they don't get dependent on a
> Oracle 48.000$ licence/CPU that obiosly will more than double the
> final cost of many CA products. CA has nearly doubled the number of
> Ingres developers since it was first planned to opensource it
> (that's at least what CA proclaims) and they are working to port
> many of its products, right now tied to Oracle databases, to
> Ingres. That will means for CA dramatically reducing cost, and an
> instant grow of its client base.

If it wasreally such a great product, then why didn't they start
porting their Oracle-based products to use Ingres a year ago when they
could have gotten the benefit of charging hefty licensing fees for
Ingres as well?

And the"dramatically reducing cost" and "instant grow of client base"
are both illusions.

 1.  CA doesn't save money by porting their applications to run on
     Ingres; it _costs_ them money to do so.

 2.  CA doesn't instantly grow its client base, unless there is some
      magical reason to imagine that new customers will suddenly want
      to start buying products from CA because these products have
      been ported to run on Ingres.

>  When I go to the Ingres website it gives me the impression is a
> project really alive, and of course I downloaded the Ingres
> documentation and found it better documented and up to date than the
> Postgresql one. A thing I really liked is that they constantly
> compare Ingres to Oracle and DB2 in the docs, emphasizing the points
> where Ingres is not yet as mature as their rivals (XML support for
> example). This is not a tipical behavior of a company that drop away
> a product in the opensource just because they make no more profit.

CA are pretty good at marketing, so I haven't the slightest bit of
trouble believing that they would be able to successfully give this
impression.

SAP AG did very similar things with SAP-DB, and that did not prevent
reality from being quite different from impressions.
--
"cbbrowne","@","ntlug.org"
http://cbbrowne.com/info/x.html
"I'm sorry,  Mr.   Kipling, but you  just  don't know how to   use the
English Language."  -- Editor of the San Francisco Examiner, informing
Rudyard Kipling, who had one  article published in the newspaper, that
he needn't bother submitting a second, 1889

On Mon, 2004-08-16 at 11:52, Chris Browne wrote:
> And the"dramatically reducing cost" and "instant grow of client base"
> are both illusions.
>
>  1.  CA doesn't save money by porting their applications to run on
>      Ingres; it _costs_ them money to do so.
>
>  2.  CA doesn't instantly grow its client base, unless there is some
>       magical reason to imagine that new customers will suddenly want
>       to start buying products from CA because these products have
>       been ported to run on Ingres.
>

Agreed. ISTM if they really wanted to accomplish those goals, they would
port all of their stuff to postgresql. They then lose all of those costs
of having to maintain and develop an open source project as well as
being able to increase a customer base since customer data is not
beholden to a single vendor and customers don't have to bet their
futures on CA's fortune. (both things that they are actually making
worse by porting all their apps to ingres).

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL