Open Stack

Hey

I think too much of this discussion has been about the fairly arbitrary
names we have for different classes of projects. The term "Core" isn't
actually all that useful to us in the discussion, or more generally,
because everyone has their own idea of what the term means.

There are two important things being discussed here - our vision for the
coordinated OpenStack releases and the rules around the use of the
OpenStack trademark.

They are different things - a project being included in the coordinated
release does not mean it has to be deployed in order for a provider to
use the trademark.

For the sake of focusing the discussion, we should ignore the trademark
question for now and focus on our vision for the coordinated release.

I see our coordinated release as being a cloud provider's toolbox of
great projects that are designed to work well together built by a
community with a unified mission.

To be included in the coordinated release, a project needs to meet set
of criteria which we should clearly define[1].

If a project looks promising, it is accepted into Incubation for a full
release cycle so that is fully prepared to be included in the next
coordinated release. Projects must go through at least one release cycle
as an Incubated Project, but multiple cycles may be required if it turns
out it needs more time to be fully ready for inclusion.

Cheers,
Mark.

[1] - Example of what our criteria for inclusion in the coordinated
release might look like:

  - Development process - follows the standard OpenStack development 
    process; everything from git, gerrit, launchpad, team meetings, 
    wiki, blueprints, milestone releases, etc.

  - Community - has a solid community of folks contributing to the 
    project, a community that looks like it has longevity

  - Openness - the project's community not only follows our development 
    process, but is truly committed to open development and welcoming 
    new leaders into its community

  - Fit - the software needs to "fit" with the rest of OpenStack. I 
    don't think we should be overly prescriptive about this (e.g. 
    "projects absolutely must be written in Python") but deviations 
    from Openstack norms (like use of Python) would need to be 
    justified and considered carefully.

  - Integration - as well as being a good fit for OpenStack, new 
    project's should also integrate well with existing projects where 
    that makes sense.

  - Scope - new projects, almost by definition, will expand the scope 
    of the OpenStack release but we should be growing the scope in 
    careful, measured ways. Maybe someday OpenStack might have a e.g. 
    CDN project, but we should only consider including such a thing 
    where it is a sensible, incremental expansion of OpenStack's scope. 
    In the case of the CDN example, that might be where OpenStack 
    already does PaaS really well and a CDN to support applications 
    deployed on our PaaS solution is an obvious need for providers 
    already using our PaaS solutions. Clearly, that's a long, long way 
    off if it ever happens at all.