Operating System Partner Tenets

Scale through upstream

When adding product support for our contractual partners, it is important to focus efforts on publishing the work in ways that can be adopted without special exception.

Open Source operating system distributions require that contributions be available in an upstream project, with an owner and a method for open communication. In free and open source projects, the upstream of a program or set of programs is the project that develops those programs. The OS partners are downstream of those projects. This term comes from the idea that water and the goods it carries float downstream and benefit those who are there to receive it. If a project requires specific modifications, it creates a burden on the distribution maintainers. There are  distributions from easily backporting all bug fixes, security fixes and new hardware enablement needed to maintain all supported environments. Manpower of the OS Partner teams is limited and have other requirements for extending the GTM strategies and ensuring that all teams have an opportunity to coordinate with OS Partners on what is currently supported and what is new. Conserve their energies for critical projects.

Use open source standards

Any team submitting modifications should be sensitive to the extensive testing required before a new version of any operating system is released to ensure it is stable enough for customer success.

There are hundreds of packages which make up the Operating System. Making sure that they all work together as a whole is not an easy task. This becomes even harder as the number of packages and their inter-dependencies grows. There are customers that will not accept packages external to the distributions. Our operating system partners need to be able to package and digitally sign that software to satisfy these enterprise customers.

  • Avoid major version updates, ABI breakage or API changes if at all possible.
  • Avoid changing the user experience if at all possible.
  • Avoid updates that are trivial or don't affect users.
  • Push major bug fixes and security fixes to the previous stable releases for long term support.
  • Use semantic versioning for all changes.

Be flexible and inclusive

The commitment to introduce support into any distribution is an implicit acceptance of the requirement to be flexible and resilient. Help OS distribution partners participate in the feedback and understand the context for changes.

Policies and technical apparatuses ensure that both positive and negative feedback loops have a genuine and material effect on project operations. Both the product team and external project participants should be able to alter the project conditions. Project teams should report thoroughly on the expectations of their endeavors and all participants should equally feel that they can suggest adjustments to projects based on assessments of these outcomes. The project teams should be fundamentally oriented toward continuous engagement with the OS partners and learning. Every project should have a defined contribution policy so there is no ambiguity.