Swapnil Bhartiya: Can you tell us what Cloud Foundry is and how it is different from the traditional server virtualization space?

Sam Ramji: Cloud Foundry is a cloud native application platform. In the past, when people talked about Platform as a Service (PaaS), they talked about Amazon Web Services as Infrastructure as a Service and Heroku as Platform as a Service. With AWS, you get the ability to use an API to get more compute, networking, storage, etc. It abstracts – not virtualizes – but abstracts your infrastructure.

Back in 2007, a few people from Heroku said "what if instead of having to know that you are deploying these servers, you would just write a little bit of Ruby code and then you say 'git push heroku master'." You are just connecting your source control system with the bit of code that you need for a system that will take all those dependencies, combine them dynamically, put them on the right number of servers, scale it up/scale it down based on demand, attach to storage, detach from storage; that's what the platform layer is supposed to do.

Fast forward to 2015, and we have so many different clouds; people are using the term even for on-premises solutions. If you take things like OpenStack or VMware or bare metal provisioning, "cloud" really points at "elastic capability for infrastructure." So, on top of the elastic capability for infrastructure, now you need something that can be deployed across all those clouds to build cloud native applications. That's what Cloud Foundry does.

Another big aspect of cloud native-ity is bits of these code being small and portable, which leads to microservices. If we shrink all these pieces of code, if we right-size them, then we can iterate them much faster. Maybe we can update our code several times a day based on new insights. We create a platform which basically enforces a set of opinions to say how you should build your applications. How do you get this sort of elastic scalability for the apps when you are building on top of an elastic infrastructure? Fundamentally, that's what Cloud Foundry is as a project.

SB: There is also a Cloud Foundry Foundation, can you tell us about it?

SR: Cloud Foundry, as a foundation, has a legal status that allows us to do consistent collaboration with financial and technological governance across all the different contributors to the project.

We have 49 members in the foundation currently. Certainly, the founding members – VMware, Pivotal, EMC, HP, Intel, IBM, SAP – are crucially important because they are all shipping products that are based on Cloud Foundry. They are putting in engineers, putting in product representation; they are taking this to market. That's really good because that allows us to have a much larger ecosystem of companies that are not building the platform but are building applications on top. Other vendors are database companies, like Redis or Mongo, or systems management companies like New Relic.

All of this is useless if it doesn't benefit users. We brought in dozens of users such as Verizon, JPMorgan Chase, Bloomberg, Citi, CenturyLink, Telstra, and more. We are, kind of, upending the old asymmetry between software vendors and software consumers and rebalancing it. Consumers like JPMorgan Chase can identify the stuff they want on the roadmap, then they can contribute their own engineers to build that software in a way that it goes in the upstream and will be consumed by every single commercial vendor. So, there are those two sides of the equation  – you get the ability to influence the upstream, to make sure your requirements are met, and you have choice across different providers because everybody is taking the same upstream pieces.

If this sounds a lot like Linux, it's because that's the inspiration. There is a common upstream and everybody knows how to contribute, but they can run consistently across multiple vendors.

However, Linux distributions for a long time have had a lot of issues with portability of software across them. Since we have a greenfield problem with Cloud Foundry to solve, we are getting after certification to start with. This year as Cloud Foundry comes into its own, any Cloud Foundry implementation will support applications written on any other Cloud Foundry implementation. It gives users the flexibility to switch vendors; it gives them the opportunity to have multiple vendors and be able to basically split their applications across multiple data centers or just be able to have redundancy in supply.

SB: You said that you are changing the asymmetry between software vendors and software consumers; now consumers are also becoming contributors. So, what is the governance model of the Foundation? How do you ensure there is some kind of meritocracy?

SR: The governance model of Cloud Foundry is broken into four lanes  – our first lane of governance is Business Governance. This is where we deal with things like budget, standards, operations, bylaws, etc. The second lane is our Technology Roadmap: How are we actually implementing technology day by day; that's our Project Management Committee (PMC).

