Launching an Open Source Project

The following steps outline the process for creating and releasing an open-source project. Please note that this process is not finalized, yet.

1. Get approval.

   • Seek approval from the relevant business line and forward the approval via email to [email protected].

2. Register your release.

   • Fill out the registration form (internal) to express your intention to release non-product code (such as utility libraries, tools, and sample code).

3. Name your project.

   • Check that it does not conflict with an existing project or infringe on any trademarks.
   • Don’t use a Allianz brand name.
   • Avoid using a third-party brand name. In certain cases you can use them as descriptors. For example, you can use “Test Libraries for Java” but don’t call something “Java Test Libraries.”
   • Don’t use unclear names. e.g. “Foundation Server”

4. Remove sensitive assets.

   • Remove any trademarks or product icons.
   • Remove all internal dependencies or references in your code and documentation. This includes any references to server names, binaries, databases, or email addresses.
   • Remove comments or documentation references to JIRA links, internal code names, and anything else that wouldn’t make sense to external developers.
   • Remove embarrassing content (curse words, etc).
   • Remove all embedded credentials, passwords, or other secrets that may be mistakenly added to the code or a configuration file. (Note: we expect secrets to be managed outside of source code, but we ask you to check nonetheless.)
   • Conduct a static code analysis for vulnerabilities.

5. Prepare code for release.

   • Use consistent code conventions, clear function/method/variable names, and a sensible public API.
   • Keep clear comments, document intentions and edge cases.
   • Ensure the distribution mechanism is as convenient, standard, and low-overhead as possible (RubyGems, Homebrew, Bower, Maven, NuGet, etc.)
   • Enable GitHub Actions for continuous integration.
   • Use inclusive language.

6. Code license.

   • Pick on of the prefered licenses - other licenses must be cleared with legal.
   • Review all license dependencies for compatibility with the chosen license.
   • If your repository vendors third-party OSS which is not managed/vendored by a dependency manager (e.g. RubyGems), describe its use and its license in a NOTICE file.
   • Add copyright and license headers at the top of each file (optional):

   // SPDX-FileCopyrightText: Allianz and others
   // SPDX-License-Identifier: MIT

7. Final review:

   • Once all activities have been completed, a final review will be conducted. If no issues are found, you can proceed with creating the repository.

8. Create GitHub repository

   • Create a GIAM group to manage access to the repository. Details can be found here.
   • Update the repos.yaml configuration file to include the new project and submit a pull request for review
   • After the pull request is merged, the repository will be provisioned automatically.

9. Publish the code.

   • After the repository has been provisioned, copy the code into the new repository. Do NOT include the git revision history!
   • Apply Allianz standard settings and include required files in the GitHub repository, as outlined here.
   • Verify that Dependabot and GitHub Code Scanner are functioning properly.

10. Going forward.

    • Ensure at least one team member is committed to managing community interactions merging pull requests, giving feedback, releasing new versions.
    • Regularly monitor and update your project to maintain its overall health; otherwise, it will be automatically archived due to inactivity.
    • Make your life easier as an open source maintainer, from documenting processes to leveraging your community.
    • Build a community that encourages people to use, contribute to, and share your project.

---

This release process is based on the GitHub release process template with some adoptions from the Yahoo release process. The original text is licensed under CC-BY.