You can find our GitHub page at github.com/atsid.
We encourage releasing as much of our code as possible as open source projects. For more detail on our open source strategy, have a look at this post.
What can be released?
Nearly anything! We encourage our team members to always be thinking about code that could be beneficial to release as open source software.
This makes it easier to reuse for other projects, and lets us give back to the community.
Guidelines for whether a project should be released include:
- Is there a wider use case or other potential interest for the project?
- Will releasing the code represent ATS well?
- Have you confirmed that the codebase itself does not represent proprietary capabilities or IP1?
If you aren’t sure whether a project is a good candidate for open sourcing, feel free to ask for a review by other technical staff or ATS management.
Open source standards
Our open source code should reflect our values as a development team, and should therefore be of high quality.
Some specific guidelines to consider for any open source codebase that we maintain or would like to release:
- Does the README.md state the purpose and goals of the project?
- Is the README.md file clear and comprehensive for new developers to get started working?
- Have you put relevant and useful badges in the README.md file to indicate status and quality2?
- Have you included a LICENSE file? (We default to Apache 2.0, feel free to copy it from one of our many open source repos)
- Where appropriate, is the
package.jsoncontent complete and up-to-date?
- Have you confirmed that there is no sensitive information in the codebase (customer or corporate proprietary information, passwords/tokens, etc.)?
1We try not to depend on proprietary IP, but it’s worth double-checking. Especially if we’re including customer-provided components or business logic.
2ATS has built and maintains a badging dashboard tool that can help you check this.