History

CloudFreeStyle was started as a concept at The PDX Cloud Foundry Hackathon on April 14th, 2012.

Elephants

The topic of governance in the CloudFoundry project has become something of an "elephant in the room" with the community of businesses, developers and other stakeholders surrounding the project. During lunch time, a discussion of the VMWare's new commit workflow came up.

A general disappointment was expressed by all in attendance with both the process and attitude VMWare was presenting. We realized that many of the stakeholders for the project were in the room and so, the question was posed:

"Why is this a problem, exactly, and what would be a  more positive way to contribute as stakeholders to this project?"

Problem Statement

The problem was formally stated as:

• Problem: VMWare owns and manages the CloudFoundry project.

Why is this a problem?

• Fair voice for all stakeholders

  When a single for-profit entity owns and manages the project, the other stakeholders may not receive a fair voice in the decision making process.

• Longevity

  What happens with VMWare decides to stop supporting the project? What if VMWare changes it's mind about investing in and pursuing CloudFoundry? Other stakeholders in the project may want to see it continue beyond the lifespan VMWare has in mind. If they are owning and managing it, if they decide to kill the project, we have no significant recourse.

• Commit Workflow

  The recent changes to the commit workflow (using Gerrit) seem overcomplicated, too tightly controlled, and anathema to the way open source projects are generally developed and managed. Further, VMWare has not built any trust with the community regarding accepting contributions since over 100 pull requests remain outstanding on the project, so going back many months. There's a concern that though the new process is an improvement, that it's still far from what is desired by the community.

• Velocity

  As stakeholders in the project, we want to move as quickly as possible, coding and contributing back the project. That means we need a high level of visibility into the project direction, the ability to pose questions and resolve decisions rapidly and fairly, and the ability to have contributions applied to the project in a timely manner. So far, none of those things have been happening and the only way to maintain velocity within an organization is to maintain a private fork of the project, then attempt to sync when updates are provided from VMWare. This is causing things to move very slowly, generally speaking.

• FOSS Ideals

  Operating as a corporate owned project with a minimal amount of "openness" and "inclusiveness" with the community surrounding the project flys in the face of established FOSS ideals. As passional open source developers, we do not want to contribute to a project, no matter how awesome it is, unless it's fully open.

• Competing Implementations

  There's is no established way to deal with competing implementations of features and code. One good example is the .NET support provided by IronFoundry vs Uhuru. These are very different implementations. Which one is the "official" implementation which gets accepted back into the CloudFoundry project? How is that decision made? Arbitrarily by VMWare or fairly by the community?

• Not Invented Here Syndrome

  Many of the stakeholders feel that there's a significant Not Invented Here tendency in the CloudFoundry project which, it is assumed, is not due to technical reason, but more a result of the isolation of the project from the larger open source community or possibly corporate interests such as licensing and IP concerns. The most recent example of this is the new Bosh system, which could probably have been implemented using existing open source tools.

Solutions

A number of possible solutions were discussed, and ultimately one decided upon.

Possible Solutions

• Engage in open discourse with VMWare to improve their current process - REJECTED

  This idea presumes that VMWare will continue to manage the project, and improvements could be made by open discourse with the community to eventually reach a situation which was mutually amenable to all stakeholders. This was discounted as both "tried" and "failed". The general consensus is that there is not enough trust in the stakeholder community that this process would result in the desired outcome.

• Ask VMWare to donate CloudFoundry to an open source software foundation such as Apache Software Foundation, the Software Freedom Conservancy, or similar. - REJECTED

  This idea would entail starting a discussion with VMWare which would eventually result in the donation of the project to an established and trusted open source software foundation. There was also very little faith in the likely success of this idea. The generally feeling was that VMWare would not be able to understand FOSS ideals and the previously stated issues well enough to agree to this.

• Start over with a new codebase - REJECTED

  This idea suggested that we could start over, re-writing the CloudFoundry codebase as a 2.0 product, written by and managed in a typical FOSS manner. This was deemed to be too much work and not in the best interests of the existing developer community, and so the idea was rejected.

• Create a community fork - ACCEPTED

  This idea suggests creating a community-run fork of the CloudFoundry project which is managed in the open using The Apache Way (though not actually being an Apache Software Foundation project). This idea was preferred because it could be done without violating VMWare's licensing, and does not depend on their consent. Further, it's a natural way to evolve a project on GitHub. Since it would be a direct fork, it would be reasonable to continue to integrate code changes from the VMWare project back into the fork, so that VMWare could continue to be a significant part of the development community.

Proposed Solution

The proposed solution was formally stated as:

• Solution: Create a community fork of the CloudFoundry project.

  Specifically, this project would be a public fork on Github, and manage itself through the Software Freedom Conservancy (when issues such as legal status, donations, etc arise). Further it would use the model presented by the Apache SOftware Foundation (known as The Apache Way) for fair and open project management. It will be called CloudFreeStyle in order to respect VMWare's CloudFoundry trademark ownership.

How does this solve the stated problems?

• Fair voice for all stakeholders

  One aspect of the The Apache Way is that a project is required to have a heterogeneous Project Management Committee (PMC). The PMC is responsible for leading, managing and resolving decisions about the direction of the project. A successful PMC will be composed of a balanced representation from all stakeholders in the project (eg, no single entity will have a controlling representation at the PMC level). Decisions will be made in public, in the project mailing list, and will be voted upon in the normal ASF manner.

• Longevity

  While no project is completely independent, and may still fall mercy losing support from the sponsoring entity, it is felt that we can trust Github and the Software Freedom Conservancy more than VMWare for long-term support of the project infrastructure and community.

• Commit Workflow

  We will use the fork/pull-request workflow that is common on Github to accept submissions back to the project. This is viewed as an ideal methodology by the community. It removes the middleman of VMWare, and places the decision making process about which contributions are accepted in the hands of the PMC instead of a single entity.

• Velocity

  The improved commit workflow will allow for faster iterations, and the increased visibility into project direction will allow developers to move forward in a more cohesive manner. It's expected that more contributions will be submitted by those who may currently be reserving their effort due to lack of trust in VMWare's existing process. An inclusive and open attitude will attract more developers.

• FOSS Ideals

  "Inclusiveness First" - Duke Leto
  

  The project will be significantly more "open" and "fair", bringing it more inline with expected and established FOSS ideals. As Duke Leto stated during the meeting we will hold the values of "inclusiveness first" as a core tenant of the project management philosophy.

• Competing Implementations

  The PMC voting process will provide a fair forum for resolving the problems of competing implementations.

• Not Invented Here Syndrome

  Open discussion about project goals will encourage reuse of existing technologies. Lack of corporate licensing concerns will make integrating other open source projects less of a risk.