Blog

At the 2022 Global Summit, the Open Compute Project Foundation (OCP), introduced the next evolution of the contribution process for hardware specifications. 

The existing contribution workflow and hardware specification templates were set up many years ago when the OCP was focused on one type of specification document, always leading to a product. This mode of operation, while still relevant in some cases, does not reflect the OCP of today.

Notably, the current contribution process has the following limitations:

• Did not require HW specs to be useful to the community.

  • Encourages monolithic contributions which are not easily reused - may be too specific with compliance.

  • Does not encourage the community to provide feedback and participate.

• Contribution license best practices are not clearly defined or understood. 

• Process not formally defined or documented - leads to repetitive training and oversights.

• New versions require equal amounts of labor by contributors as the initial contribution.

• Does not encourage multiple parties to come together at different times.

• HW Specs are IP-heavy from the start - potential barrier to participation.

• Not extensible for the diversified needs of products and de-facto standards.

• No clear errata/revision process.

With these limitations in mind, OCP staff worked closely with members of the OCP Incubation Committee to determine the best way to introduce a formal contribution process that includes:

• A revised specification architecture with standardized specification templates, enabling different types of specifications and facilitates multi-company contributions, with multiple parties coming together at different times

• IP licensing guidance and templates to guide "useful" contributions. 

The revised process and specification architecture is intended to encourage tighter collaboration, early communication, and to reduce inefficient habits.

To encourage multi-party collaboration, which will render more robust and useful contributions, OCP plans to implement a streamlined process framework to produce three types of Specifications: Base Specifications, Design Specifications, and Product Specifications. This will help yield a modular approach enabling derivative specifications, faster innovation, and more diverse products.

• The Base Specification is an architectural framework for coarse alignment— a requirements description for flexible hardware and software modules to interoperate. Market requirements drive Base Specifications. Without going into much details of a specific design, the Base Specification may be light on IP content. We need companies (including potential competitors) to engage in this phase; therefore, the IP-content may be light.  For this, we will need a legal agreement such as a Contributor License Agreement (CLA) upfront (potentially without knowing the eventual scope of the base specification).  The Base Spec shall be generic enough to allow several Designs for each Module (with a generic name). To develop such generic modularity, we need a broad representation from different disciplines - often from competing companies with differing viewpoints.  But since the discussions are broad, the IP content is light with no secret sauces!  By separating the Base Spec into its own section, this allows more representation and collaboration in the development of the Base Spec.

• The Design Specification captures customer requirements for finer alignment by building on the Base Spec.  One or more companies will join to develop detailed design specs. Compared to the Base Specification, this effort typically contains significantly more detail such as future roadmaps and IP-related information. This group may have a multi-party NDA on their own (outside OCP umbrella) for the normal practice of developing products.  The resulting Design Spec would be contributed to OCP (via a Final Specification Agreement: FSA). At the Design Phase, it is likely that a few companies will engage as a team with limited access list to develop a specific Design optimized around solutions from a few companies who don’t compete.  In this case, IP content may be rich, and some discussions may happen under NDA (outside OCP).  As the Design Specification completes, it gets contributed to the OCP with a Final Spec Agreement (FSA). 

  • Key point -  Design Specifications can be reused! I.e., if one contributor uses an indoor design specification, another team could reuse and make an outdoor specification. This flexibility should allow for an increased number of and easier processes for contributions to the OCP Community. Having the same Base Specification for several Design Specifications will help increase the commonality of physical and logical interfaces to meet a set of common infrastructure hw/sw/fw requirements while allowing gen-to-gen variations or product differentiation.

• The Product Specification captures manufacturing requirements, building on the Design Specification. Typically even fewer companies will engage to create a single product specification, but the goal is to increase the total number of products that meet a Design Specification (derived from a Base Specification). The resulting Product Spec shall be contributed to OCP (via a Final Specification Agreement: FSA). A product typically goes through much effort for qualification and mass-production readiness beyond what specified in a typical design spec. At Product(ization) Phase, even fewer companies may be involved to develop a specific final product for contribution to OCP. A Product may be submitted to OCP for “OCP Accepted™” or “OCP Inspired™” designation (with different levels of collateral such as a Design Package).

Examples of the Base, Design and Product specifications and their role in the new process.

• Key Points

  • This new approach still allows for monolithic contribution - one contributor can follow the process all the way through.

  • By reducing the initial barrier to entry, this approach should encourage more collaboration within project groups. More participating contributors should lead to even more innovation.

  • Not all adopters can write a product spec, but they can participate in creating a base specification

  • Splitting contributions into three distinct sections in the new modular approach will help facilitate downstream collaboration and derivative work.

Have questions about this new process, or want to understand how your organization can get involved? Reach out to Bijan Nowroozi (OCP CTO), or Michael Schill (OCP Community Director)