“Figure out how to take the right steps that will evolve the technology. That is my main goal”

An Interview with Chip Childers

Chip Childers is the co­founder of the Cloud Foundry Foundation and has been its Chief Technology Officer since 2016, now he is the Executive Director of the Foundation. During his visit in Berlin, we had the opportunity to meet up with him and get insight into the organization. What are they up to and what is to come?


Tell us some background. What is the Cloud- Foundry Foundation and what does it do?

Simply put, the Cloud Foundry Foundation owns the intellectual property for the open source Cloud Foundry software and protects the trade­ mark. The Foundation is a 501(c)(6), meaning it is a non­profit and that the intellectual property of the Cloud Foundry open source project can never be acquired for profit. The role of an open source foundation in general is to help support the participation of individuals so they can collaborate on code. Organizations can use the open source project without buying it. On top of the baseline responsibility of holding the intellectual property, the Foundation collaborates with member companies on marketing initiatives, supports and hosts events, provides education and certification programs, and more. We don’t ship any software; our community builds that.

Cloud Foundry Foundation is a sister organization to the CNCF and we are a collaborative project of the Linux Foundation. We are sup­ ported by our member companies; the goal of our membership is to help support ecosystems around the Cloud Foundry platform. Multiple Cloud Foundry Certified Providers sell commercial distributions of the software, including VM­ ware (formerly Pivotal), IBM, SAP, and regional companies like Swisscom in Switzerland. We also work with and support the end user organizations who use the open source software itself, though the majority of users purchase Cloud Foundry from one of our Certified Providers.

The Foundation exists to help the vendors and end users that build and sell the open source platform. Typically, the Certified Provider companies selling a commercial distribution are also the ones who spend the most time building the software, though end user organizations take their knowledge from using the platform to help contribute back to the code. We help all of these companies collaborate with each other, integrate with other open source projects and build an ecosystem around it.


What was your role in this as CTO?

My role is to help the technical community to collaborate more effectively. I build relationships with different vendor organizations. It’s my job to understand their needs and goals. It is very com­ mon for vendors not to be able to see they have a shared goal. I help them define the opportunities for collaboration within the open source ecosystem. The Foundation is neutral territory for many of these competitive companies to come together, and I help oversee that process. I work closely with our member companies to figure out the right steps to evolve the technology.

I also run various programs, education, and community management.


How did you end up in this role?

I’ve been in the industry for 25 years. I started as a developer in the internet boom process back in the late nineties.

I went from web developer to building business applications. From there I shifted into working for a large managed services provider where I did a lot of infrastructure and automation, from using to getting deep into building. I also learned a lot from working at startups. I was looking for a new opportunity at the same time the Cloud Foundry Foundation was being formed and came on to guide the process.


What kind of topics are you promoting?

Right now, the community is in the middle of a transition within our cloud native architecture.

We are at the point where Kubernetes has finally reached maturity, so the Cloud Foundry community can use it to replace a very purposeful component within the Cloud Foundry project. To us, the container orchestration layer is a component of a larger platform, not a platform in­and­of itself. The same is true for service mesh technologies, and in our case, we are integrating Istio. We see these things as features or architectural components of the system.

At this point, Kubernetes is mature Enough for us to adopt it, even with a handful of specific use cases that will need to be addressed. In fact, many of the companies involved in building Cloud Foundry are working deeply within the Kubernetes community to address these gaps and the whole Cloud Foundry community is looking forward to the continuing evolution of Kubernetes. We are going through the transition of bringing Kubernetes into the architecture and making sure that our community is continuing to intermingle with Kubernetes and other open source communities.

Istio is a big component right now as well. Istio is a service mesh project that is owned by Google. We are yet to see how it evolves. Right now, it has been integrated into the Cloud Foundry infrastructure. Because of this integration, members of the Cloud Foundry community are also participating in the Istio community. This has helped to push forward efforts that align with the use cases the Cloud Foundry platform has for underlying networking technologies like Istio.


“The role of Open Source Foundation generally is to help support the participation of individuals so that they can collaborate together.”


