Cloud computing relies heavily on open source code; open source has won out over commercial code for next-generation applications, even inside the enterprise. Promising open source projects attract venture capital which encourages a project to form a company that wraps itself around the code and starts to monetize it. "We used to share code, improve it, and build it for reputation's sake," Ramji said in his OSCON keynote. Now an open source project can be an element of competition between startup companies and contributing companies who want to be able to adopt it for their own advantage. Foundations are formed when a project becomes so important that multiple vendors are willing to back it, provided no single one of them controls it. All participants want to move the code to a neutral plane, where they can share in it without one gaining control or competitive advantage. The growth of open source foundations is a result of the larger, direct role that startup economics tends to play in a project without multiple vendors, said Ramji.

One example is Docker, the Linux container company. "Docker has taken over the world," and its success generated unease among developers with other ideas for containers, leading to the well-known competition between Docker and CoreOS's Rocket. IT managers told Ramji they would have to conduct a nine-month project to figure out which one to use. He responded, "that doesn't sound fast" in a business world that has to constantly adjust to changing conditions. "Sometimes competition leads to innovation and sometimes it gets destructive," he told the OSCON attendees. Companies don't want to get bogged down in deciding between competing open source projects. On June 22, Docker and CoreOS both got behind the Open Container Initiative  and agreed to adhere to a common container file format and a common runtime to simplify future tasks for enterprise container adopters.

The drive of open source projects today is not simply to create an alternative to commercial code. It's now driven by the need for "continuous innovation," by business needs that can be adapted with frequent software adjustments in any week or even through the space of a day. "Zynga used to say they deployed code 40 times a day. Now Amazon says it deploys code every seven seconds. Why do we do it? We do it to run in the cloud, to connect to any device," to constantly update applications in the cloud to adjust to business needs, Ramji said. There can't be continuous innovation if developers and operations staffs spend much of their time trying to figure out how open source code components will work together. Cloud Foundry, Docker, Kubernetes (the Google-spawned container orchestration system), Mesos (container cluster management used by Twitter, Apple, and Airbnb) and other container projects have continuous innovation as their underlying goal. "If we can bring it all together, if we can work to harmonize Kubernetes and Mesos together, we can re-imagine schedulers as plug-ins," Ramji continued, and use them as they're needed.

Single-vendor open source projects won't behave in this fashion. They'll be run by developers who have been given stock options by venture capitalists to press their momentary advantage. Only multi-vendor projects that are creating a new platform or set of components that work together will have the chance to grow into both a major project and a major force for change in cloud usage, he predicted.

Cloud-native applications are meant to function "in a world of cloud computing that is ubiquitous and flexible." Applications can be developed on a cloud platform, then deployed to different clouds where supporting software stacks will help them run at scale.

Cloud-native applications amount to "prescriptive software stacks" designed to work together for enterprises that are too busy to assemble components themselves, Ramji concluded. To get there, companies will build microservices -- discrete application services -- each running in its own container, then connect them via a network to build the application they want. Cloud native means "rebalancing the roadmap toward user-driven systems" that use standardized parts and follow standardized deployment and operational procedures.