Open Stack

John, appreciate your candor and candidacy. Some questions inline for you...

On 09/26/2016 06:57 AM, John Davidge wrote:
> Last year, the TC moved OpenStack away from the Integrated Release, and
> into The Big Tent. This removed the separation between those projects
> considered integral to OpenStack, and those which enhance it.

Who decides what is integral to OpenStack and what merely "enhances" it, 
though? The TC? The DefCore group? The Board of Directors? One might say 
all three groups have a say in defining what "is OpenStack", no? And 
therefore all three groups would decide what is "integral" to OpenStack.

> Since then, the number of official projects has gone from ~12 to 60.
> While this was a fantastic move for community inclusivity, it has
> also made life harder for operators and customers

We do indeed have a long way to go in improving the operator's 
experience for many OpenStack projects.

However, remember that many of the OpenStack projects came into 
existence because operators were asking for a certain use case to be 
fulfilled. I'm uncertain how putting some projects into a 
not-really-OpenStack-but-related bucket will help operators much. Is the 
pain for operators that there are too many projects in OpenStack, or is 
the pain that those projects are not universally installable or usable 
in the same fashion?

> and has diminished the focus on OpenStack’s core
> purpose.

What is OpenStack's core purpose? :) The OpenStack mission is 
intentionally encompassing of a wide variety of users and use cases. The 
Big Tent, by the way, did not affect this fact. The OpenStack mission 
pre-exists the Big Tent. All the Big Tent did was say that projects that 
wanted to be official OpenStack projects needed to follow the 4 Opens, 
submit to TC governance, and further the mission of OpenStack.

It sounds like you would like to limit the scope of the OpenStack 
mission, which is not the same as getting rid of the Big Tent. If that's 
the case, hey, totally cool with me :) But let's be specific about what 
it is you are suggesting.

> Managing every team under one roof has led to issues for both the core and
> the newer projects. The experience so far has taught us that there isn’t a
> single set of rules that can be helpfully applied to both.

Hmm, I disagree about that. I think that experience actually *has* shown 
us that there is a single set of rules that can/should be applied to all 
projects that wish to be called an OpenStack project.

> I believe that now is the time to take The Big Tent’s ideas and
> iterate upon them to create a new model that can promote inclusivity,
> while still preserving a clear focus for the core of OpenStack. The
> main points of this new model are:
>
> * Define OpenStack as its core components

Which components would these be? Folks can (and will) argue with you 
that a particular service is critical and should be considered core. But 
differing opinions here will lead to a decision-making inertia that will 
be difficult to overcome. You've been warned. :)

> * Introduce a new home for complementary projects - The OpenStack Family
> * Reinstate Stackforge as the primary incubator for new projects

Having Stackforge as a separate Github organization and set of 
repositories was a maintenance nightmare due to the awkwardness of 
renaming projects when they "moved into OpenStack".

Also, reminder: The Big Tent != the dissolution of Stackforge.

> OpenStack will once again be a focused set of closely aligned projects
> working together to provide an operating system for the datacenter.

As I've said before, this was never really reality, even since the 
beginning of OpenStack. :)

 > The
> OpenStack Family will provide a home for projects that work to improve the
> experience of an OpenStack cloud (think Ceilometer, Heat, etc), while
> protecting them from some of the more prescriptive rules that go with being
> a core OpenStack component. Stackforge will be the main focus of
> early-stage innovation, with a clearly defined path towards graduation into
> The OpenStack Family.

Who gets to decide this graduation? The TC? The DefCore committee? The 
Board of Directors? What criteria would you use in the graduation 
requirements? Would they be technical criteria or governance/process 
criteria?

What technical benefits would graduating give to a project? If no 
technical benefits -- the benefits would be entirely marketing, 
political or reputational -- then should the *Technical* Committee be 
the group that decides whether a project graduates?

These are all questions that you will inevitably be asked to consider 
when you go (back down) the route you suggest. So, I think it's worth 
responding here in your TC candidacy mail.

All the best,
-jay

 > I believe that this model[4] can go a long way
> towards solving many of the pain points that we are seeing with OpenStack
> today.
>
> This transformation is one that I think is very important for the future
> of OpenStack. We have a fantastic project surrounded by a talented
> community, of which I am very proud to call myself a member. Trust me with
> your vote, and I’ll work hard to ensure its continued success.
>
> Thank you for your consideration,
>
> John
>
> [1] https://www.youtube.com/watch?v=pmpRhcwyJIo - Curvature
> [2] https://www.youtube.com/watch?v=GjuF-3fB0IQ - IPv6 Prefix Delegation
> [3] https://www.youtube.com/watch?v=4ag1NiCVBDo - Neutron Purge
> [4] https://johndavidge.wordpress.com/mr-openstack-tear-down-this-tent/
>
> ------------------------------------------------------------------------
> Rackspace Limited is a company registered in England & Wales (company
> registered number 03897010) whose registered office is at 5 Millington
> Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy
> policy can be viewed at www.rackspace.co.uk/legal/privacy-policy - This
> e-mail message may contain confidential or privileged information
> intended for the recipient. Any dissemination, distribution or copying
> of the enclosed material is prohibited. If you receive this transmission
> in error, please notify us immediately by e-mail at abuse at rackspace.com
> and delete the original message. Your cooperation is appreciated.
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>