Currently, the open source projects under the TARS Foundation include TARS, TarsGateway, TarsBenmarck, TarsJMeter and K8STARS, and more than 20 projects are also in the incubation stage.

The TARS Foundation hopes to accommodate a variety of bottom-up content to build a better microservice ecosystem. It will include infrastructure, storage, development framework, service governance, DevOps, and applications based on any programming languages.

In 2020, the Foundation has created a new project governance model and it uses 7 criteria that are related to Code, Licenses and Copyright, Releases, Quality, Community, Consensus Building, and Independence, to measure an open source project. If you are interested in learning about these criteria, please read more here.

Why you should donate a project to an open source foundation?

Donating a project to a non-profit open source software foundation can increase users’ confidence in the project, thus attracting a greater user base. On the other hand, if developers are using a project under a commercial company, they may have concerns about copyright or other reasons when using the project.

If a project is donated to the TARS foundation, it is able to take advantage of the many resources and expertise of the TARS Foundation and the Linux Foundation in the areas of open source project development and community building.

How to donate a project?

• Submit a project proposal through a form.
• TOC (Technical Oversight Committee) reviews the proposal during a regular meeting and schedules a time for presentation in the next meeting.
• The PMC (Project Management Committee) or important committer(s) of the proposed project is/are invited to attend and present the proposal to the TOC members.
• The TOC members may engage with the project to ask further questions along with the PMC or important committer(s).
• TOC will vote to pass the submitted project proposal into incubation with a simple majority rule.

How to become a graduated project?

When the incubating project meets all the requirements, it can apply to be a graduated project. It needs to demonstrate whether the project realizes all the criteria and the degree of realization in a file named “Assessment” on the project page. The TOC will review and vote to decide if the project reaches graduation.

Meanwhile, the TARS Foundation has connections with leading IT enterprises, which can pave the way for the donated projects to become enterprise-level applications and provide project contributors with opportunities to communicate with more global companies.

Appendix: TARS Foundation Open Source Project Governance Model

Code

• The project produces Open Source software, for distribution to the public at no charge.
• The project's code is easily discoverable and publicly accessible.
• The code can be built in a reproducible way using widely available standard tools.
• The full history of the project's code is available via a source code control system, in a way that allows any released version to be recreated.
• The provenance of each line of code is established via the source code control system, in a reliable way based on strong authentication of the committer. When third-party contributions are committed, commit messages provide reliable information about the code provenance.

Licenses and Copyright

• All new inbound code contributions to the Project must be made using an OSI-approved open source license specified for the Project within the “LICENSE” file within the Project’s code repository (the “Project License”).
• All the Project dependencies mentioned above cannot exceed the license used by the Project.
• The Project dependencies must be available as Open Source
• Contributors of Project must sign individual CLA (Contributor License Agreement)
• All copyrights created by the Project belong to the TARS Foundation

Releases

• Releases consist of source code and are distributed using standard and open archive formats that are expected to stay readable in the long term.
• Releases are approved by the Project's PMC (Project Management Committee), in order to make them an act of the Foundation.
• Releases are signed and/or distributed along with digests that can be reliably used to validate the downloaded archives.
• The release process is documented and repeatable to the extent that someone new to the project is able to independently generate the complete set of artifacts required for a release.

Quality

• The project is open and honest about the quality of its code. Various quality and maturity levels for different modules are natural and acceptable as long as they are clearly communicated.
• The project puts a very high priority on producing secure software.
• The project provides a well-documented, secure and private channel to report security issues, along with a documented way of responding to them.
• The project puts a high priority on backwards compatibility and aims to document any incompatible changes and provide tools and documentation to help users transition to new features.
• The project strives to respond to documented security reports in a timely manner.

Community

• The community welcomes contributions from anyone who acts in good faith and in a respectful manner and adds value to the project. Contributions include source code and documentation, constructive bug reports, constructive discussions, marketing, and generally anything that adds value to the project.
• The way in which contributors can be granted more rights such as commit access or decision power is documented in public and archived places, and is the same for all contributors.
• The project strives to answer user questions in a timely manner.
• Contributors come from multiple organizations.
• The project has a well-known homepage that points to all the information required to operate according to this project governance plan.

Consensus Building

• The project maintains a public list of its contributors who have decision power -- the project's PMC (Project Management Committee) consists of those contributors.
• Decisions are made by consensus among PMC members and are documented on the project's main communications channel. Community opinions are taken into account but the PMC has the final word if needed.
• All "important" discussions happen asynchronously in written form on the project's main communications channel. Offline, face-to-face or private discussions that affect the project are also documented on that channel.

Independence

• The project is independent from any corporate or organizational influence.
• Contributors act as themselves as opposed to representatives of a corporation or organization.