I would like to float the idea of organising a developer recruitment
drive for Firebird.

Feasibility is based on questions like this:

* are there database developers/programmers out there who do not know
about Firebird, but are likely to be enthusiastic if they are
informed?

* would an influx of new developers have any negative effects on
Firebird development? For example, is the current rate of Firebird
development adequate when considering the factors involved in the
design cycle (design, craft, test, release)? Would a faster rate of
development reduce the test cycle and result in buggier releases?

* are there negative social implications in actively seeking out new
development team members instead of waiting for the new members to
find Firebird? Could an aggressive development strategy affect
Firebird's goodwill in any way?

These are just some of the issues. If there are no significant
reasons for not actively seeking out new developers then I propose an
organised plan, policy, and effort. I imagine such would encompass:

Who and Where: where on the web would we be most likely to find
potential new developers?

How: how to assess/invite potential new developers.

The When part (timetable for achieving features) is more the
territory of FB-sourceforge/IBPhoenix, so I'll ignore that for now.

This is yet another AGS (Andrew's Grand Scheme). Yes, Helen, I'm
bouncing off the rubber walls again! :-)

If Ann, the good folk at IBPhoenix, and the Sourceforge FB developers
consider a developer drive unnecessary or simply a bad idea then I'll
go back to my quiet grumbling about lack of varchar stripping across
the network and so forth :-) Otherwise I'll take point and start
doing some advanced recon.

I guess it boils down to this: Does FB need more developers? If so,
is it better to seek them out rather than wait for them to stumble
across FB?

Regards,
Andrew Ferguson