There is often some confusion as to the exact history of the different directory server versions that were sold by Netscape, iPlanet, Sun Microsystems, AOL, Red Hat and now Oracle.

For anyone interested in the lineage of these different directories, this is my recollection of events, some from the inside, and some from the outside:

Netscape Directory versions 3 and version 4 were where directory server as a commercial product really started to take off. Netscape Directory Three was based directly on the work of Tim Howes at University of Michigan. It was really more of an LDAP front-end, with provision for different back-end databases (at least in theory). Netscape Directory Four recognized that to get good performance, there needed to be tight coupling between the front-end (LDAP) and the back-end (database), so the facility of pluggable backends was dropped.

At this point, AOL buys Netscape and only wanting the browser, the website and its attached eyeballs, forms iPlanet with Sun to offload the other products it has no use for.

Sun takes over development, integrates components from its existing directory product and Directory 5.0 is born. This was a bit of a dead-end, with terrible performance mainly due to the replication scheme used.

Directory 5.1, which should really have been 6.0 because of the huge difference (ripping out the unworkable replication and replacing it with a loose consistency model) and different schema file format was more than just an incremental change. I also remember this being the time that the ACI format changed.

At this point, iPlanet disolved, and the code was shared by both Sun and AOL.

AOL took the code and tried to sell it as their own directory server. It never sold well, and eventually Red Hat bought it from AOL and open sourced it. 389 was derived from this open source (389 is the development version, the Red Hat directory is the stabilized commercial/supported version).

Sun continued to evolve the product, and with directory 5.2 had a replication model which supported up to four masters (actually, it would work with more, but the performance implications caused Sun to limit official support to a maximum of four).

This was probably the most successful in the entire product line. Four masters was enough to cover multiple data centers, replication would work over a WAN and the directory server itself would scale up tens of millions of entries with suitable hardware behind it.

Directory 6 was an evolution which tried to resolve some of the limitations of DS 5.2. It removed the four master limit and used a later version of the SleepyCat database. Scalability was improved.

At this point it became obvious that the fundamental design of the product was the limiting factor in getting significant performance improvements, so a next generation directory server project was started. This being Sun, it had to be written in Java. OpenDS was born. A lot of people were skeptical about performance of a Java DS, but early testing showed some surprisingly good results. Using a more modern back-end DB not only helped performance but improved resilience and reliability too. Fortunately, this happened at a time when Sun were experimenting with open source, so OpenDS was an open source project.

Sun then made what in my opinion was a strategic blunder. Trying to cut costs, they decided to combine their two directory engineering centers into one. They chose to continue with Grenoble, and shut down the Austin group, laying off a group of highly talented directory engineers and marketing people (this is not to say that the Grenoble group were not also talented).

Being unemployed, the Austin (ex)employees looked around for what to do, and UnboundID was created. They had been working with Sun customers for many years, and knew exactly what enterprise customers wanted from a directory, and had seen some of those needs continually slip along the roadmap timeline, or get dropped time after time. They took the OpenDS code and added those items to it (as proprietary extensions).

Back at Sun, DS 6 was supposed to be the end of the line for the C based directory, with DS 7 being based upon the OpenDS project.

There were still a few performance tweaks that could be applied to DS 6, so DS 7 was actually still based upon the legacy code – essentially taking ideas tested out in OpenDS, such as compression of database entries and back-porting them into the legacy DS code.

OpenDS was still intended to be the future.

Enter Oracle.

It soon became clear that whatever marketing spin they put on it, Oracle just wanted the customers, and not the directory technology. They were going to transition existing DSEE customers to Oracle Internet Directory (Oracle’s directory product sitting on top of an Oracle database), and since OpenDS has no customers, it was dead. At the same time, they put OpenSSO into a state of living death.

There were many customers using Sun’sOpenSSO product who were not thrilled at the prospect of losing their investment in OpenSSO, or the forced transition to what many considered to be an inferior product. ForgeRock was formed to provide support and a product evolution roadmap to OpenSSO customers that didn’t want to transition to Oracle’s access manager (was Oblix). OpenSSO (OpenAM) really needs a LDAP server, and being an ex Sun product had lots of dependencies on DSEE. ForgeRock needed an open source directory to complement OpenAM. UnboundID was certainly a possibility, but with the strong open source ethic at ForgeRock and the proprietary ethic at UnboundID, the fit was not there. OpenLDAP was another possibility, but although this had followed its own evolutionary path, and is a competent LDAP server, it is written in C and would require porting and support specific to each platform.

ForgeRock decided to do their own support of OpenDS. They acquired some of the key talent from the (Sun/Oracle) Grenoble directory engineering center, and OpenDJ was born. Initially, the idea had been to simply participate in the OpenDS community and provide commercial support, but for various reasons it soon became clear that it would be necessary to fork the project. There is still active participation in the OpenDS project, and with both being open source projects, some cross-pollination of ideas.

One of the biggest hurdles faced by ForgeRock (and UnboundID) was that Sun had provided the documentation effort for its open source projects (openDS and OpenSSO) and has copyrighted  the result, now owned by Oracle, which meant that they were faced with the herculean task of completely re-documenting. In ForgeRock’s case, for two products; OpenAM (OpenSSO) and OpenDJ (OpenAM).

—-

Things didn’t really go as Oracle had planned with DSEE. Existing customers would not transition to OID in most cases, and with viable alternatives (UnboundID, OpenDJ and OpenLDAP) which did not require building an Oracle database infrastructure and employing DBMs, they continued with DSEE (or ODSEE as they insist on calling it).

Of course, they recognized what Sun had several years before, that the current code base had reached the end of the line, and that if they wanted to keep the existing customers they had to provide a path which was not OID. So back to OpenDS, plus a few tools to ease the transition from DSEE, and the Oracle Unified Directory came into existence.