Open Stack

Well said.

After reading through this ML thread multiple times and really trying to
give all viewpoints a thorough amount of time to sink into my brain,
I've come to the following conclusions:

1) The idea of "core" vs. "supported"/"ecosystem"/"related" is really
NOT all that important to users (whether users are service
providers/operators or developers or IT departments or universities or
anyone). The distinction is immaterial to users of OpenStack in the same
way that a distinction between an engine and a steering wheel are of no
consequence to a driver of a car -- while the car may not run without
the engine, it's pretty pointless to the driver if he can't steer the car.

2) The idea of "core" vs. "supported"/"ecosystem"/"related" DOES matter
to product and business development folks since the Board of Directors
uses the concept of "core" vs anything else in its evaluation of
trademark enforcement.

3) The idea of coordination -- in releases, in Development/CI/QA
tooling, in community management, and in the approach that APIs and
implementations are transparently developed -- is the REAL topic of
discussion for the Technical Committee, not what is "core" and what isn't.

4) Inclusiveness matters. Exclusive communities tend to stagnate whilst
inclusive communities tend to grow -- with growing pains, but they grow.
OpenStack should be a growing community, not a shrinking or exclusive one.

In conclusion, I came into the Technical Committee meeting this week
with a set of opinions that I have pretty much maintained for over a
year now: that "core" should mean infrastructure-only projects and that
we should only incubate projects that are considered
infrastructure/foundational.

After the meeting and this discussion, I've changed my mind and I no
longer think it is useful for the Technical Committee and the technical
community to distinguish between "core" and "supported". I think that
incubation should refer to the following:

 A joint commitment between the proposing project and the existing
OpenStack developers, CI, Community/Release Management and QA teams to:

 * Adopt OpenStack common practices and tools used in developing and
testing the project
 * Adopt OpenStack common practices for tracking documentaion, bugs and
a roadmap
 * Agree to coordinate releases of the project **at least as often as
the OpenStack 6-month release cycle**, though the project is able to
release more often as desired.
 * Work with other OpenStack projects to reduce integration point
friction and better consume/utilize existing OpenStack APIs
 * Use a single 6-month release cycle to "blend in" with the
above-mentioned tools and practices

A proposal by a project to "incubate" would merely then be a simple
agreement of best faith to follow the above things and nothing more than
that. At the end of the six month incubation period, the Technical
Committee would be asked to decide whether they believe the project
tried in best faith to adhere to the above points, and if not, decide
whether to rule the project as "not OpenStack", whether to include the
project in OpenStack and/or to give additional incubation time and some
suggestions for areas of improvement.

Best,
-jay

On 11/09/2012 11:23 AM, Zane Bitter wrote:
> On 08/11/12 06:34, John Dickinson wrote:
>> OpenStack Core should be defined as IaaS, and the "batteries-included" parts should be part of the ecosystem but not part of core.
> 
> I'd like to address the idea that has come up several times this week 
> that "ecosystem" projects are competing on the merits of their code, and 
> that by promoting a particular project to core OpenStack would be 
> engaged in prematurely "picking winners" and therefore distorting the 
> free competition between projects.
> 
> That's not how I see it: Open Source projects compete on the strength of 
> their communities, not the merits of their code. A good community can 
> fix just about any code, but code can never save a weak community. And 
> it seems to me that the TC absolutely is qualified to make judgements 
> about this.
> 
> In my opinion, if a group has:
>   * A problem that is common to a substantial proportion of OpenStack users;
>   * A solution to that problem in the form of working (if incomplete) code;
>   * A proven commitment to do things the OpenStack way; and
>   * A record of collaboration with the larger OpenStack community
> 
> then there *needs* to be a place for them in OpenStack proper, not just 
> as a Related project. Because otherwise we will continue to see these 
> important problems being solved piecemeal by proprietary projects; or 
> projects that are not developed in consultation with the community that 
> are then dropped on us out of the blue, written in Java or having 
> problematic dependencies or any number of other fundamental 
> architectural problems that would have been ironed out right at the 
> beginning if development had happened in the open. That situation is bad 
> for developers (who have to deal with a balkanised ecosystem), bad for 
> providers (who have the expense of maintaining their own individual 
> implementations), and especially bad for users (for all the reasons that 
> Monty has pointed out elsewhere in this thread). It would result in 
> OpenStack being much less relevant than it ought to be.
> 
> Now, the definition of "Core" is currently linked closely to trademarks. 
> So if you prefer to define "Core" as Nova + Swift + Quantum with 
> everything else as an Official but not Core project then that's fine by 
> me (although I personally find the distinction pointless). Projects like 
> Heat or Horizon exist only to work with other core projects, and are 
> unlikely to be distributed independently. But I am completely opposed to 
> banishing everything else to the non-official "ecosystem". The 
> ecosystem, of course, has its place, but its place is specialised 
> functionality and plugins that allow providers to use different 
> back-ends without breaking API compatibility for users, not as a 
> catch-all for all the things that are an essential part of a modern IaaS 
> offering but aren't Compute, Object Storage or Networking.
> 
> cheers,
> Zane.
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>