6
The Status of Open Source for 5G
2.2 GOVERNANCE MODELS MAKE A DIFFERENCE
The governance model in open source is one factor to be considered for new projects. The choice
implications can be profound with regards to the adoption and continued need for contributions. While the
licensing model for open source provides a legal framework, the governance model provides a social
framework for collaboration. A good governance model must be well-defined and include documented rules
for engagement, which is how decisions are made in order to nurture a healthy, long-term community.
Transparency is also extremely important as it helps the community understand how decisions are made
and by whom. The leadership teams’ constituency and its structure must be diverse to appeal to a broad
group of stakeholders while avoiding tilting the balance toward specific business interests.
Depending on the projects’ original intent, the seeding contributors and their strategic objectives, decisions
can be made by appointed leads from specific organizations, elected ones on a merit-based criterion or a
combination. A meritocracy-based governance is perceived as being more open and can encourage more
participation, which in return will result in more opinions and potentially some overlapping code contributions
that require consolidation/harmonization. This can translate into faster cycles, but it can also result in major
architectural changes from the original seeding project. Some open source communities put the control in
the hands of a commercial entity, while others are established around non-profit organizations that are
vendor neutral.
There is no good or bad governance model for a specific project. The decision to choose one over the other
has to do with finding the best tradeoff between control, process, agility and quality.
2.3 STANDARDS-BASED OPEN SOURCE VS. OPEN SOURCE IMPLEMENTATIONS
With the rise in popularity for open source projects, a common question regards the value of standards.
Many people perceive open source as a competing force in the establishment of “de-facto” standards for
various industries.
There are quite a few similarities between the standards and open source paradigms. Both have the
objectives of increasing interoperability, reducing costs and facilitating the establishment of a healthy
business ecosystem. The difference has to do with the method to achieve those goals.
Historically, standards have been developed using consensus-based collaboration in a process that
required written documentation of the specific standard (for example, a specification, protocol, an
Application Protocol Interface (API)). This is no different than open source projects, with the exception that
for open source, contributions are in a form of running code.
Usually the collaboration process in standards is a very transparent one based on less transparent or even
proprietary implementations. Open source projects can bring implementation transparency during the
harmonization/standardization process, as well as after the finalization of a standard as a way to establish
reference implementations.
Therefore, open source projects should be considered complementary to standards development, as a way
to accelerate and improve the process of creating interoperable solutions. Figure 2.1 shows where
standards and open source initiatives work together to benefit vendors, service providers and end users.
Combined with automation tools, continuous testing and integration, as well as broad adoption of DevOps