Open Stack

On Wed, 2012-11-07 at 19:47 +0000, Gabriel Hurley wrote:
> We need to step back for a minute and question the supposition that a
> "non-core but blessed by OpenStack" category is benefical. I don't
> believe it is.

My understanding of the "non-core but blessed by OpenStack" idea is "not
required for the use of the trademark, but part of the coordinated
release" where the criteria for inclusion is the coordinated release is
quite broad.

> There are serious implications to creating a space which is not core
> but is blessed by the foundation/TC. It sends mixed messages to the
> community and has a significant impact on the ecosystem. All the
> concerns the TC has about crushing ecosystem competition when debating
> incubation apply just as much to creating a second "non-core" space.
>
> There should be Core, and then there should be a thriving community
> which is supported equally by the foundation. Nothing in between. We
> can't play favorites there.

I agree that the effect on our ecosystem should be considered when
deciding on the inclusion of a project in the coordinated release.

However, where a project fills a gaping hole in our coordinated release,
where the project is a great "fit" for OpenStack and where the project
is quite clearly already a part of the OpenStack project rather than the
ecosystem, then leaving it in the ecosystem just to encourage
competition seems very artificial.

Has including Horizon in the coordinated release crushed competition (or
even potential for competition) in the ecosystem? It probably has to an
extent, but it has been hugely beneficial for OpenStack and we are still
seeing some competition to Horizon in the ecosystem.

> I also think we're placing too much weight on the value of CI
> infrastructure and release management. Projects have been doing that
> for themselves forever and there's lots of free (or nearly free)
> services for Open Source projects readily available.

It's not so much about the value these resources bring to the individual
project, but that an individual project must use those resources to be
considered part of the OpenStack project.

So, Incubation providing access to those resources is a way of allowing
the individual project join the broader OpenStack project in preparation
for inclusion in the coordinated release.

> Ultimately making another category is just a way to dodge the hard
> issue of what is truly core. Whether core is Iaas or a viable cloud at
> all levels of the stack... that's the real debate here.
> 
> I agree (even at peril to my own project's status) that Horizon
> (currently core), Ceilometer (currently incubated) and Heat (incubated
> largely by a plurality of abstentions) fall above the realm of IaaS.
> However I think that Core would be excruciatingly lacking without the
> inclusion of higher-layer projects for two main reasons:
> 
> 
> 1.       Higher-layer projects are the only check on the unity of the
> "core" projects. Projects that span the APIs of Nova, Glance, Swift
> and Quantum are the ones that discover the pain points. They're the
> ones that can work towards OpenStack feeling cohesive. Without those
> OpenStack is just a trademark and a bunch of arbitrary code.
> 
> 
> 
> 2.       Higher-layer projects (particularly Horizon) improve the
> discoverability, usability and visibility of OpenStack. At this point
> most new users considering OpenStack experience Horizon first. When
> people want to demo OpenStack's functionalities, they use Horizon.
> That's quite telling. Humans are inherently visual creatures and the
> majority of the future users of "cloud" are not the type who want
> arcane CLIs. Folks from Amazon, Rackspace and any other cloud provider
> will tell you that services experience a huge increase in usage when
> they integrate into the dashboard. Losing that from Core benefits
> nobody.

These are great arguments for including more projects in the coordinated
release, I agree.

> As a final argument, let me flip things the other way and suppose that
> Horizon was designated a "supported" project. If that entails the
> arduous Gerrit review process and having to clear major decisions with
> the broader community rather than just letting my team keep building
> great things... that's enough of a disincentive that I'd rather not be
> "supported". I'll go build something autonomously, promote it
> aggressively, make it dead-simple to install, and if it's cool people
> will use it. People will use it in spite of a core component if it's
> better in every metric.

If the 'H' release included Nova, Swift, Glance, Keystone, Quantum,
Cinder, Horizon, Heat and Ceilometer but only say Nova, Swift and
Keystone were referenced in the trademark rules, that's ok by you right?

Again, I don't the "Core" term is helping anything here.

If we define the coordinated release as containing those projects which
we're only willing to label "Core" we end up with a much too exclusive
criteria for inclusion.

If we say the coordinated release contains both "Core" and "Extra"
classes of projects, we arbitrarily make some projects feel second
class.

Projects are either in the coordinated release or not, and we should
have fairly broad criteria for inclusion that would welcome projects
like Horizon, Heat and Ceilometer.

> Long story short, I don't see value in creating another category; I
> think we need to fundamentally define Core, let things be in or out,
> and then devote the foundation's resources to supporting the *entire*
> ecosystem, not just a handful of projects.

I think I mostly agree except:

  1) "Core" is proving to be a divisive term, we should instead 
     define our vision for the coordinated release.

  2) I think I'd draw the line between "what makes sense in the 
     release" and "what should live in the ecosystem" slightly
     differently.

Cheers,
Mark.