Open Stack

Hi Thierry, thanks for the reply. Comments inline. :)

On 08/20/2014 06:32 AM, Thierry Carrez wrote:
> Jay Pipes wrote:
>> [...] If either of the above answers is NO, then I believe the
>> Technical Committee should recommend that the integrated project be
>> removed from the integrated release.
>>
>> HOWEVER, I *also* believe that the previously-integrated project
>> should not just be cast away back to Stackforge. I think the
>> project should remain in its designated Program and should remain
>> in the openstack/ code namespace. Furthermore, active, competing
>> visions and implementations of projects that address the Thing the
>> previously-integrated project addressed should be able to apply to
>> join the same Program, and *also* live in the openstack/
>> namespace.
>>
>> All of these projects should be able to live in the Program, in
>> the openstack/ code namespace, for as long as the project is
>> actively developed, and let the contributor communities in these
>> competing projects *naturally* work to do any of the following:
>>
>> * Pick a best-of-breed implementation from the projects that
>> address the same Thing * Combine code and efforts to merge the good
>> bits of multiple projects into one * Let multiple valid choices of
>> implementation live in the same Program with none of them being
>> "blessed" by the TC to be part of the integrated release
>
> That would work if an OpenStack Program was just like a category
> under which you can file projects. However, OpenStack programs are
> not a competition category where we could let multiple competing
> implementations fight it out for becoming "the" solution; they are
> essentially just a team of people working toward a common goal,
> having meetings and sharing/electing the same technical lead.
>
> I'm not convinced you would set competing solutions for a fair
> competition by growing them inside the same team (and under the same
> PTL!) as the current mainstream/blessed option. How likely is the
> Orchestration PTL to make the decision to drop Heat in favor of a
> new contender ?

I don't believe the Programs are needed, as they are currently
structured. I don't really believe they serve any good purposes, and
actually serve to solidify positions of power, slanted towards existing
power centers, which is antithetical to a meritocratic community.

Furthermore, the structures we've built into the OpenStack community
governance has resulted in perverse incentives. There is this constant
struggle to be "legitimized" by being included in a Program, incubated,
and then included in the integrated release. Projects, IMO, should be
free to innovate in *any* area of OpenStack, including areas with
existing integrated projects. We should be more open, not less.

> I'm also concerned with making a program a collection of competing
> teams, rather than a single team sharing the same meetings and
> electing the same leadership, working all together. I don't want the
> teams competing to get a number of contributors that would let them
> game the elections and take over the program leadership. I think such
> a setup would just increase the political tension inside programs,
> and we have enough of it already.

By prohibiting competition within a Program, you don't magically get rid
of the competition, though. :) The competition will continue to exist,
and divisions will continue to be increased among the people working on
the same general area. You can't force people to get in-line with a
project whose vision or architectural design principles they don't share.

> If we want to follow your model, we probably would have to dissolve
> programs as they stand right now, and have blessed categories on one
> side, and teams on the other (with projects from some teams being
> blessed as the current solution).

Why do we have to have "blessed" categories at all? I'd like to think of
a day when the TC isn't picking winners or losers at all. Level the
playing field and let the quality of the projects themselves determine
the winner in the space. Stop the incubation and graduation madness and 
change the role of the TC to instead play an advisory role to upcoming 
(and existing!) projects on the best ways to integrate with other 
OpenStack projects, if integration is something that is natural for the 
project to work towards.

> That would leave the horizontal programs like Docs, QA or Infra,
> where the team and the category are the same thing, as outliers again
> (like they were before we did programs).

What is the purpose of having these programs, though? If it's just to 
have a PTL, then I think we need to reconsider the whole concept of 
Programs. We should not be putting in place structures that just serve 
to create centers of power. *Projects* will naturally find/elect/choose 
not to have one or more technical leads. Why should we limit entire 
categories of projects to having a single Lead person? What purpose does 
the role fill that could not be filled in a looser, more natural 
fashion? Since the TC is no longer composed of each integrated project 
PTL along with elected reps, there is no longer a need, IMO, to restrict 
the number of project leads by having Program Technical Leads.

> Finally, I'm slightly concerned with the brand aspect -- letting
> *any* project call themselves "OpenStack something" (which is what
> living under the openstack/* namespace gives you) just because they
> happen to compete with an existing openstack project sounds like a
> recipe for making sure "openstack" doesn't mean anything upstream
> anymore.

As a technical community, I believe we should focus on designing and 
writing the best software we can, and let the software's quality, 
features, ease of use, and stability speak for itself. Let the Board and 
the marketing folks handle decisions around what can and can't be called 
"OpenStack whatever". Provide the Board and the marketing folks with a 
set of quality projects that are well-integrated, packaged consistently 
with distros, and tested thoroughly for stability and scale, and leave 
it at that.

Best,
-jay