Skip to main content

NOTE: Our FAQ

The official home of the OpenDS documentation is now contained on our wiki. The wiki contains updated versions of all documents, including the FAQ
Please refer to the wiki for all documentation in the future. The information below is being preserved for historical purposes, but is no longer being updated and may be removed at some point in the future.


Frequently Asked Questions
OpenDS Logo


Project Definition Roadmap Getting Involved in OpenDS Governance Other Questions



Project Definition
What is OpenDS?
OpenDS is an open source community project building a free and comprehensive next generation directory service. OpenDS is designed to address large deployments, to provide high performance, to be highly extensible, and to be easy to deploy, manage and monitor.

The directory service includes not only the Directory Server, but also other essential directory-related services like directory proxy, virtual directory, namespace distribution and data synchronization. The Directory Server is a network-accessible database that is able to store information in a hierarchical form. Clients may communicate with it using standard network protocols (at present LDAP and DSML are supported) to retrieve and update information in a variety of ways.

Initial development of OpenDS was done by Sun Microsystems, but it is now available under the open source Common Development and Distribution License (CDDL).


Is OpenDS a Sun Microsystems product?
No. OpenDS is an open source community project that is constructing next generation directory service software. The initial effort is primarily by Sun employees, but the goal is to attract developers and other interested parties from around the world. At some point, Sun will likely develop its own distribution and commercial offering based on this project.


Why release the OpenDS Directory Service as open source?
Sun believes very strongly in the value of open source, and is one of the top contributors to open source software. Sun has committed to providing open source for most of its Java Enterprise Systems components including its market leading Directory Service product.

Open source provides a number of benefits to the community:
  • Allows developers to cooperate freely with a minimum of legal restrictions.
  • Helps drive interest in the directory service solution and make it more appealing to organizations that prefer open source solutions.
  • Allows the community to more easily communicate what features they would like to see in OpenDS, and even gives them a chance to contribute at levels from developing core code, plugins, scripts, and even documentation.
  • Gives the community access to the source code so that it can more easily debug problems or answer questions that it might encounter. This increases code quality and security while reducing deployment costs.
  • Enables interested parties to more easily create customized versions of the solution that are optimized for a particular use.



What are the primary goals of the OpenDS software?
  • Performance. Lots of features are important, but performance is almost always near the top of the list. It needs to be extremely fast, outperforming all other servers wherever possible.
  • Upward Vertical Scalability. It needs to be capable of handling billions of entries in a single instance on appropriately-sized hardware. It should be able to make effective use of multi-CPU, multi-core machines with hundreds of gigabytes of memory.
  • Downward Vertical Scalability. It needs to be capable of running adequately in low-memory environments so that all essential components can be functional on edge devices like cell phones and PDAs.
  • Horizontal Scalability. It needs be possible to use synchronization to achieve higher levels of read scalability by adding servers to the directory service. In addition, it needs to be possible to use data distribution in conjunction with synchronization to achieve horizontal read and write scalability to achieve deployments into the billions.
  • Supportability. The server should be easy to support and maintain. Administration should be intuitive, and wherever possible the server should provide sufficient information and notifications to enable corrective actions, even predictively.
  • Security. The server must provide extensive security in areas like access control, encryption, authentication, auditing, and password and account management.
  • Extensibility. Virtually every aspect of the server should be customizable. It needs a safe and simple plugin API that delivers additional points of extensibility, including, but not limited to, password validation algorithms, password generators, monitor information providers, logging subsystems, backend repositories, protocol handlers, administrative tasks, SASL mechanisms, extended operations, attribute syntaxes, and matching rules.
  • Synchronization. The server must support data synchronization between instances, including not only total data synchronization but also partial synchronization (with fractional, filtered, and subtree capabilities), and must also provide a means of synchronizing with other applications and data repositories.
  • Availability. The server must be robust enough to continue running properly even if serious errors are encountered.
  • Portability. The server needs to be written entirely in Java so that it can run on any platform.
  • Reliability. A directory service is one of the most critical components of a business infrastructure. It is absolutely essential that the service function despite hostile or unexpected events and that the data it delivers be trusted.
  • Compatibility. The Sun Java System Directory Server will continue to be maintained over time and will not be immediately replaced by Sun products based on OpenDS. However, OpenDS must provide support for virtually all existing features of the Sun Java System Directory Server. Migration from other directory server implementations should also be taken into consideration when applicable.



