Comparing Disasters

A month ago I have described my disappointment with OpenAM. My rant obviously attracted some attention in one way or another. But perhaps the best reaction came from Bill Nelson. Bill does not agree with me. Quite the contrary. And he has some good points that I can somehow agree with. But I cannot agree with everything that Bill points out and I still think that OpenAM is a bad product. I’m not going to discuss each and every point of Bill’s blog. I would summarize it like this: if you build on a shabby foundation, your house will inevitably turn to rubble sooner or later. If a software system cannot be efficiently refactored, it is as good as dead.

However, this is not what I wanted to write about. There is something much more important than arguing about the age of OpenAM code. I believe that OpenAM is a disaster. But it is an open source disaster. Even if it was bad, I was able to fix it and make it work. It was not easy and it consumed some time and money. But it is still better than my usual experience with the support of closed-source software vendors. Therefore I believe that any closed-source AM system is inherently worse than OpenAM. Why is that, you ask?

Firstly, I was able to fix OpenAM by just looking at the source code. Without any help from ForgeRock. Nobody can do this for closed source system. Except the vendor. Running system is extremely difficult to replace. Vendors know that. The vendor can ask for an unreasonable sum of money even for a trivial fix. Once the system is up and running, the customer is trapped. Locked in. No easy way out. Maybe some of the vendors will be really nice and they won’t abuse this situation. But I would not bet a penny on that.

Secondly, what are the chances of choosing a good product in the first place? Anybody can have a look at the source code and see what OpenAM really is before committing any money to deploy it. But if you are considering a closed-source product you won’t be able to do that. The chances are that the product you choose is even worse. You simply do not know. And what is even worse is that you do not have any realistic chance to find it out until it is too late and there is no way out. I would like to believe that all software vendors are honest and that all glossy brochures tell the truth. But I simply know that this is not the case…

Thirdly, you may be tempted to follow the “independent” product reviews. But there is a danger in getting advice from someone who benefits from cooperation with the software vendors. I cannot speak about the whole industry as I’m obviously not omniscient. But at least some major analysts seem to use evaluation methodologies that are not entirely transparent. And there might be a lot of motivations at play. Perhaps the only way to be sure about the results is to review the methodology. But there is a problem. The analysts are usually not publishing details about the methodologies. Therefore, what is the real value of the reports that the analysts distribute? How reliable are they?

This really is not about whether product X is better than product Y. I believe that this is an inherent limitation of the closed-source software industry. The risk of choosing inadequate product is just too high as the customers are not allowed to access the data that are essential to make a good decision. I believe in this: the vendor that has a good product does not need to hide anything from the customers. So there is no problem for such a vendor to go open source. If the vendor does not go open source then it is possible (maybe even likely) that there is something he needs to hide from the customers. I recommend to avoid such vendors.

It will be the binaries built from the source code that will actually run in your environment. Not the analyst charts, not the pitch of the salesmen, not even the glossy brochures. The source code is only thing that really matters. The only thing that is certain to tell the truth. If you cannot see the source code then run away. You will probably save a huge amount of money.

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn

7 thoughts on “Comparing Disasters

  • Radovan,

    What’s the point in calling OpenAM Open Source? While I agree there is a version that is opensource(d) it is a nightly build (which FR has even pulled a few times) that doesn’t even resemble production quality code much less the issues with the Java 1.2-1.4 foundation. Leaving you with a singular choice for support and that is a 100% closed source binary with SAAS style vendor lock-in which IMO is a significant step backwards from closed source products.

    Think through this with me, even if you were to purchase a subscription and receive the closed source production code (only provided with subscription) and fix one of the 1000′s of security vulnerabilities, once it was recompiled to institute the fix ForgeRock would no longer support it.
    At least with IBM, CA, Oracle one can purchase perpetual licenses without annual pricing thats subject to the whims of the leadership team.

    • OpenAM is technically open source. It may not be “free as in speech” and it definitely is not “free as in beer”, but there is no doubt that it is open source. IANAL, but due to the CDDL license ForgeRock cannot distribute binaries without also distributing the source code: “Any Covered Software that You distribute or otherwise make available in Executable form must also be made available in Source Code form …” Therefore I doubt that the “production code” is really different from the source code which is available. I personally haven’t observed any differences. The other thing is that they obviously have private branches, but once they distribute the binaries they are bound by CDDL (please note that ForgeRock is NOT the original developer of OpenAM, they do not own the copyright and therefore they do not have the option of dual-licensing).

      As to the vendor lock-in: I believe that OpenAM is not worse than that of closed-source software. It is actually much better. I was able to fix OpenAM without any help from ForgeRock and without any subscription. I know it because I did it. Personally. Therefore it is possible to use OpenAM and do not pay ForgeRock a single dollar. I could agree that this is not a smart thing to do. But it is possible. However this very thing is not possible with closed source software. Even if you pay an arm and a leg for the software and support you do not have the right to fix the issues yourself. Only vendor can do that. And a software that cannot be fixed is a a dead software. Therefore I strongly believe that the vendor lock-in of closed source software is much worse than any limitations of any open source projects.

    • My opinion is than WSO2 Identity Server seems to be a good fit for federation-like scenarios. But as far as I know it is not very suitable for SSO inside enterprise, web sites, etc (e.g. the Apache agent does not seem to be publicly available. At least it was not a year ago, last time that I’ve checked). The source code seems to be OK, but I haven’t spend much time analyzing it. There were other aspects of WSO2 that were a showstopper to WSO2 IS usage for me and these were more “philosophical” and not really technical. There is one warning sign though: WSO2 is using Subversion. Therefore the development process is unlikely to be very community-friendly.

      I have only very little information about Keycloak. I haven’t had the time for a closer look yet.

Leave a Reply