openstack-poc team mailing list archive

[Joe Heck <Joe.Heck@xxxxxxxxxx>]

On May 7, 2012, at 7:45 AM, Thierry Carrez wrote:
>> "COMMUNITY"
>> ============
>> 
>> Everything else - additional APIs that map to the OpenStack kernel, proprietary plugins that provide services or functionality to core pieces (like Keystone and Quantum plugins, Volume drivers) actually have FAR more benefit by NOT being core.
>> 
>> Key differences:
>> * We should provide a means to make these pieces/projects/etc discoverable, and very easily. (and I think we all agree, and Monty is doing some "forge" thing website to make this happen as I understand)
>> * The release cycle of these components is completely independent of releases of OpenStack
>> * Compatibility is the responsibility of the community project, and we don't gate changes to future work in OpenStack based on it potentially breaking a community project
>> * These projects don't need to be open source
>> * These projects don't need to be controlled or mandated by OpenStack as an organization or community
>> * These projects are where most of the value-add for using OpenStack will be most clear.
>> * OpenStack "CORE" is the kernel being made to support *THIS* set of projects - in the kernel/userland metaphor, this is userland. This is where a thousand flowers bloom.
> 
> So the difference between (b) and (c) is about supporting (or not
> supporting) additional adjectives to the "Community" group (starred,
> tested, certified, compatible, recommended...), based on extra
> tests/QA-integration/mojo they provide and we recognize. We can do (b)
> and then evolve into (c), but not the other way around :)

In trying to explain how I was confused by this statement, I realized that I'd been confusing the intention of option (c) - I don't particularly want to have a means of certifying, recommending, or approving of something from OpenStack that isn't part of the core. That would appear to be a LOT of additional work and resources to no significant benefit to OpenStack itself, and relatively little to the community aside from making some attempt to verifying that some other project is compatible with our core. 

So with that in mind, I'm firmly doing an about face and suggesting that we follow (b), and additionally that we use the term "official" to represent the ancillary and supporting efforts that help us to make OpenStack.

-joe