| Subject | Re: [Firebird-Architect] Re: Design of new built-in functions |
|---|---|
| Author | Jim Starkey |
| Post date | 2006-05-09T18:41:31Z |
paulruizendaal wrote:
the topics.
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.
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.
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.
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.
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.
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.
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.
cash to the Apache Foundation, but in developers and services.
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.
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.
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!
2. Track and follow up downloads to find out what problems people
have and if/when they give up.
3. Start a certification program.
4. Find out why US developers are shunning the project and fix it.
5. Institute an architectural review process
6. Develop the culture to make predictable releases
7. Identify and exploit Firebird advantages over MySQL and Postgres
(Windows support, for example)
Jim Starkey, Senior Software Architect
MySQL AB, www.mysql.com
978 526-1376
>I would like to respond to some statements you made, which wereI'm not on the general list, so either indulge me here or ask me to drop
>interesting, even though in part factually incorrect. I'm cross-
>posting to FB-General, so that we can continue this discussion in the
>right list.
>
>
>
the topics.
>>Firebird's biggest problem is lack of management of organization.Part of the question revolves around what is meant by success. If
>>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.
>
>
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.
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.
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.
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.
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.
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.
>True, but the three open source databases are MySQL, Postgres, and
>
>>This is the golden age of open source databases.
>>
>>
>
>Very true. After a first great database race in the 80's (winner:
>Oracle), another great race is on between the 3 big proprietary
>players and the 3 big open source databases. Which one of the 6 will
>win is anybody's guess right now.
>
>
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.
>IBM and others are throwing hordes of money at Apache. It may not be in
>
>>Companies and investors are are throwing sacks of gold at everyone
>>in site but Firebird.
>>
>>
>
>Sacks of money do not equate success. Great Bridge burned through $18
>million and had nothing to show, but documentation. Apache does not
>generate money, yet is a success.
>
>
cash to the Apache Foundation, but in developers and services.
>"Could be" the market leader, not "is". That's what so frustrating.
>
>>In the time that Firebird has put out three releases
>>(counting 1.5 as a release), MySQL has gone from a handful of
>>people to a profitable company over over 300 people with tens of
>>millions of dollars in the bank, millions of customers, and
>>alliances with dozens of major products and companies.
>>
>>
>
>
>Moreover, considering that MySQL is weighted towards Linux (60..70%)
>and that Firebird is weighted towards Windows (70..80%), Firebird is
>actually *the market leader* on Windows.
>
>
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.
>FB/IB core companies in my estimate generate some $10 mln in sales,Let me correct a misunderstanding. Falcon is not related to Vulcan.
>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.
>
>
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.
>So, in summary, the 2nd great database race is not over and FirebirdCould be, should be, but it isn't. Firebird is being left behind for
>is in the lead group. It will be a very interesting 2 years ahead.
>
>
>
>
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!
2. Track and follow up downloads to find out what problems people
have and if/when they give up.
3. Start a certification program.
4. Find out why US developers are shunning the project and fix it.
5. Institute an architectural review process
6. Develop the culture to make predictable releases
7. Identify and exploit Firebird advantages over MySQL and Postgres
(Windows support, for example)
>--
>
>
Jim Starkey, Senior Software Architect
MySQL AB, www.mysql.com
978 526-1376