Category: General news

[See remaining text…] 

Ann: I plan to make my best efforts for both companies and build the reputation of Open Source Databases and Open Source as a better model for doing business. The database market is huge and the availability of high quality open source databases is accelerating the growth. There’s plenty of room for Firebird and MySQL and PostgreSQL and Ingres and CloudScape and SQLite and all the rest. In specific, the differences in licenses and configurations of MySQL and Firebird mean that they appeal to different segments of the market.

FBNews: Can you tell us if Netfrastructure will be open sourced by MySQL? If don’t so, what do you think is the currently role of Netfrastructure in the actual MySQL AB business?

Ann: At the moment, no one knows. MySQL hired Jim for his mind and his track record, not for the 17″ stack of listings that are Netfrastructure.

FBNews: What is Jim currently job in MySQL AB? Will he only work in Netfrastructure improvements or is he going to participate in MySQL database development?

Ann: He’s also a senior architect.

FBNews: Do you think MySQL will use Jim’s expertise to create its own full featured MySQL engine, considering that now Oracle has InnoDB?

Ann: Certainly, MySQL recognize the benefits of a transactional backend. They hired Jim because he designed and implemented three transactional engines: Rdb/ELN, InterBase and the Netfrastructure engine called JSTar.

FBNews: Can you explain to the common users what are the major conceptual and architecture differences between Netfrastructure and Firebird?

Ann: Sure.

First, Firebird started as a C program and is only gradually adopting serious object discipline. All of Netfrastructure is designed and build as objects. The code looks completely different.

Second, Firebird relies on careful write directly to the database to maintain on-disk consistency at every point in its operation, eliminating the need for a recovery process.JStar writes data changes to a log file – logged changes are gradually propagated to the database. After a crash, a recovery process brings the database to a consistent state before restart.

Third, Firebird is multi-generational on disk. JStar is multi-generational in memory, but only the most recent committed data is stored on disk. This reduces the cost of garbage collection and greatly increases the memory usage.

Fourth, Firebird has a tiny memory footprint for a relational database. Data is cached only as it occurs on pages. JStar maintains an in-memory record cache with version chains.

FBNews: Many times you are referenced by the community as the InterBase/Firebird “mother”. With the recent events, can we expect that Firebird is getting orphan?

Ann: Firebird has dozens of parents – Paul, Dmitry, Arno, Helen … It can never be an orphan again. And I’m not leaving. I may cut down on consulting so I can be more annoying on the lists to make up for Jim’s cutting back there.

FBNews: In your vision, what are the benefits and loss (if any) to Firebird project with all the recent moves?

Ann: Not much of either, frankly. This really isn’t about Firebird, it’s about Netfrastructure and Jim. The lists will hear less from Jim, but he’s promised to lurk on architecture where he has most to contribute. His work on Vulcan is done except for some bug fixing that’s included in everyone’s plans. The integration will go more smoothly without him, I suspect.

« Hide it

[See remaining text…] 

To attack Firebird, Oracle would have to buy rights from many individuals.

Another difference is that Firebird operates under a single open source license. MySQL is dual licensed GPL and commercial, as is InnoDB. Oracle’s purchase of InnoDB doesn’t affect MySQL’s GPL business, but does put Oracle in the position to set terms for the commercial side of MySQL’s use of InnoDB.

If Oracle were to buy the rights to all code created by Roman Rokytskyy, JayBird would still be available under a license that allows its use with Firebird in all situations that are currently allowed.

Yet another difference is that Firebird’s code base is integral – MySQL has a more modular approach, using backend plug-ins. That lead to serious specialization. Many people on the Firebird project are familiar with most aspects of the code – the loss of one individual would not leave large sections of Firebird indecipherable.

If Oracle were to buy Roman’s code and hire Roman, others would pick up the existing code for Jaybird and continue to maintain and enhance it. Oracle would be under no obligation to share changes it made to Jaybird in the future – that obligation falls on subsequent contributors but not on the original contributor, but we would continue with a fork.

Basically, Oracle’s buying InnoDB and SleepyCat is a problem for MySQL – to the extent that it is a problem – because of their dual GPL / commercial license. EnterpriseDB and the other commercializations of PostgreSQL exist because of the very open license that PostgreSQL uses – there is no obligation to publish changes to the code, so they can produces “better” versions using their own “secret ingredients.”

Firebird’s license is between those two. We can’t make money selling commercial licenses, but we can’t be attacked by a third party restricting our right to make commercial use of code they acquire. We require that anyone who distributes changes to the code publish the changes, so no one can create a special secret “turboFirebird.”

There’s a risk that someone will decide that all our developers are wonderfully talented people and hire them away, but every software development organization faces that risk, and Firebird has a good record of bringing on and integrating new developers.

Hope this is moderately clear ….

Best,

Ann

« Hide it

[See remaining text…] 

Market researcher Evans reported early in 2005 that MySQL was used by 40% of developers, immediately followed by Firebird with 39%. The acquisition means that the Firebird architecture will be the most popular on the planet with a very large margin.

A lot of work will probably need to go into getting MySQL and the technology behind Netfrastructure to work together. A lot of testing will also be needed since, due to the low number of deployments of Netfrastructure, its finesses remain largely unproven.

It will be interesting to see how MySQL clients will react to this move and the eventual downgrade of InnoDB support. Will they wait until MySQL completes the Netfrastructure port, or will they choose to move to Firebird directly?

« Hide it

[See remaining text…] 

My decision to join MySQL has almost nothing to do with Firebird and everything to do with Netfrastructure. The Netfrastructure platform represents what I feel about contemporary computing hardware and future application requirements, and has been the center of my technical heart and soul for six year. Some aspects of Netfrastructure technology have already been contributed to the Vulcan project, but Firebird and Netfrastructure are architecturally incompatible. An attempt to integrate the technologies would be unlikely to meet the goals of either project.

MySQL and Firebird have never seen each other as competitors and I doubt this will change in the future. The projects have different open source philosophies, different technologies, different customer bases, and different sweet spots. The ideas behind the two projects are, happily, public and available to all. If MySQL and Firebird compete, it is only competition in offering the best possible support to their respective customers.

I am pleased to have had the opportunity to finish the Vulcan project. The combination of Vulcan SMP and architecture combined the rich feature set of Firebird 2 will make a solid release and a superb platform for future development.

I wish the Firebird project all the best in years to come. And if you need an opinion, please feel free to call.

Site editor note: Is this your first contact with Firebird? I invite you to read the “Get to know Firebird in 2 minutes” paper and find out why Firebird is so special!

« Hide it