Back to Links Page

Open-Sourcing Interbase

From Interbase developer Edward V. Popkov

Dear Colleagues,

First of all, please let me express the deepest appreciation to everyone who stands today in protection of fair play, professional dignity and honour, and freedom. Found yourself in front of an unexpected challenge, you managed to keep yourself straight under the pressure of monopolistic power. Thanks to your courage, the truth is being revealed and the demand grows for actions to take, that have a potential not only to change the software practice, but the very way of our lives as well.

The demand I am talking about is a rising voice of the community to make InterBase an open source product. Being myself a wee part of both InterBase and open source communities I can only welcome all the efforts being made to make two powers meet, and do my best to support such efforts.

Let me proceed with a small disclaimer which, I believe, is due before any thoughts and suggestions are spoken. Despite the fact that I am working in both InterBase and open source projects, I am not entitled to speak for the whole community, for either of the parties. Everything I say is just my opinion, based upon my personal experience. I can be wrong, but the reason is only my ignorance, not malevolence. So much on that.

I would not step on thin ice and give any formal definitions of what OSS, FSF or GNU is. All the information about these movements is available online, so do you research please. Instead of attaching labels I would concentrate on two issues that seem vital for free software practice.

To succeed, the free software community needs to create a demand its products on one hand, and to protect them from misuse on the other hand.

Coding standards are essentially high in free software. Weak or immature code still exists, but it is either fixed or rejected fast. The key points of quality code are:

• peer review
• absolute availability of information on all related free software products
• big knowledge base of algorithms and programming techniques (such as has been accumulated since the early days of UNIX)
• guidelines worked out by trusted and respected programmers to help coders with almost any level of experience to produce a code that is portable between various OSs and hardware platforms with zero or minimal efforts

Open source programmers protect their software with licenses. There are several free software licenses used widely: GPL, LGPL, BSD or X11-style and others. I am not a lawyer, but there are experts who can provide you with competent and reliable analysis of the differences between these licenses.

In fact, such differences are often argued, but there's one thing many people agree on: there's no need for YAPL (Yet Another Public License). Several companies tried to limit the freedom of developers and invent their own view of open software. The result of such innovations was that these companies failed to attract new powers to work on their now-open products because newly invented YAPLs did not provide individuals and informal groups with enough protection for their work.

So, opening the source, in general is good, when it comes under an appropriate license and when it's complete. However, this is a Moebius strip that has one side. What odd things can we expect?

Many of us have working contacts with big players in different industries. These companies are usually conservative, they have long-term development and investment programs and usually don't like radical changes. Despite, or as a result of all the hype about the open source movement in the computer, other technical and even the general press, it is quite likely that they are not ready to adopt open source software products.

One of the most often used arguments is that there's no one to sue for buggy software. One of the most often heard replies is that filing a lawsuit against a manufacturer of closed commercial software is as useless. Sceptics can examine any commercial license they have handy. Microsoft EULA for NT Server will do.

That is not the only possible problem. Free software projects also get stalled and trashed. The usual reason is lack of resources. Note that in open source world funding is not as essential as in commercial development. Many open source developers have paid daytime jobs and many are funded by interested parties to work on open source full-time. The "more essential" resources are considered to be

• a project leader with the ability to steer with an iron hand
• team members with technical experience
• team commitment to the product
• lack of demand for the product

To summarise, I have several questions I'm trying to find answers to myself, and about which I would appreciate your opinion:

1. How big would the negative impact on the InterBase community be if IB were opened? How many people would be forced to switch to another DBMS not to lose their partners or customers?
2. How feasible is it for the community to take the whole product over? How many people are willing to contribute to design, development, support and distribution? How many really will?
3. Who has left the IB team? What skills can be replaced immediately?
4. If the source were to be opened, would it be reasonable to change the name of the product and fork immediately?

We shan't cheat with Inprise, neither shall we flinch. A newly born project will need a solid rock to stand on and sources of funding for community members who have no other employment must be considered.

That's all for now. Thank you and take care. Please feel free to contact me in private or via (if you are a subscriber to that list).

Other Views

Home Page