20060325 forking with sun almost - plembo/onemoretech GitHub Wiki

title: Forking with Sun - Almost link: https://onemoretech.wordpress.com/2006/03/25/forking-with-sun-almost/ author: lembobro description: post_id: 748 created: 2006/03/25 12:46:00 created_gmt: 2006/03/25 12:46:00 comment_status: open post_name: forking-with-sun-almost status: publish post_type: post

Forking with Sun - Almost

With their latest version releases, the Netscape family directory products of Sun and Red Hat have finally forked significantly enough to make seamless interoperability a thing of the past. The different algorithms used for replication now make it impossible for these latest directories to replicate with each other. This was to be expected. Intellectual property law concerns really demanded it, especially if Sun’s version was to remain a proprietary product.

At my company we have opted to remain with Sun, primarily because by doing so we can avoid the steep initial cost of purchasing Red Hat’s commercially supported product (I opted not to push for implementation of the free Fedora Directory product sans support, which would have been too radical a step for them). I’ve already deployed the latest release of Sun Java Systems Directory (v5.2) in development, and hope to move quality and production over to it in good order. The demand for high availability has finally forced us to adopt a multi-master model, which is not supported by OpenLDAP, and the need to simplify sign-on has led us to begin testing Sun’s Identity Synchronization for Windows, for which their directory product (among other things) is a dependancy. Red Hat/Fedora could have satisfied both these requirements with their slightly different solutions, but unfortunately the startup cost of licensing the necessary instances was prohibitive. As a long-time Sun customer our cost to implement Sun’s solution was … $0.

I don’t see this as necessarily a loss for Red Hat. It may very well be that Red Hat does not have the resources to do this yet, or that they aren’t yet convinced that directory services should be part of their core business. There’s nothing wrong with that. Deployment of directory services has become just one step in building an Identity Managemnt infratructure, and Red Hat does not really have its own IM offering. The big players in that space are CA (with the former Netegrity SiteMinder product), Sun (with its Java Systems Identity Management Suite), Oracle and Microsoft. Of these, only CA and Sun’s offerings are real end-to-end solutions, and I would argue that Sun is the more complete of these two.

Of course we run the CA solution in my work environment — which at the time seemed to be the way to go (Sun’s entire product line was in serious flux at the time). Time will tell whether any other vendor will be able to make a dent in this market. I doubt that Red Hat will try. Their best strategy is to continue concentrating on their core compentency in providing the best server OS platform available (not that I don’t expect some movement toward a compelling desktop product soon — more on that in my other blog).

The upshot of all of this is that now that we’ve forked with the Sun product, there’s really no easy was to turn back. For all intents and purposes my company won’t be exploring deployment of Red Hat Directory going forward. Barring the collapse of Sun, or its abandonment of its own directory, we’re now stuck with them. There is the possibility that Sun will participate in the Fedora Directory project and contribute their own changes to it. I don’t see that happening in the near term, although I think it would be a huge benefit to the entire OSS community.

Copyright 2004-2019 Phil Lembo