| title | description |
|---|---|
Minimum Open Source requirements for Services |
The minimum requirements for Open Source when working on services, which then allow further progression. |
Here we document the minimum requirements for use of Open Source in services. When a service meets this minimum requirements, it is then possible for contributors to further progress the service toward the complete Operate First methodology. This represents what we expect from any service claiming to be Open Source.
These requirements do not represent best practices, but are the bare minimum for Open Source development of services. Most Open Source models (beyond “throw it over the wall” behavior) are covered by these requirements in one way or another:
- All the service's code and assets necessary to operate the service are shared under an open source license, and publicly accessible.
- A public contributor can use the same workflow as a typical team member to make a change to the service.
For many projects the above seem obvious; this is how we generally work together on Open Source projects. Nevertheless such requirements are being explicitly specified, since services are a new area of work, and since the services and their sources are often not “distributed” for users to operate, and optionally modify, their own copy.
Due to the variety of services, projects, teams, and workflows there is a lot of flexibility in the requirements. Secondly, the requirements are a bare minimum, and best practices usually go beyond the requirements. Thus we must address common questions about the requirements:
A service is software operated for the user. Software the user is operating for themself is not considered a service. A service is defined by the context in which the software is operated and all of the assets required to operate the software for the user in that context.
A: Make all parts of the service open by default, except where law, security, privacy, or common sense says otherwise. A general rule of thumb is if you commit it to a repository, it should be open. Assets that should not be shared are ones where you don’t have redistribution rights (such as a RHEL VM image, or private information, and personal identifiable information), or things that are actually secret: Don’t share keys, passwords, or tokens.
If changing configuration is an activity that a typical team member does in order to change the service, then you should share that configuration publicly, in order to meet requirement #2.
It is not required that all tooling dependencies and service dependencies used during the building, testing, deployment and operating of the service are themselves Open Source.
It is recommended that you include sufficient configuration to operate the service, or some base default version of configuration. Putting secrets in your configuration is a bad practice that should be avoided, regardless of Open Source.
A: Tests that are used during operation the service (as per requirement #1), and tests that used when run when making a change to the service (as per requirement #2), must be shared publicly under an Open Source license.
It is recommended that tests which are independent of the service (eg: penetration tests or performance tests) are Open Source, but this is not required.
A: The requirement #2 above does not require that any public contributor can trigger the test suite, if that activity is limited to certain known contributors.
It is common for Open Source projects to limit which contributors can trigger CI or run test suites on their provided infrastructure. This is usually done to prevent abuse such as exfiltrating secrets or denial of service. It’s recommended that your project has a mechanism whereby a known contributor, or maintainer, can review a contribution from an arbitrary contributor and then allow the CI or test suite to run on it.
A: If such documentation is necessary for a typical team member to make a change to a service as described in requirement #2, then it is required that such documentation be made available to the public.
It is recommended that an Open Source project has a documented contribution workflow (eg: a simple CONTRIBUTING file, a wiki, or further documentation).
A: The minimal requirements above do not require that a service can be operated by anyone. The requirements serve to enable others to change the service code so that it can be operated by others, should that be desired. It is by these means that these requirements accommodate the forking of the project, with all the usual tradeoffs and costs.
However, if a typical team member operates their own instance of the service in order to make changes to it, then requirement #2 means that public contributors should also be able to do so as well.
It is a powerful, laudable goal for others to be able to operate an Open Source service, either by operating an instance on their own, or participating in operations of a common instance. Operate First is a project that enables this, and even provides infrastructure.
A: It is not required that all dependencies of a service are Open Source, or have Open Source alternatives. For example, a service may interact with a proprietary authentication system, or run on a proprietary platform.
The requirements together serve to enable others to change the service code so that its proprietary dependencies can be replaced with Open Source ones, should that be desired.
A: The minimal requirements above do not require that the Open Source service lead a community built around it.
If your project grows bigger, and has many participants, then forming a community with the typical components (communication venues, code of conduct, governance, etc.) is recommended, and brings significant further Open Source benefits.
Among other things, having a community means sharing your documentation, issues, and a roadmap. It also means conducting most planning conversations about the service in the open, and not limiting participation to your team. This is how you gain the advantages of the Open innovation process, where minds beyond your team can help work through problems and create solutions Without these things, your community interaction will be more painful as crossing the boundary between community and Red Hat private has a high context switching cost.