We borrowed a bit of the concept of PMC, as established by Apache, which gives us expandability so we can add projects as well as have them under a common conversation and contribution model. The way you vote into that committee is based on your code commits, and your code commits are governed by your actual dedicated engineers.

The third lane of governance is around Engineering Allocation. We want to be able to see not just the drop-in contributions, because distributed systems are hard to build. We generally want people to be dedicated to projects for six or more months to be productive. So, being able to work with engineering managers and executives that are committing engineering resources to work on these projects exclusively for the next several months is crucial.

And then, finally, Technology Strategy  – this is a huge component of the user voice. How do we bring in roadmaps based on needs for large users. That influences all the other three lanes – it will influence how we allocate engineers because, in some cases, users will contribute their own engineers that will influence the technology roadmap on a week-to-week basis, because Cloud Foundry ships code every two weeks under cf-release  [1]. Then, finally, that ripples to Business Governance to make sure that we continue to hear the voice of users and also bring users onto and in front of the board of directors.

SB: That's a huge operation; where does the Foundation get its funds?

SR: Cloud Foundry Foundation is a membership-driven organization, much like the Linux Foundation, of which we are part. We are formally a Collaborative Project of the Linux Foundation, in that we borrow some best practices on managing the business and also a lot of common capabilities like human resources, finance, web marketing, etc., which has been fantastic.

We gain our funding from two major buckets: One is from our members  – our members contribute at different levels – platinum, gold, and silver  – and that's what allows us to fund operations, pay our salaries to the staff, invest in market research, etc. Events are the next big category of income for the foundation.

SB: What's your role as the CEO of a foundation like Cloud Foundry?

SR: I started programming in 1980 when I was nine years old, and I made money at programming until I was about 30, when I moved into management. Then, around 2002, I started moving into marketing and strategy. So, the last decade and a bit I spent time at BEA Systems, at Microsoft, and at Apigee.

So, as CEO of a foundation, I end up running a lot of different threads: making sure that our users are happy and that we are bringing in that input; making sure the Foundation is operating well, that we have good financial basis; making sure there's a consistent way we are articulating the value of Cloud Foundry and why we care about the climate of application platforms.

And, also to make sure with this fleet of 49 members – and a dozen of them being distributors and service providers of Cloud Foundry software – that even if they're competing in the market, they are doing so in the principled way to keep the project strong and together.

The best thing that I get to do as a CEO is to build this ongoing experiment collaboratively – not just with our users or our members, but also with the staff of the foundation. We're experimenting with a holacracy model – which is that none of us is boss of any of us and that each one of us is whole in themselves.

And as a result, I have the opportunity to work with world-class people such as Stormy Peters and Chip Childers  [2]. The reason that they are here is that we treat each other with a ton of respect; there is a lot of autonomy. We get together once a month in person to make sure that we are synced; we get together every day briefly on the phone to see who needs help with what.

But, I think this is an interesting way not to just run a foundation but potentially a way that software companies will get run more and more in the future.

SB: You have worked with Microsoft and led open source efforts there. How was it working there?

SR: I worked at Microsoft from 2004 to 2009. In 2005, I wrote a paper on how Microsoft needed to respond to Linux, Apache, MySQL, and PHP. I said, basically, these open source technologies have a huge implicit internal advantage. Each piece of technology evolves independently but generally there are benefits for the whole.

There's an organic process there, and they also have a huge value proposition which is: You can try all for free, you can use it forever for free. If you want, you can build your own technical competency in operating it or you can choose from a wide range of different companies that can give you some operational muscle.

Whereas the Microsoft model at the time was: Everything is expensive and you can only get it from us. I said, "Ultimately you need to be an open source company; you need to figure out how to take your software, make it open source. Initially, you could start by making it free, and to ring-fence that, you need to make it free to developers and startups."

Eventually that became a program called BizSpark [3]. At the same time, that paper made it to corporate strategy, and they asked me to lead open source technology strategy for the company.

I led a team where we had over 120 people in 80 countries; it was called the CSI (the Commercial Software Initiative); a little bit of an Orwellian name, but we transitioned that to the Open Source Software Initiative.

