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
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.
Getting Involved in OpenDS
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:
What are the primary goals of the OpenDS software?
- 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.
Why not contribute to an existing open source directory project?
- 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
- 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
- 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
- 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
- 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.
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
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
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.
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
- 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
- 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,
- 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
- Only a minimal amount of data synchronization (i.e., replication) functionality is
- 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
- 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
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.
Where can I get more information on OpenDS?
The OpenDS project site is located at
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
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 firstname.lastname@example.org
. If you have a developer-related question, try email@example.com
. For a complete list of the project's mailing lists and information on how to subscribe, see the Mailing Lists
How can I get involved as a developer?
First, register as a user on the java.net site at
and request a role in the OpenDS project. Also see the
Contributing to OpenDS
for additional information.
How can I get involved as a user?
Visit the project site at
and read the information on
the OpenDS Downloads
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
out the source
. See the OpenDS Source Guide (in either
form) for more detailed information.
How can I get pre-built versions of OpenDS?
Pre-built versions of OpenDS are available for download at
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.
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
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
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:
- Project Owner
- Project Manager
See the OpenDS
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
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:
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.
Can Sun Java Enterprise System applications work with OpenDS?
OpenDS will be LDAPv3 compatible. However, testing with Sun Java Enterprise System will not be
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.