Google often gives its software away for free. It has long believed in open source software.
But last week, the company took this idea to the next level. It gave away all rights to Kubernetes, a cloud computing system originally designed by Google engineers, asking a non-profit to manage its development. It didn't just share some software code with the world. It agreed to let an independent party oversee the development of the code.
Dubbed the Cloud Native Computing Foundation, the organization is just the latest in a series of high profile new foundations now stewarding opens source projects created by large tech companies. In the past year, we've also seen the launch of the Cloud Foundry Foundation to govern a project originally released by VMware, the establishment of the Node.js Foundation, thanks cloud services company Joyent, and the founding of the Open Container Initiative, thanks to several different companies, most notably Docker and CoreOS. All four of these new organizations are under the umbrella of the Linux Foundation, the organization originally founded to manage the Linux Kernel, the core of all Linux operating systems.
Thanks to these foundations, competing companies—and independent developers—can come together to work on projects that benefit all of them without any one company owning the final product. That makes open source even more open. It makes it easier for the world to collaborate on new software.
Open source foundations are nothing new. Linux Foundation has been around since 2007, and other major projects like the Eclipse code editing tool and the Apache web server have been governed this way for even longer. Many of the most important open source projects in recent years, such as the Hadoop big data crunching platform and the database system Cassandra, are managed by the Apache Foundation. But it's unusual to see so many new foundations created so quickly.
While the Linux kernel, Apache server, and Hadoop platform were all started initially as non-commercial projects, some of these new projects, like Cloud Foundry, have always been corporate products. And though some major open source projects remain corporate property, such as the MongoDB database, it's becoming harder and harder to name significant projects that aren't now part of a foundation. That's a good thing.
Why are so many companies giving away their intellectual property? It's not happening for altruistic reasons. In his keynote at the O'Reilly Open Source Conference in Portland, Oregon last week, Cloud Foundry Foundation CEO Sam Ramji argued that the shift is being driven by economics.
Companies like Google want others to use their open source software since it can help drive the use of online services, like Google's cloud computing tools. They want others to contribute code to this software too. But increasingly, others don't want to use or contribute to projects unless they're independently managed.
Venture capitalists have been pouring money into companies dedicated to commercializing open source projects, whether that's by providing support and services for open source projects or by building proprietary products atop open source code. Docker, for example, has raised $162 million million according to Crunchbase. But new business models for open source create new challenges for the companies that maintain them.
"Turns out with all of that money, you start to generate distrust," Ramji said. "So some of the old nature of the open source model is starting to break down as these projects become bigger and more valuable, I think that's where foundations come in."
For example, IBM and HP offer cloud services based on Cloud Foundry. It would be in their best interests to contribute back to the main Cloud Foundry project, but they might be disinclined to do so by the fact that they compete directly with Pivotal, a company spun out of VMware and EMC in part to commercialize Cloud Foundry.
When Pivotal owned all of the work that HP and IBM developers were putting into Cloud Foundry, there was always the possibility that the company could change the open source licensing, reject a competitor's contributions, or make changes to the project that didn't fit with the plans of outside contributors. One company was calling the shots, and it had to put its own interests first. So by putting its code into a neutral, independent organization, competitors can make mutually beneficial decisions without having to worry that all of their efforts will disappear overnight.
But there are downsides to the foundation model, argues Derek Collison, one of the original creators of Cloud Foundry and the founder of Apcera, a startup that makes tools for managing cloud infrastructures. Foundations move slower than projects governed by a small team with clear goals, and innovation can be hampered by infighting, he says, echoing the reasons many open source project leaders have given for not placing their projects into foundations over the years.
"Design by consensus has never worked," he says. "And it never will unless you have someone who says 'I know the pain points, I know how to drive it forward.'"
But Collison isn't totally against the idea of foundations. In fact, Apcera is part of the Open Container Initiative that is helping standardize an increasingly popular technology called containers. He argues that relatively little design or innovation has to happen within the foundation. With the standard established, the member companies are free to innovate as they see fit, adding their own unique features atop the standard.
Standardization is a major driving force many of these new projects, Linux Foundation director Jim Zemlin told us last year. "Providing a huge standards document to a light bulb manufacturer won’t help it make better, cheaper bulbs," Zemlin told us. "But if you hand them the open source code, then they can just start doing it."
And even if foundations move more slowly than companies, they might still win out in the end. Ramji cited a study conducted by Henrik Ingo in 2010 to compare governance models of open source projects. Ingo's conclusion: There appears to be a "glass ceiling" limiting the growth of of single vendor projects. In other words, if you want your project to grow, giving away the code to an independent organization is the best way to do that.