The idea was if you're going to compete, compete in a principled matter; if you're going to compete with Linux, do it by being better at functionally running open source workloads on Windows. In fact, we went beyond that, and one of our engineers, Hank Janssen, ended up writing the code that Microsoft contributed to the Linux kernel under GPL to run Linux on Microsoft Hyper-V, and an echo of that code still runs today in Windows Azure.

One of the things that we realized in 2009 was that the world was moving from software licensing to cloud-based licensing, which is Infrastructure as a Service (IaaS). Once Microsoft moved to that model, there was no longer an economic mismatch between software licensing and open source. In fact, any workload would be a good workload for Microsoft.

In 2009, I left Microsoft and joined a startup called Apigee, which went public in April 2015. I had the opportunity in January to join the Cloud Foundry Foundation, so I left Apigee shortly before the IPO to lead the Foundation as its first CEO.

SB: What kind of collaboration is there between Cloud Foundry and other open source projects?

SR: There is increasing collaboration between Cloud Foundry and other open source projects. One of the most interesting ones that I'm focused on right now is the Open Container Initiative (OCI).

SB: While talking about containers, we see the emergence of competing technologies; do you think there will be some interoperability issues or fragmentation?

SR: Containers are an interesting space. A couple months ago, I was talking with some venture capitalists and their consensus estimate was there are 42  – might be higher now – VC-funded container companies. That's a lot.

We expect that there is going to be a lot of innovation in the container space. You have Docker, you have Rocket, you have Warden, and there is a new system coming out from VMware called Photon.

I think that the standard of OCI will enable a lot of different containers to innovate, where they will be able to do different implementations but still have a common backplane so that we can do what matters, which is generate, manage, and orchestrate all these containers.

OCI is also a Linux Foundation Collaborative Project. But, it's a result of the need for common container standards and contributions from CoreOS and Docker. What we are going to get, as a result, is a common definition and standard for a file format that is a container, as well as a common definition and a reference implementation for a run time.

SB: What we are seeing now is that open source has become a norm in the enterprise space. We are seeing a phenomenon where hard-core competitors are collaborating on technologies like Linux. So, in your opinion, what is driving this adoption and collaboration?

SR: There's an interesting economic basis of how software competition used to be and how it is today. It used to be that someone could build the biggest company with the smartest engineers and have the most power because you could gather those engineers, put them into a single project of your choosing, and build big pieces of software. Awesome. That worked for the '70s, '80s, and '90s.

In the 2000s, we started seeing this sort of coupling model between open source engineers and open source projects which enabled collaboration across companies. At some point, that was sort of vilified: like "okay, how do we share this; how do we not give up our patents; how do we know what the roadmap is; if we are paying these engineers how do we know what we get out of it?" Some companies really excelled at it, and they did very well. Red Hat, obviously, did a phenomenal job, as did IBM.

The basis of government acquisition of technology is increasingly open source. You can see that the US Digital Service Division and 18F have an explicit open source preference; the United Kingdom has had an explicit open source preference for some years. Those are all getting more sophisticated. And then, finally, the big mainstream companies – AT&T, JPMorgan Chase – are getting in a very, very aggressive pro open source stance.

The customers are demanding open source partly because it gives them some sense of source code escrow, that they will be able to manage this software in future when the software company may not care, it reaches end of life, or the company goes out of business. They've learned from the last several decades of enterprise computing that all the software you adopt becomes legacy eventually and will need support for decades to come.

Finally, the linchpin of that model of "being able to put together more smart engineers faster to solve a big problem" is no longer the advantage of a single company. It's much more advantageous to be able to do that across multiple companies.

So, when we look at IBM, EMC/Pivotal, HP, SAP, even Microsoft, they are ostensibly competitors. But, the collective builds such good quality software that it's so much more reliable and believable. So, there are a bunch of different components there but, to summarize: Users want it, and it is a more efficient way to build better software. The time of open source is here. Even if it hasn't taken over every corner of the world yet, it has certainly become the de facto way to do greenfield development.

I would guess that 10, 20 years from now we might not even have a phrase for "open source," because we will just say "software."