
ForgeRock quietly cuts off “trunk” access to OpenAM, OpenDJ, and OpenIDM - GuyPaddock
Around 2 AM Eastern Time on 11&#x2F;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.<p>In place of those repositories, they&#x27;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&#x27;t going to be able to get any security updates unless they pony up to the pricey Enterprise Edition.<p>Technically, the CDDL does require them to provide some copies that do not require a commercial license, but there&#x27;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.
======
GuyPaddock
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...](https://forgerock.org/topic/where-has-the-trunk-
gone/#post-14593)):

"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."](https://backstage.forgerock.com/downloads.")

~~~
willow9886
What are your thoughts on this statement, Guy?

~~~
GuyPaddock
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/](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".

~~~
willow9886
Thanks, Guy!

------
willow9886
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](http://gluu.org)

~~~
Yeroc
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.

~~~
webmaven
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.

------
Yeroc
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/](http://www.keycloak.org/)

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

~~~
GuyPaddock
UPDATE: Their latest statements can be found here:
[https://forgerock.org/topic/where-has-the-trunk-
gone/](https://forgerock.org/topic/where-has-the-trunk-gone/)

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

~~~
GuyPaddock
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.

