Why do salmon swim upstream? Scientists have deduced that if the riverbed was a good place for them to start, it will suffice for their offspring. Thus they spawn and their offspring return to the ocean to feed. But what if some of the fish, en route to the sea, took a tributary at a fork in the river? They might get lost, fail to reach the ocean and perhaps starve or exhaust themselves trying to find the original route. Developing software using open source principles follows a similar theory.
When software is developed using open source methods, an upstream repository of the code is accessible to all members of the project. Members contribute to the code, test it, write documentation and can create a solution from that code to use or distribute under license. If an organization follows the main stream or branch of the upstream code their solution will receive all the changes and updates created in the upstream repository. Those changes simply "flow down" to the member’s solution. However, if a member organization forks the code -- if they create a solution that strays from the main stream -- their solution no longer receives updates, fixes and changes from the upstream repository. This organization is now solely responsible for maintaining their solution without the benefit of the upstream community, much like the baby salmon that took a tributary and then have to fend for themselves rather than remain in the main stream and receive the benefit and guidance of the other salmon making their way to the ocean.
Network functions virtualization (NFV) is the revolution sweeping telcos as they modernize their infrastructure. After years of lock-in to proprietary vendors who were solely responsible for the solution, telcos seek to deploy open systems based on open source software. Telcos wish to derive the benefit of community-developed software. (By the way, here’s an article on telcos’ use of open source.) To avoid using a software solution that is only maintained by one vendor, it behooves telcos to select a solution from a vendor who does not fork upstream code.
Red Hat has an upstream first philosophy. Almost all the code in Red Hat software is contributed to the upstream project and by and large, Red Hat software is not forked from the upstream. Red Hat contributes and invests at high levels to the following NFV related projects:
Red Hat is the second largest contributor to the Linux kernel. This means Red Hat engineers and support staff are well versed and able to resolve customer issues involving the Linux kernel.
Contributions to OpenvSwitch
OpenvSwitch is popular open source software virtual switch hypervisor. Red Hat ranks among the top five contributors to the openvSwitch project, and thus, Red Hat engineers and support staff are well versed and able to resolve customer issues involving OpenvSwitch.
OpenStack upstream contributions
Red Hat continually ranks among the top contributors to OpenStack, a key open source cloud platform for NFV. Thus, Red Hat engineers and support staff are well versed and able to resolve customer issues involving OpenStack.
Open Platform for NFV (OPNFV) facilitates the development and evolution of NFV components across various open source ecosystems. Red Hat is a platinum member of OPNFV indicating Red Hat’s commitment and contribution to this project. Red Hat is among the top contributors to OPNFV.
Contributions as of Q4, 2016
The high level of contributions by Red Hat to core NFV projects demonstrates that Red Hat is:
- Committed to the projects;
- Investing time and money; and
- Engineering Red Hat solutions to be compatible with upstream.
Aside from NFV, Red Hat participates in multiple open source communities.
Unlike salmon that might take a fork in the river and jeopardize their journey to the ocean to feed and grow, Red Hat never forks upstream software. Thus users of Red Hat software can be confident that they will get software that has been debated and vetted in the public forum, letting it mature through a cycle long before it reaches their networks and data centers.