Why not contribute to an existing open source directory project?
There are already a few open source directory projects, most notably OpenLDAP, Red Hat Fedora Directory Server, and Apache Directory. However, Sun felt creating a new project was a better option than contributing to one of these existing projects.

Creating a new project allows us to start with a framework that is designed to meet the needs of existing customers we already know well, and more easily extend it to meet new needs and new customers.

In addition, the goals of the existing projects do not necessarily line up with the needs we want to address from our considerable work with existing customers and partners, and we would not want to face the danger of forking the code or not being able to meet those needs, should they diverge from the goals of an established project. In essence, it wouldn't be fair or beneficial to any of the existing projects.

That said, this community will look for opportunities to collaborate with other projects wherever possible. This is especially true in the area of standards.


Why not open source the current Sun Java System Directory Server?
The current Sun Java System Directory Servers, 5.2 and 6.0, have a distinguished heritage and a proven track record. Its codebase is descended from code written by the University of Michigan, Netscape, Sun and Innosoft. The first release of this Directory Server was over ten years ago, when the performance, scalability, and feature set requirements were very different. Maintaining this evolved codebase can be challenging, as making a change in one area often requires in-depth understanding of a number of different components. Starting over allows us to design for current and future needs, while drawing on Sun's decade of experience supporting over 2500 customers and 3 billion deployed entries. Our goal of pursuing a very high level of open source community participation requires a codebase which is highly readable and has maximum function isolation. A fresh start provides a much better chance of achieving that goal.

The Red Hat Fedora Directory Server, which has been released under the GPL, shares a common code ancestry with Sun Java System Directory Server. The split occurred shortly before the release of iPlanet Directory Server 5.1. Sun could have started a similar open source project with the existing Sun codebase. However, we have not seen strong enough community interest in the Fedora Directory Server to believe it would be worthwhile. In addition, Directory Server 6.0 is dependent on a number of third-party libraries for which Sun does not have the right to release the source.

In addition, Sun's current Directory Server is written in C, which would limit the number of open source developer participating as there are many more Java programmers than there are C programmers.

This new open source project is intended to bring significant new value to the market and is designed to be the leading directory service of the future.


Why use Java instead of some other language like C or C++?
Java is a very portable language that allows for quick development of robust applications that work on a wide array of platforms without recompilation. Java has special support for networking and concurrent processing, which has been particularly improved in recent versions. Its exception handling capabilities make it possible to create very robust and stable applications, and it can provide a wealth of debugging information when a problem does occur so that its cause can be quickly identified.

OpenDS is based on Java SE 5, which provides excellent performance. Java bytecode is natively compiled at runtime, which benefits from inspecting the running code and can result in performance that exceeds that of C and C++ applications. Further, there are a number of profiling and other performance analysis tools for Java that can help identify potential hotspots and areas of contention. Finally, Java applications can benefit from performance improvements in the JVM, which is an area that is frequently being improved.


How did OpenDS start?
This project actually started as an internal Sun project over a year ago. Significant development has already been made by a fairly small team of Sun directory engineers, but some of the most challenging and exciting code is yet to be created.


Roadmap
What is the current state of OpenDS?
The only part of OpenDS that is currently being developed is the Directory Server and it is very much a work in progress. The community provides an open development process everyone can see and comment on as the work is being done. However, a minimal functional codebase has been developed so the early participants in the OpenDS community can have something to try and play with for experimentation and to get an understanding of the basic framework. As such, the code available now provides support for the following components and functions:
  • Basic support for all core LDAPv3 operations, including search, bind, modify, add, delete, compare, abandon, and extended operations.
  • Basic support for a number of controls, including proxied authorization, persistent search, LDAP pre-read and post-read controls, LDAP assertions, retrieving matched values, paged results, authorization identity request, password policy controls, and account usability controls.
  • Basic support for several SASL authentication mechanisms, including ANONYMOUS, CRAM-MD5, DIGEST-MD5, EXTERNAL, GSSAPI, and PLAIN. There is also an API to add support for new SASL mechanisms.
  • Support for the "Who Am I?", StartTLS, and cancel extended operations, and an API to add support for new extended operations.
  • A number of APIs to add components to the server, including plugins, password storage schemes, password validators, password generators, monitor providers, logging subsystems, etc.
  • LDIF import and export capabilities.
  • Backend backup and restore capabilities.

