Jim Starkey wrote:

> I'm not on the general list, so either indulge me here or ask me to drop
> the topics.
>

I will reply here then, since you could follow it...

>
>>> Firebird's biggest problem is lack of management of organization.
>>> It needs an organization to recognize needs and respond.
>>>
>>>
>>>
>> Whilst I agree that the current fuzzy admin/foundation/commercial
>> setup is due for institutional reform, this has not been a major
>> drag. In theory, a communist plan-economy is the most efficient, not
>> suffering from all the duplication and horse trading in a free
>> market. Yet in practice the reverse is true. This is much the same in
>> open source. The project has shown admirable progress in the last
>> years, despite a fuzzy organisational structure.
>>
>>
>>
> Part of the question revolves around what is meant by success. If
> success is defined by serving the existing customer base, then I guess
> things are OK. If success is defined as attracting new users and
> particularly new sponsors to underwrite development, then it is not
> OK. Prospective users require documentation to get started, and there
> isn't any documentation. Heavily motivated users will scrounge around,
> but most will move on to better documented projects like Postgres or
> MySQL.
>

And I have heard more then once from newcomers that they never met
another OS project with a better support then offered trough
firebird-support list.

For sure better documentation is a good thing, but I think that if FB
was on the main linux distributions for some years (like MySQL or
Postgres) the things will be a little different. Like it or not, the
majority of FB users are the people that uses the Borland tools (in
Brazil mainly Delphi !)

> I'd say the second biggest problem is lack of a certification process.
> Certification has a triple effect. First, it lets prospective users
> know there is help available and they don't have to master the product
> all by themselves (which, given no documentation, is quite a hurdle).
> Second, it creates a market for developers with Firebird experience.
> And third, it creates evangelists with a vested interest in Firebird
> success.
>

Agreed in part here, certification could be a plus, but I my point of
view the majority of FB "users" are customers from independent software
developers (like me) my customers don't care if the RDBMS is MSSQL or FB
or Postgres (I explain in the sales moment that the low-cost of my
software is an effect of using OS software so they don't need to buy
MSSQL and Win Servers licenses, just go FB/Linux and be happy without
cost). But after a few months they forget about it, FB runs so smoothly
and need such a low support from a DBA (me in this case) that they just
forget that they had a RDBMS behind the scenes.

The point in my opnion is:
How to put FB inside organizations that has it's own development team. A
way to achieve this is marketing, reviews and articles on mainstream
magazines, the CIO's need to know that there is alternatives besides
MySQL and Postgres.

My opnion is that the main point taken to choose a RDBMS is a Cost x
Bennefit analisys, what I can get spending the least money I can that
supply my needs. Of course Free/Open Source are more than this (all we
know that the freedom to have the code and the security it gaves keep us
protected from "temporary" decisions to offer free version of the
commercial RDBMS and a lot more than this). But if I was in charge of
and internal development team in a medium sized company, I would adopt
MSSQL Express (or whatever it is called) without fear, when and if I
reach the limits of the "free" version I think that will be the time to
pay for the "rest" or to look for alternatives, in my case I had a lot
of code (an entire ERP system) for MSSQL 6.5. When I choose FB there
isn't a free MSSQL version, if it had at that time, probably I had
sticked with it, not that I think MSSQL is better than FB, but because I
already had a ton of code for it, and both supply my needs. My point is
that a medium sized company has it's needs covered by any RDBMS around.

At the time I chosse FB I discarded MySQl because of lack of features
(no SP's, no triggers, no RI, no views, no a lot of things) and
discarded Postgres because it does not has a Windows version (the
majority of my customers runs Linux, but I'd like to have an option to
adopt Win servers if I wish to) and (at that time) lack of concrete
cases about it. FB was IB, IB was a stabilished product that I knew that
is solid and provides what I needed.

> The third problem is a lack of developer presence in the US. I can't
> say for certain, but I think that sophisticated developers don't like
> the anarchy in Firebird where almost nobody posts requirements let alone
> designs before checking in the code. I will say that the current
> discussion is a refreshing break with tradition. But still, the total
> absence of an architectural process is a major headache.
>

I agree with you that discussion is a must, but there are some
"specialists" in the specific areas that know what should be done and
how it should be done. I see discussions about new features that are
more general or achitectural, I agree that sometimes the people come
with the already done code and say, "Hi, I did this and I wish to commit
it". What I think about this approach:
1.) It will be better if it was openly discussed.
2.) The guy who did the job did it because it need it, if it won't be
accepted by the project, than he have his private "branch" with his
needs covered
3.) If the job was not accepted the projects and the developer looses.
the project looses because that feature will no be incorporated, the
developer looses because his feature will be not part of the main branch
and will not evolve, I agree that the efforts are a constraint resource,
so expend it in a feature that will not be part of the code is a big
loss, but if one think it needs it now instead after a year of
discussion and no final decision made, he thinks is better to pay that
price. There is a lot of examples of this (java procedures, nbackup,
etc, etc, etc.) I think that this code is not useless besides it solves
a particular problem, it serves as a test-bed for the code, an approach
for the sollution, and for sure as an indicator if the developed
sollution works ok and show it's strengths and it's weakness

For sure every body agrees that the time spent could be better used in a
end-to-end sollution, but sometimes the time for an agreement is a
problem, and anyway it serves as a test for the choosen sollution.

The lack of presence of US coders to me has nothing to do with the
"mess" you talk about, I think the lack of US coders is because those
guys prefer to use commercial RDBMS instead of free ones, in poor
countries like Brazil and Russia this is a huge gain, so it attract more
users. AFAIK the main developer in PG are from russia too... I have no
statistics about it and could not assure it, it's just my feelings, but
I think that the majority of OS projects has a bigger number of
developers out-side US.

