ForgeRock quietly cuts off “trunk” access to OpenAM, OpenDJ, and OpenIDM | Hacker News Reader

ForgeRock quietly cuts off “trunk” access to OpenAM, OpenDJ, and OpenIDM

9 pointsGuyPaddock15 comments

Around 2 AM Eastern Time on 11/29, it appears that ForgeRock -- who develops OpenAM, OpenDJ, and OpenIDM -- quietly cut off public access to their CDDL trunk repositories for all of their projects.

In place of those repositories, they've spun up repositories that have only the source from the last major versions, which means that ForgeRock is quietly blocking out the community from contributing. It also means that any small-shop deployments who rely on the open source edition aren't going to be able to get any security updates unless they pony up to the pricey Enterprise Edition.

Technically, the CDDL does require them to provide some copies that do not require a commercial license, but there's some gray area as to which types of releases have to be public releases vs. private. ForgeRock has decided that the CDDL only applies to major (whole version) releases.

View on HN

Aaron Kozak, the Digital Marketing Coordinator for ForgeRock, has released the following statement (see: https://forgerock.org/topic/where-has-the-trunk-gone/#post-1...):

"We apologise for any inconvenience our recent changes may have caused. We are preparing for the next major release of the ForgeRock Identity Platform and as part of this process, we are no longer providing public access to our nightly builds and source code for the upcoming platform release. Open source downloads are still available via https://backstage.forgerock.com/downloads."

What are your thoughts on this statement, Guy?

TL;DR My thoughts are that this is somewhat of a non-answer from them.

If we take their statement at face value, then we'd have to make the following assumptions for this to make sense:

1. They have an upcoming coordinated release of at least two products, but likely all of the products (otherwise, it would only make sense to have cut off access for the products that are about to ship).

2. There must be some new feature(s), which have not yet been merged into the master branches, planned for the new versions that they want to keep under wraps so they can announce them and disrupt the market for a short time (or else there's no advantage to closing off access because anyone mirroring already has snapshots of the upcoming release).

Even with these assumptions, its a bit weak. If they're releasing something as-of-yet unseen in the new release, they will still have to release the source code to whatever that is when they publicly post the new version, so if "staying ahead of the joneses" (i.e. competition) is the main driver it's probably only a 6 month lead, at best.

A suicidal move for them would be to pull even the major releases from public release. In my experience setting up, customizing, and deploying the ForgeRock suite, I can say that there are enough moving parts that a prospective client needs to be able to play with it for a bit and see if it's a fit in the client's environment. Despite what others may have written elsewhere on the net, I'm not saying anything is incomplete or that the design is counter-intuitive -- after coming up the learning curve on some foundational concepts, the way they've laid it all out makes sense. It's just that, their sales cycle would be a nightmare if they can't actually put something in the prospect's hands without inking an agreement. Let alone the fact that any binary trial version is still subject to CDDL licensing requirements for the source code.

My immediate question after this statement was posted was to ask if this lack of access is expected to continue even after the release. You can follow the thread here: https://forgerock.org/topic/where-has-the-trunk-gone/

Their response was a second non-answer along the lines of "I'm sure there will be a statement at that time".

Thanks, Guy!

I would encourage anyone who wants a truly open source IDP platform to consider the Gluu Server[1]. The Gluu Server supports open web standards for authentication and authorization, including SAML 2.0, OAuth 2.0, OpenID Connect, UMA, FIDO U2F, SCIM, and LDAP. It is one of the only--perhaps the only--enterprise-grade identity and access management platform that can be used in production, with an unlimited number of users, without paying a license.

[1] http://gluu.org

That said, I imagine anyone running a large deployment will most likely want to purchase a support contract anyways. This is why I don't understand the ForgeRock move (assuming this was intentional -- hard to say at this point): The people that are running larger deployments almost certainly have the budget and need support anyways so I'm doubtful that making the move make the source code less open helps their business in anyway.

Adding intrinsic (as opposed to extrinsic) switching costs is usually a bad idea over the long term, but only if your customers (actual or potential) are savvy enough to notice. With that in mind, the approach is much more difficult to pull off with Open Source software.

So, investors want (even demand) barriers to entry (for competitors) and/or exit (for customers) to enable extraction of attractive rents. It can work very well over the medium term, although it will typically increase CAC, and lengthen the sales cycle.

Still, over the time period that VCs care about, a cash warchest can be used to fuel hockey-stick growth and provide an attractive multiple upon exit, after which growth will often slow or even stall without fresh infusions of cash.

The annoying thing about the way this unfolds over and over again, is that it's a cheap trick that isn't really necessary. Equivalent (and far more sustainable) barriers can be erected that don't mandate nuking the developer community around your code.

I agree... it seems that getting the code into peoples hands would be a positive business driver. But once you raise $50m+ in venture capital, all bets are off.

Again, my main criticism of Gluu is lack of a transparent security record (I posted a bit more on this lower down in this thread).

I haven't used it myself but I've been keeping an eye on Keycloak[1] (sponsored by RedHat) for awhile now and it looks promising.

[1] http://www.keycloak.org/

A request for clarification was sent to the ForgeRock contributions email address, but it has so far gone unanswered.

UPDATE: Their latest statements can be found here: https://forgerock.org/topic/where-has-the-trunk-gone/

That's why everyone is switching to Gluu....

One other major problem with Gluu -- where is its security track record? Where do they keep track of security issues and the appropriate fixes to patch them? If it's on their site, it's hard to find, but then most things on the Gluu site _are_ hard to find.

They don't even make a list of their most prominent customers public on their site.

Keycloak, on the other hand, is supported by RedHat, so any advisories relating to it come out through their normal advisory system. A user considering Keycloak or OpenAM is in a much better spot to make an informed decision about security than one considering Gluu, for these reasons.

We strongly considered Gluu, but it's not far enough along.

Reply on news.ycombinator.com