| title | description |
|---|---|
Open-sourcing a project |
How to take a private repo and make it open-source |
While we strive for Open Source by Default, sometimes apps start as private repos and only get open-sourced later. This can happen based on our guidelines for public vs. private content, or even a nudge from Peril.
Here is a list of things to consider in this situation.
Typically our apps conform to the twelve-factor philosophy of keeping secrets and other configuration options out of the codebase and storing them in the runtime environment instead.
But it is still worth auditing the repo to ensure no secrets have been checked in.
- Use Github to search for telltale strings such as
key,token,secret,password,credential - On the results page, check both:
- the Code tab, to view results from the current state of the repo
- the Commits tab, to view historical commits that might contain secrets that would become newly visible to the public
As an extra precaution, scan the repo for secrets using the following tools:
-
detect-secrets. It scans a codebase for known secret patterns such as AWS keys, as well as "high entropy strings" that are typical of keys and tokens in general. Please note that it does NOT scan commit history.
- Perform an initial scan and audit any found secrets
- Consider adding a git hook to prevent committing secrets in the future
-
trufflehog. Similar to
detect-secrets, but it scans both code and commit history.
It is possible that the repo's issue backlog, or wiki, or "projects" (the kanban style boards that GH repos can contain) might contain discussion of sensitive matters, so it is a good idea to review all of these as well.
- Review open and closed issues
- Review "projects"
- Review wiki content
For some older/larger projects, this may be an unduly onerous chore, so we do have the option of a fresh start as well.
We have two ways of accepting contributions on our projects:
- PRs are contributed via branches on the main Artsy repo, versus…
- PRs are contributed via branches on forked repos
For apps that need to have secrets at build time (such as deploy keys, or GitHub tokens for private Ruby gems, etc), option #2 represents a security risk, as any user can submit a pull request and potentially have your project's secrets injected into their modified version of your app.
To ensure safety on CI you should review the following settings under Project Settings > Build Settings > Advanced Settings:
- Pass secrets to builds from forked pull requests should definitely be set to Off
- Build forked pull requests should be probably set to Off (if it is not possible to build a project at all without the injected secrets)
If both of these are set to off, that implies that new contributions will have to come from branches on the main Artsy repo, so you might also need to
- Update the project's README to describe the new required contribution style
- Add the project to the list of repos for which Peril will enforce this check
Now that the project is open, it's a good idea to have an appropriate license in the repo as well. We typically use the MIT license, which strikes a balance between permissiveness and commercialization.
- Add an MIT license to the project
- Consider adding a post to https://github.com/artsy/artsy.github.io
Now that your project is public, you might want to write a blog post to document it, for the community as well as for future Artsy developers.
Some previous examples:
- How we Open Source'd Eigen — Eigen
- Open Sourcing Energy - Energy
- On our implementation of React Native — Emission
- Modernizing Force — Stitch / express-reloadable
- Rosalind and The Art Genome Project — Rosalind
If it cannot be determined with confidence that a repo passes all of the above checks, and if it is still deemed necessary to open the project, it is not unreasonable to start a new repository with a new history.
This is what happened with Force in 2016, and the process is described on the blog.