Symas Blog

Last week Andrew Bartlett of the Samba Team posted a query about how to handle
a desired extension to LDAP. The question was cross-posted to the Samba-Technical, OpenLDAP-Technical, and Fedora-Directory-Devel mailing lists. Within a few minutes, developers from the OpenLDAP community responded, proposing a general-purpose solution. Within a few hours an implementation of the solution in OpenLDAP was made available for use. Within a few days a formal specification was made available for review/comment. This rapid progression from problem-statement to working solution is a fine example of the open source development model at work. (The Fedora project remains silent. But is that so bad?)

A lot of people survey the landscape and say it’s good for the open source community to have multiple competing LDAP projects. They say that competition is good and creating choice is good. Those people are wrong.

If it’s not broken, we don’t waste time fixing it. If a project is alive and innovative and sensitive to the needs of its users and the aspirations of its developers, we don’t need to start from scratch for no apparent reason other than to create a competitor. Of course people can start competing projects for their own reasons, but they’re putting an enormous amount of effort into catching up and a tiny amount of effort into innovation.

Competition is a last resort approach that people take when they have no other choice. It’s a choice you’re forced into, when you’re operating in a closed-source environment. In reality, cooperation is always better; it allows the rapid exchange of ideas and information and prevents needless duplication of effort. Cooperation allows projects to innovate at full speed, and allows the entire state-of-the-art to advance at speeds that closed-source competition can’t match.

Having choices in feature sets and capabilities is always good. But freedom of choice is only good when all of the choices are of equal quality, equal merit. For example, there’s a plethora of choices in Linux distributions, and all of them are technically sound. But there’s only one Linux kernel. There’s only one libc… There are thousands of contributors to the kernel – they’re all creating choices for end users, by supporting new features, but for the most part they’re not duplicating their effort. (Notable exception – the Radeon/RadeonHD video drivers. Yet another mess that needs to be cleaned up…)

Fragmentation of expertise into separate projects merely dilutes the effectiveness of the developers. Forking of projects tends to be the kiss of death to one or the other team. The only sane way forward is for all developers of a technology to share the same sandbox and make sure that the best ideas from all contributors are promoted to a consolidated, consistent release. That’s one of the elements of the Linux kernel’s success. That’s what the LDAP scene needs as well, and it’s going to keep stumbling over pointless incompatibilities until this consolidation occurs.

On the LDAP scene, the fact that we have multiple choices for libraries is ancient history. But these choices are not technically equivalent; they are not of equal merit. Even the developers at Sun have acknowledged this fact:

Almost all other known Linux FOSS based utilities using LDAP,
use OpenLDAP libraries by default. The current maintainers
of the Mozilla LDAP code base are currently expressing no
interest in continuing to enhance Mozilla libldap beyond
existing minimal maintenance efforts. In reality the OpenLDAP
distribution is moving forward, while the Mozilla distribution
has stagnated.

In fact Mozilla has all but abandoned the code themselves:

4) Remove the capability from core to build the LDAP code
…

It’s an understandable action, because their library is now more of a liability than an asset; it causes the Mozilla apps to crash on common Linux distributions. But we at Symas believe that more apps should be LDAP-enabled, not less. Notice that on the Mozilla bug report, it’s noted that the crash can be fixed simply by linking against the OpenLDAP libraries. Moreover, we have submitted a patch on that bug report to integrate OpenLDAP’s libraries into the Mozilla code.

Something to keep in mind – in a competition, somebody wins, and someone else loses. With cooperation, everybody wins.

Open source is no magic bullet in itself. To steal a thought from Irving Kristol (“It’s not enough to be Hungarian, you must have talent too.”), it’s not enough to be open source. You still have to work smart. Our collaboration with the Samba and Mozilla teams proves that cooperation trumps competition. Our relentless dedication to the technology speaks for itself – most of our competitors in the directory space, including Novell, IBM, and now Sun, are using the OpenLDAP libraries in their products.