How do you handle the struggle to separate politics, innovation and commercial interests? This is always a difficult thing for the enterprise technology market, especially in enterprise soft­ ware. There is an enormous amount of open source development, but it has not entirely re­ placed proprietary or closed source software. But because it is such a major factor, open source is driving a lot of competition and a lot of commercial pressure. This is showing up in a couple of different ways. It shows up in how the large vendors that we work with interact with each other. There is a term to describe this: “Coopetition,” which is a combination of “cooperate” and “competition.”

Luckily the companies that I work with all know how to do coopetition. With open source, working with your competitors can help us to build a market around that technology.

But it can get difficult, because these vendors do have pressure to sell. This can trigger some interesting behavior. But overall, I think we have a sort of best practice that have emerged. Thankfully most of the companies that I work with knows what they are.

Venture capitalists have put a lot of money into open source, so there is pressure among the biggest hyperscale cloud providers, like Amazon, Google, Microsoft and Alibaba. All of them are commercializing open source software; however, a lot of open source software is owned by venture­backed startups, for example, Mongo DB and Elastic. These companies are struggling with the problem that Amazon has the open distribution of Elastic and thus profits off of it the most. We are going to get to an interesting time where the larger, more established companies with a lot of different revenue streams are going to have to help guide the venture capital com­ munity in how to think about what open source is. It is not a business model; it is an under­development model, a community model – but there the role of open source Foundation generally is to help support the participation of individuals so that they can collaborate together is no such thing as open source business model. Red Hat, for example, is not an open source business model. They are an incredible software support service company who happens to make open source software that they support.

In open source, there is an implicit code of conduct in how we interact. This isn’t related to who your employer is, but rather how to behave within the open source community in which you’re participating, whether as an enterprise developer, code contributor, end user, etc. There is no official corporate code of conduct for how companies interact with each other, but we have built that up through practice – and the Foundation has created a shared community code of conduct and values. Do the companies within our ecosystem try to shape the product in order to have an advantage over their competitors? Yes, that happens. But the rule in the community is to strive for consensus, and if you can’t reach it, don’t stop until you do. We have a system in place to make decisions in these rare cases. Companies with more engineers working on a particular project have more votes; this is called governance by contribution. But that is the second step. As a first step, we strive for consensus and rely on the community to understand that purposefully disadvantaging your competitor will ultimately hurt the collective more than it’s going to help your company.

When disagreement occurs, it is not necessarily because an organization has intentionally put another company at a disadvantage. I’ve seen well­intentioned mistakes made. Fundamentally, it comes down to empathy. If there is a lack of empathy for another individual’s or companies’ opinion, I try to pull that person aside and ask, did you think about their perspective?

Let’s say you have a large­scale operator who operates big multi­versions of the system. They will have a very different perspective than someone who packages it up as software and sells it. I’ve seen these two sides forget about the other. This is where empathy comes in. The more understanding for other people and companies’ perspectives, the easier it will be to collaborate. Vendors spend too much time thinking about how to compete with each other and not enough time thinking about the end users. This is a big problem in the majority of the market with people being unable to adapt to change. When those who create the technology don’t have empathy for the organization adopting that technology and what it takes for them to go through with that level of change, that becomes an issue. This is a global phenomenon. It is very difficult for the technology to make it in the mainstream market in China, for example, but when it does it really takes off, while in Europe we see more of a clean bell curve. We are all struggling with our limited human ability to adjust to change.

What can you tell us about the overall adoption for CF?

The Foundation does not have detailed visibility into the adoption of Cloud Foundry. We have a sense of the adoption based on data from direct users of the open source code, data from global surveys we’ve conducted, and data from some of our certified providers. Some certified providers are happy to share their customer base; others don’t talk about theirs.

In general, I think Europe is slightly behind on adoption. There is a macrotrend of cloud adoption that is a little bit faster in the United States, which still leaves out parts of the Asian market pretty significantly. It helps that SAP and SUSE both have strong presences here in Germany. They are the two companies that I would say are probably generating the most Cloud Foundry­related business in the European market at the moment.


