Re: Some free utilities for Java, with Hebrew support.
On Sep 25, 11:17 am, bbo...@gmail.com wrote:
On Sep 24, 5:46 am, Owen Jacobson <angrybald...@gmail.com> wrote:
You've repeatedly stated that someone could reverse-engineer MySQL's
protocol and server and add "extensions" to make their product more
competitive -- I ask this: what is the benefit in doing so as opposed
to creating a complete database implementation (client libraries and
all)
You snipped a question I consider crucial enough to any business
discussion that I'm going to ask it again at the expense of the entire
preceeding text:
What are the risks in reverse engineering MySQL's protocol, adding
your own extra features as extensions, and releasing your own driver
implementing that protocol and those extensions as a product?
I've outlined a handful below, but there are others. All of these
risks *must* be balanced against the projected profits. Remember, you
framed the concept of replacing the MySQL client library as making a
competing product - not an in-house replacement project.
you have no control over the server feature-set if you want a new feature at
that end of the connection.
.... Provided you want to remain compatible with the "stock" MySQL
client library. That's risk one.
Then again, maybe not -- in the case of MySQL. You could change
(subject to the GPL) the server you were using to support something
new, and your independently-developed closed-source client remains
your independently-developed closed-source client.
Extending the MySQL server has its own risk/reward balance, which is
mostly separate from the one for replacing the client library.
in detail; of course there would be a risk of something like that
happening if you installed a different version of the server software
some day.
But if you're selling it as a product, it's not "you" (the
manufacturer) upgrading the database -- it's your customers upgrading
their databases. There's support costs intrinsic in telling them that
no, your driver doesn't support the new version yet, and development
costs in making it support the new version. Less tangibly, your user
base will see you as slow to provide support for new MySQL server
features no matter how quickly after they're released you release an
updated driver, simply because you're slower than someone else (MySQL
AB). That perception, though somewhat unfair, has real effects on
your bottom line.
MySQL AB would have an interest in introducing features competing
client libraries don't support or in changing the protocol to break
competing libraries, so I'd expect to see it happen sooner or later.
Particularly onerous would be MySQL AB releasing a new feature (say,
stored procedures, to pick a fairly recent example) that your
customers want badly: as their client library provider, you will have
a very short period of time to implement support in your library for
the new features before your customers, who want to use the feature,
jump ship for another library that *does* provide support. Since the
feature is new, that library is most likely to be MySQL AB's own --
they'll have had as long as they want to implement support in their
own library prior to announcing the new feature.
Worse, since MySQL AB includes upgrades in their license fee, you
can't (usefully) charge your customers for the upgrade; they'll simply
go where the upgrade is cheaper -- MySQL's own library.
If the server software tries to auto-update it wouldn't be
hard to stop it with a decently configured firewall and a decently
knowledgeable sysadmin to configure it.
Would that customers could be configured so readily.
There's another risk you may or may not have considered: the cost of
legal defense. Regardless of the merit of the case, MySQL AB could
bring a suit against you for intellectual property violations. The
cost of legal proceedings to get the suit dismissed is not trivial,
even if MySQL AB were entirely in the wrong. However, with
intellectual property law in as messy a state as it's in, it's not
even clear to me that MySQL AB *would* be entirely in the wrong.