A guide for Contently developers on how to approach open-sourcing internal projects.
- Daisydiff (deprecated in favor of HTML diff service)
Open-source is encouraged whenever possible, but it is not the default policy, nor mandatory for any project. It is required that you get approval from a Director of Engineering before publishing your project.
All projects need to be reviewed with a manager to determine open-source eligibility. The following statements must be true.
- The project does not contain technology that significantly differentiates the Contently product from competition.
- The code repository is free of any private information including personal data and private keys. (Use these methods to remove private information from git history.)
- You are willing and have the time to perform the extra work required to create and maintain an open-source project, as outlined in project quality.
One of the reasons that we are not open-source by default is this process requires extra responsibilities to be taken up by our developers. You are encouraged to work through the requirements listed below before publishing and to be responsive in replying to issues and pull requests on your project after publishing.
If any of these requirements cannot be met at the time of publishing, you can create Github issues for them, which can be taken up by you or other developers.
- Thoroughly document how to interact with all APIs
- Docs should go in depth with usage examples. A /docs directory can contain information beyond the README if necessary.
- Use inline documentation to explain key areas of the code.
- Use semantic versioning
- Include the following files, which can be templated from this repo:
You can encourage your teammates to help with your open-source project. It can be great to have help getting a code base ready for publishing by adding documentation, tests, or polishing APIs. You could also hand off writing blog posts about your project to a coworker who is interested.
By default, use the MIT license, which is included in this repo. Discuss with a Director of Engineering if you think a different license would be a better fit. For example, your project may be an extension of an existing open-source project which is under a different license.
- Open a PR in this repo and use it to work through the following steps.
- Review your repo with a Director of Engineering to get approval, based on getting approval.
- Update your Github repo to be public, or create a new Github public repo.
- Publish to any package managers, such as rubygems or npm, if necessary.
- Merge your PR into contently/open-source.
Please read CONTRIBUTING.md for details on our code of conduct, and the process for submitting pull requests to us.
- Jack Pope - Initial work - @jackpope
See also the list of contributors who participated in this project.
This project is licensed under the MIT License - see the LICENSE file for details
- @PurpleBooth for the excellent README and CONTRIBUTING templates
- Keep a Changelog for the excellent CHANGELOG template