And of course, we are curious about projects for the future!

Our primary goal is to simplify the application development experience for enterprise developers working in cloud. It’s that simple. Any project we are building is being built because nothing previously existed to solve that problem for developers. We want to give software developers the freedom to focus on developing their applications rather than spending time on infrastructure. Right now, the open source market is creating a ton of infrastructure technologies. This is a blessing – we can rely more on other open source communities to build the infrastructure bits. What that means is that we can spend more time and energy on the developer experience.

As far as other projects go, we are interested in the evolution of the Functions­as­a­Service (FaaS) market as it relates to the Platform­as­a­Service (PaaS) market. Both are in the business of abstraction. FaaS (or Serverless) is a very fractured market at the moment, but Lambda is the one serverless technology that has risen above the rest. There is no open source alternative that has any significant adoption right now. A project like knative from Google is interesting, but it’s not really a developer experience. It’s more like plumbing, built on top of Kubernetes.

There is opportunity for a world­class developer experience around FaaS if the industry can align around it. There are similar opportunities for other types of development tooling. I am a fan of the work that is happening with the continuous delivery space, for example.


Right now, we are at a point where Kubernetes finally reached maturity so that we can begin to use it and to replace a very purposeful component that we have in our system.


Is open source really safe? What do you want to say to our readers about security concerns?

Nothing is 100% secure. If you feel insecure, you should build your own software. But if you don’t have the skills, trust or experience to use open source code directly – don’t do it. There is a reason why companies are commercializing open source software and offer it as a service, or offer it as a software and then consult for you. When a vendor is selling a technology, there should be some level of indemnity – handling licensing issues, providing a level of security insurance, etc. There is a huge surface area that you need to pull security updates from. Vendors do it on your behalf.

Open source software is no different than proprietary software. All software has bugs, all software has vulnerabilities. And people have different priorities, different focuses. For example, the small projects are more manageable but have less eyes on them and bigger projects have bigger risks but also more people looking at them. Suggest the conversation. The good that is going to evolve out of the chaos requires that chaos to actually happen!

Ultimately, I’d say it is okay to be skeptical about the security of a technology. Don’t adopt a project if you’re uncertain. Wait until the product is commercialized. That takes some of the risk away.

What is your take on the devops movement?

The devops movement was and is about changing the model for how we think about the software development and operations pipeline, which has benefited organizations around the globe. DevOps principles focus on faster iteration, faster release cycles and more operational accountability for developers. That said, there are things that a developer should not be building herself. There are also examples of IT services that operators should no longer spend their time on. No one should run an email server anymore, for example, except for the big email providers. I truly believe that. Stop wasting your time and outsource!

Developers, specifically, do not need to run everything themselves, but they should be responsive and feel a strong sense of ownership over their software’s production environment. When I think about optimizing for their flow, I know they can do this if they are running their own environment, but that is missing the whole idea of having an operations team who offers something as a service to the development team and takes as much work as possible away from them. It is a well­tested service experience. Take PaaS run by an internal team, for example, in which developers own the code, their app’s lifecycle and the production instance of the ap­ plication. What they actually own stops at the application itself. They don’t touch the cluster underneath. Responsiveness is the goal, so why don’t we optimize around that goal?


What would you like to tell our readers?

Be intelligent and thoughtful about how you look at all the applications and IT systems you have today. If there is no benefit in picking it up and moving it – don’t. If there is no benefit in re­ writing it – don’t. If you are going to choose to move things, pick it up and move it. Don’t assume software that has been picked up and put into Kubernetes is going to exhibit cloud native attributes. Don’t take engineers and drop them into Kubernetes to write custom software. I truly believe that is the worst experience for custom software development. A lot of people think that is what they should be doing. It’s not designed for that, so they are wasting time. Work with someone who is already there and ready to help. Too many people reach for the next shiny thing and so much time is wasted, because that technology has nothing to do with what you are trying to achieve for your company. Focus on what matters.


Thank you for participating.


The interview was conducted by Emelie Gustafsson and Michael Dombek.