Re: Firebird holding its own but should be more popular...
22 views
Skip to first unread message
Steve Naidamast
Sep 28, 2022, 11:28:37 AM9/28/22
to firebird-general
Hello All...
Out of curiosity, the other
day I researched the most recent stats I could find regarding the
popularity of the Firebird Database Engine. I found the following
chart, which I thought was quite encouraging...
See... Site Link
The
line for Firebird is the thick red line that basically follows the same
trajectory as all the other popular engines. Firebird is also
categorized in the top 1/7th of the listed engines.
However,
if one were to notice this trajectory, there is only a 10 point change
in popularity\usage\growth from 2013 to current day. Why is this?
The
Firebird Database Engine is an excellent RDBMS that provides near
perfect resources for both desktop and server based applications.
It
is relevant to state that there is not a preponderance of large
organizations that rely on this engine, probably due to a lack of formal
support programs being offered as well as a rather poor effort at
marketing.
But at least one member of this
Community (other than I) has raised the same issue as I have in recent
years, the lack of a Firebird Group Database Manager. As a result, all
of us have to rely on third-party tools, some of them a bit expensive
in order to work with this database.
I suggest
that this lack of tooling is one primary reason for the lack of
substantial growth for the Firebird Database Engine. Not making a
software tool easy to use as a result of a centralized source for such
tooling is going to be rather off-putting.
I
have researched at length the majority of the tools that the Firebird
Third-Party Community offers. Some are known to be quite excellent but
limit themselves to only supporting server-based administration. Others
like, "RedExpert", appear to be quite solid tools but offer no
supporting manuals in English (at least none that I have found).
For
me, the EMS SQL Manager for Firebird is the best tool I have used for
the majority of my database work, including their other managers across a
number of database engines I have worked with in my long career.
Now
that Firebird is settled at 4.x, I would think it be a good time for
the Firebird Development Group to reconsider developing their own
in-house database manager since they have the best knowledge for doing
so. I have thought about doing this myself but I am not sure if my ADO.NET skills with the current Firebird ADO.NET Provider would be enough to accomplish such a task but the subsequent tool still would not be from the development team itself.
A
case in point as it regards knowledge. Recently I ran into issues with
hosting a Firebird Embedded 3.x engine alongside a 4.x engine in my EMS
database manager. The actual cause for the issue was quite simple,
being a conflict between the dependent DLLs loaded by both engines for
the embedded systems.
It was Mark who responded
here to my questions regarding this who finally cleared up the mystery
with this issue, which was that Firebird 4.x was more or less an in-pace
update to the 3.x engine and being so, would not matter if the DLLs in
question were in conflict since the 4.x engine could easily open 3.x
database files as I successfully tested.
The people at EMS who I was dealing with did not seem to understand this issue until I relayed the responses from Mark to them.
As
a result, even the best of the third-party developers sometimes have
issues with this engine they do not completely understand.
I
have always been a strong supporter of the use of the Firebird Engine
but I have always been dismayed that the tooling has not been offered by
the Firebird Group themselves for at least an option to the community.
I believe it would make adopting this engine a far easier process for
others and would assist in the growth of this engine's popularity.
Of
course, we have to be mindful that the people who develop and support
this engine are not necessarily full time professionals and must set
their development priorities accordingly. However, if one is going to
provide such a quality product, one would think that making it fairly
easy to adopt would be as much a priority as its ongoing development.
I believe now would be a good time for a reconsideration of this endeavor.
Steve Naidamast
Sr. Software Engineer
Mark Rotteveel
Sep 28, 2022, 12:14:25 PM9/28/22
to firebird...@googlegroups.com
Preface: I am aware I come off as a grumpy nay-sayer in this reply, but
I'm trying to be realistic, so I prefer to say my thing instead of not
saying anything.
On 28-09-2022 17:28, Steve Naidamast wrote:
> However, if one were to notice this trajectory, there is only a 10 point
> change in popularity\usage\growth from 2013 to current day. Why is this?
IMHO: lack of documentation (e.g. complete Language Reference) for a
very long time, lack of marketing.
> The Firebird Database Engine is an excellent RDBMS that provides near
> perfect resources for both desktop and server based applications.
>
> It is relevant to state that there is not a preponderance of large
> organizations that rely on this engine, probably due to a lack of formal
> support programs being offered as well as a rather poor effort at marketing.
Such support programs do exist, through commercial companies like
IBPhoenix and IBSurgeon, and others, see https://firebirdsql.org/en/support/
> But at least one member of this Community (other than I) has raised the
> same issue as I have in recent years, the lack of a Firebird Group
> Database Manager. As a result, all of us have to rely on third-party
> tools, some of them a bit expensive in order to work with this database.
>
> I suggest that this lack of tooling is one primary reason for the lack
> of substantial growth for the Firebird Database Engine. Not making a
> software tool easy to use as a result of a centralized source for such
> tooling is going to be rather off-putting.
It is a contributing factor, but I don't think it is the primary reason
(see above).
> Now that Firebird is settled at 4.x, I would think it be a good time for
> the Firebird Development Group to reconsider developing their own
> in-house database manager since they have the best knowledge for doing
> so. I have thought about doing this myself but I am not sure if my
> ADO.NET <http://ADO.NET> skills with the current Firebird ADO.NET
> <http://ADO.NET> Provider would be enough to accomplish such a task but
or "Firebird Development Group" (which suggest this is run by a company
or something). There is the Firebird Project, which is a loose
collective of companies and individual developers working on Firebird
itself and related things like drivers, and there is the Firebird
Foundation, which is a foundation consisting of companies and
individuals who basically sponsor some of the development work with
grants to developers.
Next to that you have a number of commercial companies offering Firebird
related service (e.g. support contracts) and derived products. Those
companies may or may not be contributors of the project and/or paying
members of the foundation.
> Of course, we have to be mindful that the people who develop and support
> this engine are not necessarily full time professionals and must set
> their development priorities accordingly. However, if one is going to
> provide such a quality product, one would think that making it fairly
> easy to adopt would be as much a priority as its ongoing development.
>
> I believe now would be a good time for a reconsideration of this endeavor.
Unless someone (preferably more than one) steps up to donate their time
and do this, I think this unlikely to happen on its own. Database engine
developers and database driver developers are not necessarily good UI
and database query tool developers, assuming current contributors are
even interested in doing such work.
Writing a good database query tool from the ground up is not something
that you just "do" on a whim, I think this would be an effort measured
in person-years (even person-decades). That might even be the case if,
for example, an existing tool like FlameRobin would be "adopted" by the
Firebird Project (assuming its current contributors would agree to that,
because a hostile fork is the last thing we need).
The Firebird Project runs on a surprisingly small core of contributors.
If people want more to happen, they need to step up and start contributing.
Mark
--
Mark Rotteveel
I'm trying to be realistic, so I prefer to say my thing instead of not
saying anything.
On 28-09-2022 17:28, Steve Naidamast wrote:
> However, if one were to notice this trajectory, there is only a 10 point
> change in popularity\usage\growth from 2013 to current day. Why is this?
very long time, lack of marketing.
> The Firebird Database Engine is an excellent RDBMS that provides near
> perfect resources for both desktop and server based applications.
>
> It is relevant to state that there is not a preponderance of large
> organizations that rely on this engine, probably due to a lack of formal
> support programs being offered as well as a rather poor effort at marketing.
IBPhoenix and IBSurgeon, and others, see https://firebirdsql.org/en/support/
> But at least one member of this Community (other than I) has raised the
> same issue as I have in recent years, the lack of a Firebird Group
> Database Manager. As a result, all of us have to rely on third-party
> tools, some of them a bit expensive in order to work with this database.
>
> I suggest that this lack of tooling is one primary reason for the lack
> of substantial growth for the Firebird Database Engine. Not making a
> software tool easy to use as a result of a centralized source for such
> tooling is going to be rather off-putting.
(see above).
> Now that Firebird is settled at 4.x, I would think it be a good time for
> the Firebird Development Group to reconsider developing their own
> in-house database manager since they have the best knowledge for doing
> so. I have thought about doing this myself but I am not sure if my
> <http://ADO.NET> Provider would be enough to accomplish such a task but
> the subsequent tool still would not be from the development team itself.
[..]
> I have always been a strong supporter of the use of the Firebird Engine
> but I have always been dismayed that the tooling has not been offered by
> the Firebird Group themselves for at least an option to the community. I
> believe it would make adopting this engine a far easier process for
> others and would assist in the growth of this engine's popularity.
As a matter of terminology, there is no such thing as a "Firebird Group"
> but I have always been dismayed that the tooling has not been offered by
> the Firebird Group themselves for at least an option to the community. I
> believe it would make adopting this engine a far easier process for
> others and would assist in the growth of this engine's popularity.
or "Firebird Development Group" (which suggest this is run by a company
or something). There is the Firebird Project, which is a loose
collective of companies and individual developers working on Firebird
itself and related things like drivers, and there is the Firebird
Foundation, which is a foundation consisting of companies and
individuals who basically sponsor some of the development work with
grants to developers.
Next to that you have a number of commercial companies offering Firebird
related service (e.g. support contracts) and derived products. Those
companies may or may not be contributors of the project and/or paying
members of the foundation.
> Of course, we have to be mindful that the people who develop and support
> this engine are not necessarily full time professionals and must set
> their development priorities accordingly. However, if one is going to
> provide such a quality product, one would think that making it fairly
> easy to adopt would be as much a priority as its ongoing development.
>
> I believe now would be a good time for a reconsideration of this endeavor.
and do this, I think this unlikely to happen on its own. Database engine
developers and database driver developers are not necessarily good UI
and database query tool developers, assuming current contributors are
even interested in doing such work.
Writing a good database query tool from the ground up is not something
that you just "do" on a whim, I think this would be an effort measured
in person-years (even person-decades). That might even be the case if,
for example, an existing tool like FlameRobin would be "adopted" by the
Firebird Project (assuming its current contributors would agree to that,
because a hostile fork is the last thing we need).
The Firebird Project runs on a surprisingly small core of contributors.
If people want more to happen, they need to step up and start contributing.
Mark
--
Mark Rotteveel
Steve Naidamast
Sep 28, 2022, 1:07:01 PM9/28/22
to firebird-general
Mark...
I believe that your suggestion to use the Flame Robin tool as a basis for new DB Manager is an excellent one and have been wondering why this hasn't been taken up before considering that it appears to be relatively complete.
I have tested out Flame Robin and concluded it does need some additional work but it seems to have a very good foundation.
As to contributing time\resources to the Firebird Project, I have a set of Firebird Data Access Layers which have been completely updated and are Open Source and freely available.
If you have a place where they can be made more available to the general community, please let me know.
The link for the download page is here... Firebird Data Access Layers
I support my tools freely...
Steve Naidamast
Sr. Software Engineer
Mark Rotteveel
Sep 30, 2022, 8:22:50 AM9/30/22
to firebird...@googlegroups.com
On 28-09-2022 19:07, Steve Naidamast wrote:
> I believe that your suggestion to use the Flame Robin tool as a basis
> for new DB Manager is an excellent one and have been wondering why this
> hasn't been taken up before considering that it appears to be relatively
> complete.
In my opinion, there are basically two reasons:
> I believe that your suggestion to use the Flame Robin tool as a basis
> for new DB Manager is an excellent one and have been wondering why this
> hasn't been taken up before considering that it appears to be relatively
> complete.
1) FlameRobin is a separate project, so placing it under the Firebird
project umbrella would at least require assent and cooperation of the
current contributors/maintainers of FlameRobin. I don't think a fork
(hostile or otherwise) is a good idea for the community as a whole.
2) Initiative: someone needs to take the lead of setting up such a
project and follow through on it, and probably a few others to
contribute. I don't think this will come from current core developers or
driver maintainers (though I might be wrong, I'm only expressing my
opinion here).
> As to contributing time\resources to the Firebird Project, I have a set
> of Firebird Data Access Layers which have been completely updated and
> are Open Source and freely available.
Firebird, but it is not what I mean with contributing to the Firebird
Project (which would, for example, be providing features or other
contributions to existing (or new) projects under
https://github.com/FirebirdSQL).
> If you have a place where they can be made more available to the general
> community, please let me know.
what you mean.
> The link for the download page is here... Firebird Data Access Layers
Mark
--
Mark Rotteveel
Steve Naidamast
Sep 30, 2022, 12:42:07 PM9/30/22
to firebird-general
Mark...
Placing a link to my Firebird Data Access tools in your Third-Party Tools section was exactly what I was considering.
Thank you... :-)
Steve Naidamast
Sr. Software Engineer
Reply all
Reply to author
Forward
0 new messages