In reference to:
http://community.borland.com/article/0,1410,23108,00.html

These are good words. If Inprise can follow up with actions, and
continue to do so for a reasonable amount of time, it should
benefit the community as a whole. But thus far it's just talk
and (IMHO) Inprise has demonstrated that they are a lot better
at saying the right thing than doing it. In the following,
I will assume that they actually follow through on this
in a reasonable amount of time.

I personally feel that a code fork is not the best thing
for the community at large, if there is a reasonable alternative.
At the start of the firebird project, it did not look like
there was a reasonable alternative, and I believe that if
we had not taken action, Inprise would not have done so
in a reasonable time. (This is purely my opinion, you are
welcome to have a different one ;-)

The code as a whole will be a lot better, and the learning
process for outside developers a lot easier, with input
from the likes of Charlie Caro, Chris Jewell, Bala Sriram
and Shaunuk Mistry. The question is whether Inprise can
give them the freedom to work with the community in an effective
way, and what portion of the community can accept working with
Inprise. With patience and compromise on both sides, this
should be achievable.

Another issue is that I doubt the Inprise will allow anything
like the open free for all that we have in firebird. Personally,
I think that the improvements in firebird are a clear demonstration
that the more open-ness there is in the process, the more people
get involved and the more things actually get done. Contrary to what
Rob said, I do not believe that the firebird tree has made
dangerous or ill considered changes thus far. I say this having
looked at most of the changes that were actually made. If the
Inprise developers are not responsive to code submissions and
technical discussions, I believe there will be much less input
and enthusiasm for their tree.

So the question is, how the firebird group enter a positive
relationship with Inprise, keeping the ability to actively
work with the code and not set ourselves up for trouble
if Inprise's statements are not followed up by actions ?

It seems to me that all we really need is a central place
for discussion of the code, and participation on both sides,
as well as a reasonable effort not to flame without reason or wage
FUD campaigns. If some effort was put into keeping getting mutually
beneficial changes into both trees (the Inprise tree would, for
example benefit a lot from the warning cleanup and build
improvements that have been done in firebird), this could easily
function for long enough for better solutions to evolve.
This is very much what Chris Jewell said in a post on IB-Architech
when the firebird tree was first set up.

Finally, I continue to urge Inprise to follow up on their
word by promptly doing the following:
1) Releasing the TCS program source, and at least the RD_VECTOR
subset of the tests. This will allow people working with the
code to have reasonable confidence that they haven't totally
messed it up.
2) Publishing the existing bug database.
3) Releasing source to the InterBase Install API and windows install.
4) Publishing existing internal documentation on the engine.

I know that many of the above items are not in the the best state,
and some of the documentation is incomplete or incorrect. Some would
argue that this should be cleaned up before release, but to me, the
firebird project has demonstrated that the community is quite capable
of making use of these things. If we cooperate, we can get these things
in a usable state much quicker than either group could by itself.

Regards,
reed

Please note that in this post I represent only myself,
not IBPhoenix or any other developers involved with the
firebird tree. Time permitting, I will continue to try
to assist people working in any of the source trees.

--
Reed Mideke rfm(at)cruzers.com
If that doesn't work: rfm(at)portalofevil.com
InterBase build instructions: www.cruzers.com/~rfm