Borland became known for its good programming tools in the nineties. In fact, I wrote my very first Java application using Borland's JBuilder which came on a free CD. For reasons nobody as yet seems to understand, this well-known company had some sort of identity crisis at the end of the nineties. In a misguided effort to create a brand name, the company renamed itself Inprise. As it soon became apparent that nobody had ever heard of the company called Inprise and that everybody went on calling Borland Borland, the management then changed the name to Inprise/Borland.com, and soon after that to Borland/Inprise, and finally back to the familiar Borland.1 Of all the crazy IT stories from the turn of the millennium, the Borland-Inprise-Borland one takes the prize for most schizophrenia.

One of Borland's products, which it had purchased in 1991, was the SQL database called InterBase.2 Although not on a level with its bigger cousins Oracle and IBM DB2, InterBase was fairly common for smaller database use.

Just before the end of December 1999, the professional and determined leaders of Borland - actually, Inprise at the time - announced to the developers of InterBase that they were halting the development of the database. Apparently, the management was unhappy with the level of profit InterBase was generating. Even though the product was not in the red, for some reason they'd decided to pull the plug on it.

Borland's customers weren't happy. Big clients like Nokia and Motorola used InterBase widely and in important projects, and if nothing else helped they were even prepared to buy the whole InterBase division from Borland. With big clients like that putting pressure on Borland, the company finally compromised by deciding to release InterBase under an Open Source licence.

And that, one would think, was that. But not a bit of it, the story is just begun.

When the Borland management finally cottoned on to how strong a product they had, they suddenly changed their minds. Of course they ought to go on selling such a good product - what with big clients coming with bags of money and practically begging them to do so. So when the first Open Source version, InterBase 6.0, was released, Borland started pulling out of the project. Suddenly, the company gave the Open Source version no guarantee or support, and on the whole the company went back to the good old way of closed software, charging their clients according to the one license per machine principle.

The result of this confusing and partly amusing story was Firebird, the genuinely open Open Source version of InterBase. The Firebird project amassed a number of programmers who were fed up with the yo-yoing at Borland and were determined to keep working on the open version on their own. Borland's own programmers weren't involved in Firebird, but it was developed by some accomplished programmers from outside Borland who had worked on the first versions of InterBase back in the eighties, together with some other programmers and consultants who had worked with InterBase.

In many ways the first years of Firebird resembled the tale of Mozilla. When the code of a closed program is opened up, all the garbage that has been quietly swept under the carpet over a period of years is suddenly revealed. It is said that one of the first surprises was that compiling the InterBase code into runnable program code produced several thousand warnings of possible flaws in the code. Such "compiler warnings' don't necessarily signify serious problems and don't usually prevent a program from working, but the fact that there were thousands of them says something about the attitude of the programmers working on InterBase.

When a program is developed openly, the situation usually never gets as bad as it was with InterBase and Mozilla. In the development of closed programs, there is always the temptation to take the line of least resistance. Flaws are unimportant: if the program runs and functions and seems superficially OK, it's put on the market right away. The quality of an Open Source program is open for all to see, not to mention the personal reputation of the writers of the code being at stake; so, working in an open environment raises the bar.

The Firebird hackers had to spend the first year or so cleaning up the code. And that long overdue spring cleaning certainly revealed some hairy skeletons in the InterBase cupboard.

In InterBase, as in database products in general, it is possible to define a number of different user IDs and give these users different rights. The person in charge of the database can have the right to do anything, a secretary can have the right to add or delete data, while other users only have the right to read but not change the data. User IDs, passwords, and the level of each user's rights must, of course, be stored in a way that allows the database program to access the information.

In the case of database software, the programmer is lucky in that a database is just the place to store user information. That's how InterBase had done it. The trouble with such an arrangement is that it leads to a chicken-or-egg situation. For a user to access the database, the user ID and password must first be checked, but the user ID and password are stored within the database that can't be accessed until the user ID and password have been checked!

There are probably a number of ways to get around this problem, but in 1992 the Borland programmers chose a solution that must be the most direct. They added a so-called hard-coded extra user ID and password giving access to all databases within InterBase! This user ID had been used internally within the InterBase code to bypass the chicken-or-egg problem, i.e., to check if the user ID and password given were correct. But once the code had been made open and the password that bypassed all further checks was there for all to read, it could also be used to break into anybody's database.3

Another skeleton in the InterBase cupboard was almost as bad. To ease their testing, the Borland quality control unit had demanded that the program contained a command that would allow a database to be scrambled or completely destroyed.4 Inexplicably, they insisted that this command be left in the version of InterBase that was sold to customers. Obviously, the InterBase user manual contained no information about this command, which was only intended for internal use by the quality control department, but leaving a destroy-all-files type of command in a version to be sold to clients does sound a bit like playing Russian roulette with their data. Even more incredible is that this was apparently done at the express request of the quality control department.

So, how have things been with the Firebird project since then?

It's doing fine, thank you very much. It took a little over a year to sort out the worst messes, then it was another six months before Firebird 1.0 was published in March 2002. Though the Firebird hackers got through their spring cleaning sooner than their comrades cleaning up the Mozilla code, this too shows what an enormous job it is to inherit the responsibility of developing an old program.

Firebird has done reasonably well, but it hasn't had the same reception in the Open Source community as Mozilla, because the open MySQL and PostgreSQL already more than adequately satisfy the hacker community's need for databases. Firebird has, instead, found its customers among the old InterBase users, who no longer need to be that worried about Borland's quirks.

Verdict: The InterBase story clearly exemplifies the risks involved in using closed programs. What are customers to do when a manufacturer decides to stop developing a product they really, really need? Building the IT infrastructure of a company on Open Source programs is always a safer option, because it allows the user of a program to make their own decisions about the future. As was the case with Mozilla, the first year of Firebird exposed how much can be hidden or overlooked within a closed program, while revealing how much better the quality of an open program is likely to be. It has been said the security of Open Source programs is better, because openness helps reveal the bugs in a code. In the case of Firebird, this did happen, but it actually took more than six months before a critical gap in the defences was found - despite the fact that it was obvious and easily identifiable in the code.

• 1At this point I'm sure one is allowed a smile. Earlier in this book I've spoken against planning and predetermination, but you have to draw the limit somewhere!
• 2InterBase itself had been created way back in 1984.
• 3You must note that the openness of the code was not the problem, but the laziness and irresponsibility of the original Borland engineer. The code would have been easy to spot even before the Open Source release of InterBase; all you had to do was to look at InterBase's machine code files with an ordinary text editor. It is perfectly possible that some cracker did this - the "back door' had been in existence for nearly ten years.
• 4Most likely the command was used to create artificial error situations to test how the software handles them.