Understand the Requirements for Joining the Program

Project Team Requirements

Review the requirements to build an Open Source Commons project team.

Project Teams must:

• Have at least three members, each from a different organization.This shows that your team is committed to developing a quality open source solution and supports collaboration—and it's a vital element in reducing the risk of your solution being abandoned.

• Communicate regularly, and consistently develop and maintain the project. Hosting regular calls with your team, for example, shows commitment to your project. Additionally, a member of the Open Source Community Team will join these calls when you apply to the program.

• Assign team members specific roles. These roles might include Product/Project Manager, Developer/Engineer, Quality Assurance Tester, Technical Writer, Support/Training, and Marketing.

Note One team member may want to take on more than one role at a time. That's perfectly fine, but in our experience no one person should take on too many roles at once.

Project Application General Requirements

Review the general requirements for submitting an Open Source Commons project.

If your project includes a package users will install, it must:

• Provide added value within a Salesforce customer's production org. Solutions should improve some aspect of the organization's day to day operations and work with their production data.

• Not have a dependency on any third-party solutions that aren't free and open source, and/or an existing Salesforce Product. This requirement maintains our all important values of trust and sustainability.

Project Application Technical Requirements

Review the general requirements for submitting an Open Source Commons project.

To ensure security and technical capability, projects must:

• Use CumulusCI for continuous integration and deployment. For community projects to gain the most advantage from our tooling and to ensure consistency across community projects, all SFDO-Community repositories must be configured for CumulusCI and use the CumulusCI Flow process for managing the project.

• Be accessible via a public GitHub repository. Upon acceptance into the program, you'll move your project into the SFDO-Community repo.

• Have two-factor authentication enabled on GitHub.

• Provide access to GitHub through the project team.

• Enable protected branches on the project's master branch. Protected Branches in GitHub allow controls to be placed on any changes to a particular branch in the repository (typically master). This prevents anyone from directly committing to master and forces a feature branch to PR workflow for all changes. All SFDO-Community projects should have protected branches enabled with these minimum required checks:

  • Code review by one or more project maintainers

  • A passing Feature Test build

• Grant the Open Source Community Team access to your SFDO-Community GitHub Repo and Packaging org. These credentials may be used by the Community Team to transfer ownership of the packaging org to a new maintainer in case of project abandonment.

• Your package must be Managed rather than Unmanaged. Commit to releasing as a Managed package with a packaging org reserving the project's namespace.

• Your Managed Package must be submitted for, and ultimately pass, Salesforce Security Review via Salesforce.org maintained publisher account. Passing Security Review is a trusted stamp of approval, and provides benefits to customers who implement these apps. Your team will be solely responsible to implement changes to ensure compliance with the Security Review process.

• Alert subscribers when a new version of the product package is ready. Requiring manual upgrading rather than “pushing” of new packages ensures that subscribers understand what they're installing and have opportunity for complete review before implementing.

Project and Team Legal Requirements

Review the legal requirements for submitting an Open Source Commons project.

To ensure your application and team are committed to the values of open source, and to promote transparency:

• Include a BSD 3-clause license in all repositories.

• Sign a Contributor license Agreement (CLA), which will be provided to you by your Open Source Community Team member.

• Review the Open Source Commons Terms of Participation.

• Each Project Team Member must maintain an active profile on the Trailblazer Community to participate in the OSC program and the community, therefore agreeing to the Terms of Service and Community Guidelines.

Next Steps

Once your project team meets the above requirements, reach out to us via email at sfdo-opensource@salesforce.com.

Include this information:

• The intention of your project and what you're solving.

• The members of your team, including role assignments, and links to their Trailblazer Community profiles.

• If you have a technical solution, such as an app, provide links to your GitHub repository. Also include a list of Project Team members to set up as Contributors to the project on GitHub.

• Any further supporting material to indicate your team's activities such as prior meeting notes, documentation, Community Sprint Project documentation, etc.

Once we've received this information, we'll get back to you to schedule a project review meeting.

The next related knowledge article, Salesforce.org Open Source Commons Terms of Participation, can be found here.