There are, however, a number of things that are not yet complete, including:
  • No access control model. All operations are currently allowed for all users.
  • No GUI mechanisms for managing any aspect of the server configuration. There are command-line tools for performing certain administrative tasks, but not for managing the configuration itself.
  • Only a minimal amount of data synchronization (i.e., replication) functionality is available.
  • The password policy functionality is only partially implemented.
  • The server does not currently support online schema updates.
  • The current logging implementation exhibits poor performance and does not provide sufficient flexibility.
  • The server lacks support for a number of controls and extended operations.
  • There is no mechanism for dealing with virtual attributes.

Note that neither of these lists is all-inclusive, and they are subject to change as development progresses. The issue tracking system is the best way to identify the current state of the server and what is planned for the future.


What is the future of the Sun Java System Directory Server?
The Sun Java System Directory Server is still under active development. The 6.0 version will be released in the near future, and work has also begun on future enhanced releases. Sun has not yet decided whether the OpenDS codebase will completely replace the current code for future major versions. OpenDS is being developed for production use in high-performance and high-volume environments, but it remains to be seen how it will meet the needs of the wide range of customers using the current version of the Sun Java System Directory Server.


When will Sun provide a product offering based on OpenDS?
Current plans, which are subject to change, are to have a product offering based on OpenDS by the end of 2007 or early in 2008.


Is OpenDS going to be part of the Sun Java Enterprise System?
No. OpenDS is an open source project and independent of Sun. Whether any Sun product offering based on the OpenDS project will be part of Sun's Java Enterprise System has not been decided, but it is not the plan today.


Is OpenDS compatible with Sun Java System Directory Server 5.2 or 6.0?
Sun expects to maintain a high level of compatibility, although this might not be guaranteed for all features and capabilities.


Are there plans to provide migration tools from the Sun Java System Directory Server 5.2 or 6.0 to OpenDS?
Any tools to assist customers migrating from Sun's Directory Server to OpenDS would be part of Sun's OpenDS-based product offering. It is also possible that the OpenDS community might develop tools for migrating from other existing directory products.


Getting Involved in OpenDS
Where can I get more information on OpenDS?
The OpenDS project site is located at https://opends.dev.java.net/.


Where do I start?
The best place to start is the OpenDS home page, where you can find links to OpenDS downloads, source code, mailing lists, discussion forums, white papers, and more. You can also find information about participating in the community on the Contributing to OpenDS page.


Where do I get help?
You can find all of the project documentation at the Documentation Depot, so that's a good place to start. You can also send questions to one of the project mailing lists. If you have a general question about OpenDS, try users@opends.dev.java.net. If you have a developer-related question, try dev@opends.dev.java.net. For a complete list of the project's mailing lists and information on how to subscribe, see the Mailing Lists page.


How can I get involved as a developer?
First, register as a user on the java.net site at https://www.dev.java.net/servlets/Join. Then visit https://opends.dev.java.net/servlets/ProjectMembershipRequest and request a role in the OpenDS project. Also see the Contributing to OpenDS page for additional information.


How can I get involved as a user?
Visit the project site at https://opends.dev.java.net/ and read the information on the OpenDS Downloads page.


What are the platforms supported by OpenDS?
OpenDS requires a Java SE 5.0 or higher runtime and can be built and run any any hardware platform supporting this environment.


How can I check out and build OpenDS?
The OpenDS project site has instructions on how to both check out the source and to build the server. See the OpenDS Source Guide (in either OpenDocument or PDF form) for more detailed information.


How can I get pre-built versions of OpenDS?
Pre-built versions of OpenDS are available for download at downloads_index.html.


What is available on the OpenDS project site?
The OpenDS project site contains the source code, documentation, discussion forums, and other links to relevant information. In addition, it contains instructions on how to become involved in this project.


