Hi Jason,

The article is great. If the person reading is truly
interested in the future of InterBase(R), the length
would not be a problem at all.

IMHO, to have Borland work together with the open
source development will require an attitude change
on Borland's part.... instead of trying to control
things and put their own political spin on everything
that happens, they need to concentrate on facilitating
future development of the product.

One major irk for me is their closed bug lists. A positive
step would be to have a full list of current bugs so we
can get them fixed. Maybe Borland could come to the party
and add the list of bugs to their own open source site, or
even to firebird's?!

Then there's the issue of certified builds. Well, if we
are going to have builds certified by parties such as
Borland and IBPhoenix, doesn't that mean that those parties
will have their own internal fork of the code? I assume that
this is viewed as a major revenue stream, but won't this
severely hold back the development of a stable product?

Personally, I'm pretty sick of the whole us & them thing.
Maybe the best thing would be to make firebird *the* fork
by making it the better product (adding essential security,
writing better client dlls, etc) by moving on without the
previous baggage. Keep compatability at the API level the
same, but don't worry about on-disk-structure, etc... write
some conversion code to get from any IB -> firebird if
necessary.

I wish that Borland would come around, but I'm
not holding my breath....

FWIW,
Corey.