> My brother-in-law is a manager at Texas Instruments. His group was
> looking for an accounting database. They did a quick look at Firebird
> and decided it was just too much of a hassle to work with (they also had
> a misconception that documentation would have fixed), so they went to
> MySQL, found that fit it their needs, and stayed with it. Under
> different circumstances, Firebird would have had a toehold in a major
> company.
>
>

I am sorry, if a company took such decision the only thing I could think
about it is the lack of research about the products on the market.

> These problems are solvable but haven't been addressed. Documentation,
> friends, is even more important than SMP. A pool of trained consultants
> is almost as important.
>

There is documentation available.
IB docs
Helen Book in English a bunch of other books in a variety of languages
Support lists around the world in different languages

Of course will be good if some kind of information like the Helen's book
was available on-line for free, but it's not, there is free
documentation, and you should agree with me, the price tag on the
Helen's book and not so high ! And besides that, every single question
are answered by a group of people that for sure Borland had never had
(and will never had) in his support team.

Free available docs is good, but there is free available information for
all the needs IMHO.

> The Firebird projects needs a structure that an identify critical needs,
> develop a plan to address those needs, and execute the plan. There's no
> point moaning about the lack of documentation; the need to address it.
> If Helen's publisher is too dim to understand marketing, find a
> different solution. Start a Wiki, for example. Engineering needs an
> architectural review board. Appoint one. If nothing else, it's a way
> to recognize your best and brightest.
>
>

There is already iniciatives like that around the world. It is walking
slowly, but it's alive.

> True, but the three open source databases are MySQL, Postgres, and
> Ingres. It's actually worse than that, because new open source players
> are coming out of the woodwork with MySQL storage engines (Solid, for
> example). Firebird could make the list, but not without documentation,
> it's a non-starter.
>

I would not put Ingres in a high place than FB.

about the documentation... see above

> IBM and others are throwing hordes of money at Apache. It may not be in
> cash to the Apache Foundation, but in developers and services.
>

If and when a big player comes to FB the thing will change
considerably... Put money in it and you could get a LOT of documentation
in a year or so. Or even better, put some of the people who has
expertise in documentation to work for the project.

> "Could be" the market leader, not "is". That's what so frustrating.
> The Firebird project has a deep understanding of Windows where MySQL
> engineers tend to pride themselves on their ignorance of Windows. But
> without a strategy to exploit this advantage, it will go away.
>

Agreed with the part about the strategy, the part about leadership I
have no numbers to talk about.

>
>> FB/IB core companies in my estimate generate some $10 mln in sales,
>> 25% of MySQL sales. Sure, MySQL is ahead, but not out of sight. This
>> makes your new efforts all the more interesting. If the Falcon/Vulcan
>> engine for MySQL hits the market sweetspot and allows MySQL to
>> recapture growth, it might IPO at $1.5 billion; if it fails to that,
>> it might IPO at $0.5 billion. It is not often that one billion
>> dollars hinge on one man's ability to architect & implement a
>> breakthrough database engine in 6 months.
>>
>>
>>
> Let me correct a misunderstanding. Falcon is not related to Vulcan.
> Vulcan has quite a bit of Falcon/Netfrastructure code, but not the other
> way around.
>
> Ignore the details of MySQL economics other than to establish that
> investors are eager to pour in money, companies are lining up to
> partner, Oracle is running scared, Microsoft is scared, Ingres is
> getting gobs of VC money, Postgres forks are getting gobs of VC money,
> and everyone and their brother is writing storage engines. And Ken
> Jacobs, Oracle Vice President for Server Strategy, was sitting in the
> front row of my Falcon talk taking copious notes.
>
> In the long run, it's about technology. In the short run, it's about
> approachability and user services. Without documentation, Firebird
> isn't approachable. And it doesn't offer services.
>

Who needs services ?

I have asked this question on the Paul's thread about IBPhoenix shares.
The majority of the FB users are like me (a small shop that uses FB as
RDBMS for some product) the users of my product will not pay or see the
need for services, if the DB engine goes down for some reason *I* should
fix it and make it work again, if it slows down *I* should fix it, only
when the internal teams of medium-sized (and above) companies start to
use FB in his internal projects there is small need for services and
consulting, maybe I am just too short-sighted but that's my opnion.

>
> Could be, should be, but it isn't. Firebird is being left behind for
> reasons completely within control of Firebird.
>
> Here are steps that Firebird must take to survive. There are certainly
> others.
>
> 1. Provide sufficient on-line documentation for a database savvy
> developers succeed with a trial project. Do it now!
>

On-line free documentation is good and very important, but no serious
project will start and deny some product without a good research about it.

> 2. Track and follow up downloads to find out what problems people
> have and if/when they give up.
>

I hate anyone contacting me or when I need to provide a lot of personal
information to make a download to test a product.

If I have a problem I will call you, don't call me :-)

> 3. Start a certification program.
>

Don't see it as too important...

> 4. Find out why US developers are shunning the project and fix it.
>

Again, what is the importance of the nationality of the developers ?
What about why not so many developers from India involved on the project
? The question could be rephrased as "How could FB bring more developers
to the team ? (no mater where they lives)"

> 5. Institute an architectural review process
>

ok

> 6. Develop the culture to make predictable releases
>

ok. but bad things happens. I prefer a delay on the release and a
good/solid product out then the business approach of put out anything we
has since we need to release a new version every year.

> 7. Identify and exploit Firebird advantages over MySQL and Postgres
> (Windows support, for example)
>
>

of course.


see you !

--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br