If you've ever participated in an open source community like the Apache Software Foundation or Codehaus, you'll know that there are hundreds (sometimes thousands) of participants and interested parties for projects such as Maven, httpd, or Tomcat. Communities like these are only able to communicate because individuals can sign up for mailing lists, issues trackers, and other open source infrastructure without the manual intervention of an administrator. If you want to submit a bug to the Groovy project at Codehaus, you don't have to send an email to someone asking permission to participate, you simply sign up for an account on the Codehaus JIRA. It just would be as agile a community if you need to wait for an administrator's permission to participate.
It is this self-service sign-up capability that is a key feature of all scalable open-source infrastructure, and this is also one of the key features that was just released in Nexus Professional (which is also freely available for any interested open source project).
While this self-service sign-up is important for open source projects, it can also be something useful to the enterprise. Many large software development organizations have realized that the collaborative, open-source development model provides an example for internal development. If an organization can emulate the ad-hoc, merit-driven models of something like the Apache Software Foundation, they can start to gain some of the benefits of open source culture and open source community. I've spoken with many executives at large organizations who understand that they need to find a way to bring the "ethos" of open-source into the enterprise. One way to encourage this change is to start using the same infrastructure as open source projects: Nexus, JIRA, Subversion. Another way to bring open-source best practices into the enterprise is to allow for more ad-hoc, user-driven action. Give your developers something like Nexus, and don't put an administrator in the way. Let them sign up for accounts using the User Account Plugin.
In this post, I provide a brief overview of user-driven sign-up feature just released with Nexus Professional 1.4.0.
When you downloaded Nexus Professional, you also download a few optional plugins including the User Account plugin. This plugin is located in the ${NEXUS_HOME}/runtime/apps/nexus/optional-plugins directory under nexus-user-account-plugin-1.4.0. To install this plugin in Nexus:
To configure the User Account Plugin, click on Server under the Administration section of the Nexus menu, and scroll down to the section named "User Sign Up". The User Sign Up section is shown in the next figure.
To activate the User Sign Up feature, set the "User Sign Up" feature to "On". This will expose a "Sign Up" link next to the "Log In" link in the Nexus user interface. The Selected Roles in this configuration section are the default roles assigned to users who successfully signed up for an account.
Once User Sign Up has been activated via the Server settings as shown in the last section, users will see a Sign Up link next to the Log In link in the Nexus interface. This Sign Up link can be seen in the upper right-hand corner of the following figure.
Clicking on this Sign Up link will display the Nexus Sign Up dialog shown in the following figure. This form accepts a username, password, the full name of the new user, and an email account. It also asks the users to type in some text from a captcha form element. If a user cannot read the text in the captcha, they can click on the captcha to refresh it with new text.
Once the new user clicks on the Sign Up button, they will receive a confirmation dialog which instructs them to check for an activation email.
The user will then receive an email containing an activation link. When a user signs up for a Nexus account, the newly created account is disabled until they click on the activation link contained in this email. A sample of the activation email is shown in the next figure.
Once a user clicks on the link in the activation email, they will now have a Nexus account with a set of default permissions. On an open source project, this set of default permissions may only be enough to read and browse a set of repositories. If a user needed further access they would then need to go through a formal request process with the Nexus administrators. Often, this user-driven sign-up process is enough to satisfy the needs of 95% of the participants as the only people who need administrative access are those who are creating and managing repositories and repository groups.
To provide some sensible default permissions, click on the Server under the Administration section of the Nexus menu and scroll down to the User Sign Up section of the Server settings. Make sure that the selected default roles for new users contain some ability to browse, search, and view repositories.
This last figure shows a default User Sign Up role containing the Nexus Deployment Role. If your server were available to the public this wouldn't be a wise default role as it would allow anyone to sign up for an account, activate an account, and start publishing artifacts to hosted repositories with little or no oversight. Such a default role may only make sense if you are running an internal, corporate instance of Nexus Professional and you are comfortable granting any developer in the organization deployment permissions.