I agree with Jan.
I think a good part of this whole situation has more to do with MySQL
having a core part of its product be dependent on an external entity.
Be they open source or not. I would think they have thought about
this possibility at various points in the past.
From where I sit, I dont see PostgreSQL having the same situation,
but perhaps there's some other ridiculously popular extension to pg
which I dont know about. I'd vote for just continuing to make a
better product, compete aggressively on the pr front (where pg still
has some way to go), and let the best player win.
___________________________________
Javier Soltero
Hyperic | www.hyperic.net
o- 415 738 2566 | c- 415 305 8733
javier.soltero@xxxxxxxxxxx
___________________________________
On Oct 11, 2005, at 5:02 PM, Jan Wieck wrote:
On 10/11/2005 6:31 PM, Bruce Momjian wrote:
Jim C. Nasby wrote:
Of course one flip-side to all this is that if Oracle does attack
us it
actually lends credibility; it means they see PostgreSQL as a
threat. At
this point that could do more good for us than harm, depending on
how
exactly the attacked.
Well, that was MySQL's reaction to it, but I think the harm far
outweighs the good for them. Its more like, "Oracle finds MySQL a
threat, what is MySQL going to do now!" We don't want that kind of
outcome. Also, there are ways of attacking that do not show
Oracle as
an agreesor, like hiring PostgreSQL developers.
From the fact that there was first an Oracle announcement and then
some "calming words" from MySQL we can tell that this wasn't
friendly. If it would have been, they would have had a joint press
release instead of this big grin from Oracle and that clenched
teeth smile from MySQL in return. So I agree, they are in deep
trouble.
Now the much I agree that we should be carefull and watch out, I
don't think we should be jumping to conclusions either. Nobody
outside Oracle knows right now what their real plan and their real
target with that acquisition is.
Don't forget that only a part, although a substantial part, of
Oracles revenue comes out of the database business. One possibility
is that they try to do birth control against a low-cost R/3
backend, which undoubtedly would be very bad for their CRM and ERP
business in several ways. After failing to build any open source
community, SAP had found MySQL, who was willing to maintain the SAP-
DB sourcecode for them. If Oracle squishes MySQL now, SAP is back
to square one on that project. There are many R/3 installations out
there that go well beyond 1/4 million dollars per year in DB
license fees alone. So even if they can only delay this development
by two to three years, it might pay off quite well.
And look at it, all Oracle would have to do is to be so open source
friendly that they make InnoDB GPL only. Can you imagine the
confusion in the MySQL fan club if Oracle releases the next GPL
version of InnoDB and MySQL AB announces that they ripped out
InnoDB support and favor something with half the feature set instead?
Jan
---------------------------------------------------------------------
------
On Tue, Oct 11, 2005 at 06:04:40PM -0400, Bruce Momjian wrote:
> We have entered a new phase in the possible attacks on PostgreSQL.
> > The purchase of InnoDB clearly shows Oracle is ready to
expend money to
> slow down competitive database technology. Now that MySQL has
been
> attacked, we should expect to be the next target.
> > Let's assume Oracle is willing to spend 1% of their revenue
or net
> income on attacking PostgreSQL. Given this financial statement:
> > http://finance.yahoo.com/q/is?s=ORCL&annual
> > that would be USD $20-100 million. (The Oracle financial
statement will
> eventually disclose the purchase price of InnoDB, and we can
use that as
> a minimum amount they would be willing to spend.)
> > Now, I think Oracle realizes that the database will
eventually become a
> commodity based on their purchase of Peoplesoft and other
application
> technology. However, every financial period they delay that
time is
> more profit for them, so it is a cost/benefit of how much it is
worth to
> slow down PostgreSQL. Obviously they thought the InnoDB
purchase was
> worth it to slow down or control MySQL. Our goal should be to
make the
> cost of attacks higher than the benefit.
> > Here are the three most likely attacks on our project:
> > o Hiring > > Oracle could hire a large portion of our paid
or volunteer developers,
> thereby slowing down the project. Individuals would probably be
> approach as "We like your work on PostgreSQL and would like your
> expertise in improving Oracle", but of course once hired what
they did
> for Oracle would be unimportant. What would be important is
what they
> _don't_ do for PostgreSQL.
> > o Trademark
> > Marc Fournier owns the PostgreSQL trademark and domain
names. He could
> be attacked, perhaps by hiring him to do a job, causing it to
fail, then
> suing him to obtain the trademark, and therefore the right to
own the
> domain names. The trademark has not been enforced, and it
would be hard
> to enforce at this stage, but I think it would be effective in
gaining
> control of the domain names.
> > o Patents
> > Most technology people agree the software patent system is
broken, but
> it could be a potent weapon against us, though we have shown we
can
> efficiently remove patent issue from our code.
> > > There is probably nothing Oracle can do to permanently harm
us, but
> there are a variety of things they can do to temporarily slow
us down,
> and it is likely a attempt will be made in the future. There
are also
> possible threats to PostgreSQL support companies, though they are
> somewhat independent of the project.
> > -- > Bruce Momjian | http://
candle.pha.pa.us
> pgman@xxxxxxxxxxxxxxxx | (610) 359-1001
> + If your life is a hard drive, | 13 Roberts Road
> + Christ can be your backup. | Newtown Square,
Pennsylvania 19073
> > ---------------------------(end of
broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an
appropriate
> subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so
that your
> message can get through to the mailing list cleanly
> --
Jim C. Nasby, Sr. Engineering Consultant jnasby@xxxxxxxxxxxxx
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
--
#=====================================================================
=#
# It's easier to get forgiveness for being wrong than for being
right. #
# Let's break this rule - forgive
me. #
#==================================================
JanWieck@xxxxxxxxx #
---------------------------(end of
broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
