Never Use Closed-Source IAM Again

I will never use any closed-source IAM again. You will have to use force to persuade me to do it. I’m not making this statement lightly. I was working with closed-source IAM systems for the better part of 2000s and it made quite a good living. But I’m not going to do that again. Never ever.

What’s so bad about closed-source IAM? It is the very fact that it is closed. A deployment engineer cannot see inside it. Therefore the engineer has inherently limited possibilities. No documentation is ever perfect and no documentation ever describes the system well enough. Therefore the deployment engineer is also likely to have limited understanding of the system. And engineer that does not understands what he is doing is unlikely to do a good job.

Closed-source software also leads to vendor lock-in. That makes it unbelievably expensive in the end. The Sun-Oracle acquisition of 2010 clearly demonstrated the impact of vendor lock-in for me. Our company was a very successful Sun partner in 2000s. But we have almost gone out of business because of that acquisition and the events that followed. That was the moment when I have realized that this must never happen again.

Open source is the obvious alternative. But how good it really is? Can it actually replace closed-source software? The short answer is a clear and loud “Yes!”. The situation might have been quite bad in 2000s. But now there is a lot of viable open source alternatives for every IAM component. Directory servers, simple SSO, comprehensive SSO, social login and federation, identity management, RBAC and privileges and so on. There is plenty to choose from. Most of these projects are in a very good and stable state. They are at least as good as closed-source software.

But what is so great about open source software? It makes no sense to switch to open source just because of some philosophically-metaphysical differences, does it? So where are the tangible benefits? Simply speaking there are huge advantages to open source software all around you. But they might not be exactly what you expect.

Contrary to the popular belief the ability to meddle with the source code does not bring any significant direct advantage to the end customer. The customers are unlikely to even see the source code let alone modify it. But this ability brings a huge advantage to a system integrator who deploys the software. The deployment engineers do not need vendor assistance with every deployment step. The source code is the ultimate documentation therefore the deployment engineers can work almost independently. This eliminates the need for hugely overpriced vendor professional services – which also reduces the cost of the entire solution. The deployment engineers can fix product bugs themselves and submit the fixes back to the vendor. Which significantly speeds up the project. Any competent engineer can fix a simple bug in a couple of days if he has the source code. He or she does not need to raise each and every trivial issue and fight the way through all the levels of bloated support organization. And then wait for weeks or months to get the answer from the vendors development team. The open source way is so much more efficient. This dramatically reduces the deployment time and also the overall deployment cost.

The source code also allows ultimate customization. Software architects know very well how difficult it is to design and implement good extensible system. As with many other things it is actually very easy to do it badly but it is extremely difficult to do it well. A system which has all the extensibility that the IAM needs would inevitably become extremely complicated. Therefore the best way how to customize a system is sometimes the simple modification of the source code. And this is only possible in open source projects. Oh yes, there is this tricky upgradeablity problem. Customizations are difficult to upgrade, right? Right. Customized closed-source software is usually very difficult to upgrade. But that does not necessarily applies to well-managed open source projects. Distributed source code control software such as Git makes this kind of customization feasible. We are using this method for years and it survived many upgrades already.

But perhaps the most important advantage is the lack of vendor lock-in. The source code of open source project does not “belong” to any single individual or company. If the product is good there will be many open source companies that can offer services that only a single closed-source vendor can provide. This creates a healthy competition. In the extreme case the partner can always take over the product maintenance if the vendor misbehaves. Therefore it is unlikely that the cost of the open source solution spins out of control. Open source also provides much better protection against vendor failure. Yes, I’m aware that many companies behind the open source projects are small and that they can easily fail. But in the open source world the company failure does not necessarily mean project failure. If the project is any good then it will continue even if the original maintainer fails. Other companies will take over, most likely by employing at least a part of the original engineers. And the project goes on. This is the ultimate business continuity guarantee. And it has happened several times already. On the other hand the failure (or acquisition) of a closed source vendor is often fatal for the project. This has also happened several times. And we still feel the consequences today.

The difference between open-source and closed-source world is enormous. Any engineer that ever goes there and understands open source is very unlikely to go back. Open source is much easier to work with. The engineers have the power to change what they do not like. Open source is much more cost efficient and the business model is sustainable. And it actually works!

Therefore I would never ever use closed-source IAM again.