Linux and open source have changed the computer industry (among many others) forever. Today, there are tens of millions of open source projects. A valid question is “Why?” How can it possibly make sense to hire developers that work on code that is given away for free to anyone who cares to take it? I know of many answers to this question, but for the communities that I work in, I’ve come to recognize the following as the common thread.
An Industry Pivot
Software has become the most important component in many industries, and it is needed in very large quantities. When an entire industry needs to make a technology “pivot,” they often do as much of that as possible in software. For example, the telecommunications industry must make such a pivot in order to support 5G, the next generation of mobile phone network. Not only will the bandwidth and throughput be increased with 5G, but an entirely new set of services will be enabled, including autonomous cars, billions of Internet-connected sensors and other devices (aka IoT), etc. To do that, telecom operators need to entirely redo their networks distributing millions of compute and storage instances very, very close to those devices/users.
Given the drastic changing usage of the network, operators need to be able to deploy, move and/or tear-down services near instantaneously running them on those far-flung compute resources and route the network traffic to and through those service applications in a fully automated fashion. That’s a tremendous amount of software. In the “old” model of complete competition, each vendor would build their solution to this customer need from the ground up and sell it to their telecom operator customers. It would take forever, cost a huge amount of money, and the customers would be nearly assured that one vendor’s system wouldn’t interoperate with another vendor’s solution. The market demands solutions that don’t take that long or cost that much and, if they don’t work together, their value is much less for the customer.
So, instead, all the members of the telecom industry, both vendors and customers are collaborating to build a large portion of the foundational platform software together, just once. Then, each vendor and operator will take that foundation of code and add whatever functionality they feel is differentiating for their customers, test it, harden it, and turn it into a full solution. This way, everyone gets to a solution much more quickly and with much less expense than would otherwise be possible. The mutual benefit of this is obvious. But how can they work together? How can they ensure that each participant in this community can get out of it what they need to be successful? These companies have never worked together before. Worse yet, they are fierce lifelong competitors with the only prior goal of putting the other out of business.
A Level Playing Field
This is what my team does at The Linux Foundation. We create and maintain that level playing field. We are both referee and janitor. We teach what we have learned from the long-term success of the Linux project, among others. Stay tuned for more blog posts detailing those principles and my experiences living those principles both as a participant in open source projects and as the referee.
So, bringing dozens of very large, fierce competitors, both vendors and customers, together and seeding the development effort with several million lines of code that usually only come from one or two companies is the task at hand. That’s never been done before by anyone. The set of projects under the Linux Foundation Networking umbrella is one large experiment in corporate collaborative development. Take ONAP as an example; its successful outcome is not assured in any way. Don’t get me wrong. The project has had an excellent start with three releases under its belt, and in general, things are going very well. However, there is much work to do and many ways for this community, and the organizations behind it, to become more efficient, and get to our end goal faster. Again, such a huge industry pivot has not been done as an open source collaboration before. To get there, we are applying the principles of fairness, technical excellence, and transparency that are the cornerstone of truly collaborative open source development ecosystems. As such, I am optimistic that we will succeed.
This industry-wide technology pivot is not isolated to the telecom sector. We are seeing it in many others. My goal in writing these articles on open source collaborative development principals, best practices, and experiences is to better explain to those new to this model, how it works, why these principals are in place and what to expect when things are working well, and when they are not. There are a variety of non-obvious behaviors that organizational leaders need to adopt and instill in their workforce to be successful in one of these open source efforts. I hope these articles will give you the tools and insight to help you facilitate this culture shift within your organization.
Latest posts by Phil Robb (see all)
- What I learned at the ONAP & OPNFV Event in Paris-Saclay - March 8, 2019
- Industry-Scale Collaboration at The Linux Foundation - January 9, 2019
- Three Steps to Gaining Influence in an Open Source Project as a New Enterprise Contributor - October 9, 2017