From OpenIDM to Success

I started my work on OpenIDM almost precisely five years ago . At that time, ForgeRock was only a couple of months old. OpenIDM was just a very small bunch of ragtag prototype code that did not make much sense. I was the only one in the team that had any product development and architecture experience. So naturally, my job was to create OpenIDM architecture and design. One month later, the architecture of a brand new IDM system appeared. This is a photo of my whiteboard from 28th May 2010:

If you remember OpenIDM version 1, this certainly looks very familiar. A couple of days later I have refined it in semi-formal diagram:

All the major components and interfaces are there. After that, I have created the basic data model, formalized it in the schema and the development of OpenIDM code has started.

The months that followed were not easy. One of the fundamental requirements given by ForgeRock was that OpenIDM has to be based on OpenESB. I had quite bad experience with ESB from my previous projects. But this requirement seemed to be non-negotiable. Therefore, I have secretly created an architecture that can run on ESB but that does not depend on it. I was right. OpenESB proved to be a very bad idea. It frequently died with very helpful error messages such as “null” and it was a nightmare to use it. Even though OpenESB was open source, we could not fix it because we could not find anyone who can actually build the source code. This made the development very slow and painful.

I have introduced my friend Igor Farinic to the project. Together we have also added two more developers, Katka Valalikova and Vilo Repan. This created the “nLight” part of OpenIDM team. We were partially paid for our work and we were partially volunteering. We had agreed on a fixed monthly rate that barely covered our expenses. And in the end we have done more than twice the work that we had promised. We were not paid for that extra work. We really believed in OpenIDM at that time.

I also remember frequent arguments with Laszlo Hordos over the technology. But I guess this is the part of the game when you are creating something new. I also had to work on other projects to cover the expenses of our small company (nLight). It was not exactly a walk in the park. But despite all of this, we had OpenIDM prototype in summer 2010. And in autumn 2010 we had something that resembled an early product. And it even almost worked. Someone from ForgeRock suggested that we really should not start from version 1.0. Therefore, the decision was that the first OpenIDM version would be OpenIDM 1.5. That was October 2010. OpenIDM 1.6 followed shortly after that.

Then January 2011 came and also the OpenIDM Design Summit in Oslo. I had a presentation about OpenIDM architecture. I’ve met Andi Egloff there. He was a ForgeRock fresh hire. Almost immediately we had a very fierce discussion about OpenESB. Andi held that ESB is a key to the IDM technology. I opposed that it does not bring any substantial value. We could not agree.

Things were moving suspiciously slowly after that meeting in Oslo. In early spring, I received a surprise call from Jamie Nelson who has recently merged his company with ForgeRock. He simply told us that they are moving OpenIDM development in-house. The entire “nLigth” part of the team was effectively expelled from OpenIDM project. Without any warning.

We were told to stop our work on OpenIDM. That was a real surprise. We wanted to cooperate. But we were not allowed to. I must say that ForgeRock eventually paid all the money that have been agreed. But this was not about the money. We needed a product. ForgeRock was absolutely silent about OpenIDM future. We have patiently waited for several months. Nothing happened. No explanation, no news, no roadmap update, nothing.

Later we have learned that ForgeRock scrapped the entire OpenIDM version 1. They have silently started to redesign everything. There was OpenIDM version 2. But we have not been invited to this party. The first months of OpenIDM 2 development were obviously conducted in a very closed manner. The source code was not public at that time. We have only learned about this retrospectively by looking at the OpenIDM 2 source code history.

So after few long months of information silence, we decided that we have to do something ourselves. We had copyright over the majority of OpenIDM 1 code (there were four developers from “nLight” and only one from ForgeRock in the OpenIDM 1 team). Therefore, we have decided to start a new project and pulled in our code from OpenIDM 1. The OpenESB was the first thing that we (very happily) removed. I originally designed OpenIDM 1 not to depend on ESB. Thus, removal of OpenESB was even easier than I expected. We reimplemented the parts that were missing. And that’s how midPoint project started. The developers that once believed in OpenIDM and were expelled, established a new company: Evolveum. And we worked at improving the software that we believed in.

Here we are four years later. MidPoint is currently the most comprehensive open source IDM system available. MidPoint is approximately four times bigger than OpenIDM 3. I think that this can be considered a major success. Humble open source company with a very tight budget created a technological marvel. A product several times bigger than what a shiny big ForgeRock fueled by VC millions could ever do.

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

2 thoughts on “From OpenIDM to Success

  • Are you seriously suggesting that “more code” == “better”? If so then I expect “your code” == “worse” without even knowing what OpenIDM is like internally.

    How about a feature-by-feature comparison with an objective analysis? The blog above reads like nothing more than a rant about getting fired backed by a childish (and misdirected) jab at the product you’re no longer a part of.

    • No, “more code” does not necessarily means “better” in a generic case. But when it comes to two systems that solve very similar set of problems by using a very similar technology then it is somehow likely that the system that is several times larger can be possibly more advanced, don’t you think?

      This is also supported by the feature-by-feature analysis, which is linked from the post.

      BTW, I would say that I quite know how OpenIDM code looks internally. Otherwise I would not dare to write this post.

Leave a Reply