The Cloud Foundry Way: Open Source, Pair Programming and Well Defined Processes

This is a series of posts about Cloud Foundry–both the community and the project–and how these teams work. Please comment and ask questions so we can answer them in future posts!

Cloud Foundry is a unique open source software project. Actually, it’s a collection of projects that all together make a product that helps organizations run applications on an industry standard, multi-cloud infrastructure. A whole bunch of developers and product managers, who believe it should be easier to develop, deploy and maintain apps in the enterprise, have gotten together to make this possible. Cloud Foundry helps organizations run applications across languages and clouds.

Unlike many open source software projects, Cloud Foundry has been created with a set of deeply thought out engineering practices that originated with Pivotal and have been added to and adapted by many. There’s a clear path to becoming part of the project with time given each week to ensure the projects are well-balanced and have the necessary resources. This allows many large companies like Pivotal, IBM, EMC, SAP, GE, HPE, Fujitsu and others to collaborate not only on the code, but also on the direction of the project.

So how does it work?

• Anyone interested in Cloud Foundry can follow along on mailing lists and Slack.
• Developers can track changes and submit pull requests in github.
• Each project has a product lead. The product leads are responsible for managing the backlog of each project in public trackers.
• There is a monthly Community Advisory Board (CAB) where all the product leads get together, give updates and let anyone ask questions. You can join the next one!
• While anyone can submit a pull request, the path to becoming a contributor is clearly defined.
• New potential contributors apply to a Dojo. To apply, they take a test. If accepted, they are expect to spend 6 weeks physically at the Dojo pairing with more experienced project members.
• After contributors finish their six weeks in the Dojo, they are Cloud Foundry committers and they agree to spend a year working on Cloud Foundry.

The bar to entry is high – some that take the entry test do not pass – and the requirement to spend 6 to 8 weeks physically in a Dojo with the expectation of a long term commitment to work on Cloud Foundry likely means you must work for a company that wants to invest in Cloud Foundry.

A Dojo is a physical space that resembles a big open office or co-working space, often occupied by standing desks. These dojos are hosted by Cloud Foundry member companies and can be found in the San Francisco Pivotal offices, in Raleigh at IBM, in Cambridge at EMC, and at other locations around the world. While some spaces are more quiet than others, people used to cubicles or co-working spaces might find the amount of talking surprising at first. This is because pairs of programmers are talking to each other and collaborating all day.

One of the unique things about Cloud Foundry is that all code is written in pairs. Two programmers work together to write each piece of code. We’ve discovered this greatly improves code quality in addition to morale and work/life balance for the developers. They start their morning with a standup meeting then spend the day working together, taking an occasional break for a game of ping pong or lunch. They don’t spend much of the day on social media or email – they spend it coding together. We’ve experimented some with remote pairs as well.

“Pairing is liberating. It forces you to “think out loud” and correlate your understanding of the feature with your pair. The net result is high confidence, high quality and ultra high velocity (no more building the wrong thing).”
– Steve Greenberg, Pivotal

Developers interview to be assigned full-time to projects. In addition to a team of developers, each project team has an engineering manager from one of the participating companies assigned to support them. Project leads meet weekly at the Allocations (LL) meetings to make sure resources are balanced while developers move around to make sure all projects are covered. Also included is “the anchor” – a developer who has agreed to remain on that project long term for consistency instead of moving around as projects need a particular expertise.

“Pairing can initially be intimidating, especially since someone is watching your every move, but very quickly you appreciate having another person around to help get through a frustrating story, give you another perspective, and my favorite part, teach you something new. It’s a fun way to develop, a fast way to learn, and most importantly a great way to efficiently collaborate.”
– Swetha Repakula, IBM

New projects are proposed by anyone, but typically a product lead or contributor, often by one of our member companies, is the one to start a new project.

While the product leads are the ones that make day-to-day decisions and manage the backlog (i.e. roadmap), there is also a Technical Advisory Board (TAB) that discusses and influences the long-term direction of the project. TAB members are nominated from the Cloud Foundry member companies.

Requirements across projects and the roadmap are discussed weekly and coordinated across all projects. The combination of clearly defined processes for becoming a committer with working relationships across companies, combined with clear, open communication paths, creates a quiet, confident group of developers that focus on producing high quality code.

This article was originally published at Cloud Foundry.