Skip to end of metadata
Go to start of metadata

This is to explain exactly how the development process and the process to commit changes and new code into OpenAM.

The ForgeRock project organization is structured as a hierarchy of users, that are promoted based on merit. 

We have four types of contributors:


A Listener is someone that uses our software. They contribute to the ForgeRock projects by providing feedback to developers in the form of bug reports and feature suggestions. Users participate in the ForgeRock community by helping other users on mailing lists and user support forums. The passive users are also known as lurkers.


A Fan is a user who has an account on the IdP, and contributes to a project in the form of code or documentation. They take extra steps to participate in a project, are active on the developer mailing list, participate in discussions, provide patches, documentation, suggestions and criticism. Fans have accounts in the Forgerock development tools; Confluence, Jira, Fisheye and Crucible. Fans are also known as contributors.


A Roadie is a Fan that has been given write access to the code repository trunk. They will be given a mail address. Not needing to depend on other people for the patches, they are actually making short-term decisions for the project. The Band can (even tacitly) agree and approve it into permanency, or they can reject it. Remember that the Band make the decisions, not the individual people. Roadies are also known as committers. Roadies are able to propose community members for more advanced membership.


A Rockstar is a Roadie that has been elected due to merit for the evolution of the project and demonstration of commitment. They have write access to the code repository, a mail address, the right to vote for the community-related decisions. Rockstars are part of the Band. The Band as a whole is the entity that controls the direction of the project, nobody else.

The Band

The Band is the group that controls and directs the project. The Band votes on election of members and commits to release branches.  The Band consists of all Rockstars.

How to Commit

In order to submit changes to the OpenAM source tree,  one has to be at least a Fan. This means that they have to have a login into

There are 3 different kinds of code submissions that we need to address:

  1. Simple patches to trunk
  2. Complex patches to trunk
  3. Extensions

Simple Patches to trunk

Simple patches to the main trunk, are patches that affect less than 100 lines of code, and affect less than 5 physical files.  This is expected to be the majority of fixes for issues raised in Jira.  Most fixes are going to be 3 or 4 lines. After review the patch is committed directly to the trunk.

Complex Patches to trunk

Complex patches to the main trunk, are patches that affect more than 100 lines of code,  affect more than 5 physical files or is being developed by more than one developer.  This kind of patch has to be developed in its own branch, allowing the developers to commit changes and test changes. Any contributor can request a branch for their development.  Branches are expected to be transient and to only be valid for the length of the development of that feature or fix.  Once the development work is completed,  it will be merged back into the trunk.


Extensions are meant for longer term projects, or sub-projects that are not supported by ForgeRock.  Any Contributor can request an extension, over which they have control. The Band will determine if this is a reasonable subproject and will not unreasonably withold approval.  The extension owner is able to determine who will have developer access and how they will handle commits.  At some point,  an extension might be mature enough to be brought into the supported software,  at which time,  it will become part of the main OpenAM project and subject to the normal submission process.

Submitting code changes

You can submit changes following a "review then commit" flow.

Review then Commit

The development process for a simple patch is:

  1. Check out the latest version of the trunk to a local workspace.
  2. Edit your local files making the changes you deem necessary.
  3. Build and verify your changes.
  4. If there has been a significant time since you checked out the source,  you might want to sync up, and verify your fix still works
  5. Generate a diff using svndiff.
  6. In Crucible; create a review request and paste your diff.
  7. Once your patch has been reviewed a Roadie or Rockstar will commit the patch to the trunk.

The development process for a complex patch is:

  1. A branch will be created for your fixes.  You will have full commit access to the branch
  2. Check out the latest version of the branch to a local workspace.
  3. Edit your local files making the changes you deem necessary.
  4. Build and verify your changes.
  5. Commit your changes into your branch.
  6. If there has been a significant time since the branch was created,  you might want to sync up with the trunk, and verify your fix still works
  7. In Crucible; create a review request, based on your branch and the trunk.
  8. Once your patch has been reviewed a Roadie or Rockstar will merge and commit the branch into the trunk.

How do I become a RockStar?

Participation in the project starts with becoming a fan.  This involves signing the CPA, which basically states that you have the legal right to anything you contribute to the project.  At this point,  you are free to add documentation,  create wiki content, download and build the project and submit patches as diffs, into crucible.

Once a fan has shown a commitment to the project and has submitted patches that the Band deems reasonable quality, they can be nominated to be come a roadie.  Any roadie or rockstar can nominate anyone and the band then votes.

A Roadie is intended to be a fairly major contributor to the project and has write access to the trunk,  Roadies are able to submit simple patches directly to the trunk.

Once a roadie has shown a strong commitment to the project,  generally by becoming a module owner, or responsible for a significant section of the project, they can be nominated to become a rockstar.  The Band then votes on the nomination.

Once accepted as a rockstar,  they become part of the architecture committee,  (the Band) and are an integral part of the project.

Anyone can move along this chain, simply by showing a commitment to the code and the project.

How are releases managed?

ForgeRock releases are releases that are supported by Forgerock.  These will be managed as a separate branch in the tree,  and the band will be responsible for voting, and moving code from the trunk to the branch.  It is anticipated that all changes to the trunk,  will either move into the release branch,  or be reverted in the trunk.

It is the responsibility of the Band, (architecture council), to insure that changes committed to the trunk, are consistent with the roadmap.

  • No labels