Governance
What license is used for the OpenDS codebase?
The OpenDS code is released under the Common Development and Distribution License (CDDL). Information about this license can be found at https://opends.dev.java.net/OpenDS.LICENSE and at http://oss.oracle.com/licenses/CDDL.

The CDDL is an OSI-approved open source license that is based on the Mozilla Public License (MPL) but adds additional benefits like extending the use of any covered patents to those that use the code and offering a degree of protection against patent litigation. Further, the CDDL is a file-based license, which ensures that any code released under the CDDL will remain open but does allow it to interact with code under other licenses (even closed source licenses).

The GNU Public License (GPL) is another popular open source license, but Sun does not feel that it is appropriate for use with the OpenDS Directory Service. The GPL does not offer any form of patent protection, nor does it interact well with code under any other license. Recent proposals for the GPLv3 do appear as if they might address these concerns. If the released version of this license is acceptable Sun might consider dual-licensing the code under both CDDL and GPLv3.


What is the OpenDS governance model?
The OpenDS project follows a simple governance structure:
  • Decisions are made in public discussion groups.
  • Decisions are made by consensus, rather than voting.
  • Decisions are made transparently and any member of the project can voice their concerns.

Everyone is welcome to join the OpenDS community and make contributions. OpenDS members follow the code of conduct and abide by the governance process. OpenDS members can participate in one or more of the following roles:
  • User
  • Contributor
  • Committer
  • Project Owner
  • Project Manager

See the OpenDS Governance Model for more details.


Can I create specific features for OpenDS?
One of the values of open source projects is the ability to share, collaborate and enrich a product. Although the ability to commit into the source will be enforced by the governance policy, you will be able to create your own features.


If I build the code for OpenDS, can I call it OpenDS or Sun Java System Directory Server?
No. If you build your own version of the product based on the OpenDS codebase, you cannot use "OpenDS", "Sun Java System Directory Server", or any other trademarked terms in the name of that product.


Can I repackage OpenDS and bundle it in my own solution?
Yes, within the terms of the CDDL.


Can I build OpenDS and provide distributions to others?
Yes, within the terms of the CDDL.


Can I expand OpenDS interfaces?
Yes, within the terms of the CDDL.


Can I buy support for OpenDS?
Yes. OpenDS is a community open source project that Sun Microsystems provides support for under the product name Sun OpenDS Standard Edition (SE). If you are interested in getting commercial support for your implementation of OpenDS please go here for more information: http://wikis.sun.com/display/sunopends/Home.
In addition to this commercial offering, you can contact the OpenDS community via IRC (#opends on irc.freenode.net) or one of the email lists and ask for help and direction.


Do I need to register to use the OpenDS source code?
There is no need to register in order to access the OpenDS source code, precompiled builds, or project documents. Only your e-mail address is necessary for participating in the mailing lists. Registration through java.net and membership in the OpenDS project will be required if you wish to contribute to the project or create issues in the issue tracker.


Other Questions
Can Sun Java Enterprise System applications work with OpenDS?
OpenDS will be LDAPv3 compatible. However, testing with Sun Java Enterprise System will not be performed.


Does the 200,000 entry Directory Server license provided in Solaris licenses apply to OpenDS?
No. OpenDS is an open source project and no licensing fees are required for its use. Also the current license for Directory Server entries included with Solaris does not apply to Sun OpenDS Standard Edition, the commercial offering based on OpenDS.


Is there any cost for using OpenDS?
No. The OpenDS code is free to use, free to modify, and free to redistribute, within the terms of the Common Development and Distribution License.
However, if you want to purchase commercial support from Sun Microsystems by purchasing a license to OpenDS Standard Edition at http://wikis.sun.com/display/sunopends/Home.


If there is a strong community for OpenDS, should I still buy a service contract from Sun to get support on Sun's commercial offering?
Sun's commercial offering is Sun OpenDS Standard Edition. Buying support for the Sun product will provide to you high level of service and ensure timely answers to your critical support request. A support contract would also guarantees you access to future upgrades.


What is the difference between a project, a community, a codebase, and a product?
An open source project consists of the source code, a set of goals, and the rules that bring the community together.

The community is a group of people who work together to use and contribute to the project.

A codebase is the source code for the project.

A product is a commercial offering based on the codebase.
 
 
Close
loading
Please Confirm
Close