We’ve talked about Growing the Community and the virtue of Cooperation over Competition before. I just wanted to take a moment to reflect on how we’re doing. The upcoming LDAPCon provides a perfect opportunity to illustrate the point.
Chaotic growth doesn’t help anyone; it’s just cancer. We’re after harmonious growth, where all the members of the community benefit and advance together. Looking at the LDAPCon Agenda you’ll see a fair amount of collaboration between projects that formerly were painted as competitors – OpenLDAP collaborating with OpenDS, OpenDS and ApacheDS, and ApacheDS with OpenLDAP. This may be surprising to some, but it shouldn’t be. (In fact one audience member at the MySQL User Conference even asked what OpenLDAP’s competitors have to offer (in regards to OpenLDAP’s new NDB backend) and my response was “what competition?” In the OpenLDAP Project we only compete with ourselves, working hard so that the next version is always better than the last…)
Competition is based on the notion of winners and losers. But in the world of interoperability and open standards, if there is a loser, there can be no winners. If our software fails to work as expected with someone else’s, nobody wins – everyone loses. The end-users lose, because they’re stuck with an ugly data management problem, and the software authors lose, because they have to spend time figuring out what went wrong, and how to correct things while doing the least possible damage to anything else in the system.
So when we work on this technology, we spend a lot of time identifying shortcomings in what exists today, listening to feedback from our user communities and from the surrounding communities. And then we take what we’ve learned and disseminate it as broadly as possible, to help as many as possible.
For example, the LDAP Password Policy specification had been lying dormant for several years, with the last public revision made in July 2005. One of the goals for that specification was that it be usable by other software that relies on LDAP for authentication storage. But over the course of time its utilization by other authentication providers (such as SASL, Kerberos, or Samba) has been nearly nonexistent. I’ve surveyed the requirements of these other communities and edited a new revision of this specification to address some of the areas that still had holes, and to facilitate its use by the larger community. Given the crucial role that password management still plays in computer security, it is vital to get this design right and to get it widely adopted.
Likewise, the ever popular RFC2307, specifying a mechanism for using LDAP as a Network Information Service, has long been in the need of some attention. The last revision was published back in February 2005 and still left several open items unresolved. As this is the specification that every Unix / Linux / POSIX-based system now uses for interoperating with LDAP, it’s also of crucial importance for computer installations everywhere. I’ve published a new revision of this spec as well, tying it into the Password Policy spec to leverage that work and provide a clear direction forward for POSIX security management.
The aim of this effort is to improve computer security – not just for Symas customers, or OpenLDAP users, but for *everyone*. We don’t live in isolation, we live in a globally interconnected, interdependent community. We all rise and fall together. This fundamental truth is why Open Source and Open Standards are so powerful, and why “proprietary solution” is an oxymoron – if your work only touches a small subset of the population, and no one but you is allowed to see inside and know how it works, then it is not a solution at all. (Sometimes that’s hard for people to see: a lot of industries today are only oriented toward addressing symptoms, which is not the same as solving problems.)
Of course there’s still a lot of work left to do, on this front and on many others. If you’re interested in learning more, drop us a line. Or stop by in Portland at LDAPCon and say Hi…
