Open Stack

Excerpts from Sandy Walsh's message of 2014-05-06 07:02:05 -0700:
> On 5/6/2014 10:04 AM, Thierry Carrez wrote:
> > John Dickinson wrote:
> >> One of the advantages of the program concept within OpenStack is that separate code projects with complementary goals can be managed under the same program without needing to be the same codebase. The most obvious example across every program are the "server" and "client" projects under most programs.
> >>
> >> This may be something that can be used here, if it doesn't make sense to extend the ceilometer codebase itself.
> > +1
> >
> > Being under the Telemetry umbrella lets you make the right technical
> > decision between same or separate codebase, as both would be supported
> > by the organizational structure.
> >
> > It also would likely give you an initial set of contributors interested
> > in the same end goals. So at this point I'd focus on engaging with the
> > Telemetry program folks and see if they would be interested in that
> > capability (inside or outside of the Ceilometer code base).
> 
> This is interesting.
> 
> I'd be curious to know more what "managed" means in this situation? Is
> the core project expected to allocate time in the IRC meeting to the
> concerns of these adjacent projects? What if the core project doesn't
> agree with the direction or deems there's too much overlap? Does the
> core team instantly have sway over the adjacent project?
> 

Yes, the core team instantly has sway. It is not to be taken lightly.

We absorbed Tuskar into the Deployment program, and our PTL, Robert
Collins, was able to get involved with the design of Tuskar early and
convince them to stay more aligned with other OpenStack projects. So
the benefit is now Tuskar can focus on the thing that they _do_ need
to do that are unique.  Likewise, their core team was given core status
in the deployment program, and was able to influence the pieces of the
Deployment program that they needed to work better.

This has created a nice cycle of contribution where many aspects of the
Deployment program's projects have been improved as a result. Had Tuskar
decided to just stay out of the Deployment program, they might have
reimplemented many of the things we had already done, and thus would
be less adoptable by users and they would receive less contribution as
a whole.