Open Stack

James E. Blair wrote:
> Thierry Carrez <thierry at openstack.org> writes:
> 
>> Removing the root cause would be a more radical move: stop offering
>> hosting to non-OpenStack projects on OpenStack infrastructure
>> altogether. We originally did that for a reason, though. The benefits of
>> offering that service are:
>>
>> 1- it lets us set up code repositories and testing infrastructure before
>> a project applies to be an official OpenStack project.
>>
>> 2- it lets us host things that are not openstack but which we work on
>> (like abandoned Python libraries or GPL-licensed things) in a familiar
>> environment
>>
>> 3- it spreads "the openstack way" (Gerrit, Zuul) beyond openstack itself
> 
> I think this omits what I consider the underlying reason for why we did
> it:
> 
> It helps us build a community around OpenStack.
> 
> Early on we had so many people telling us that we needed to support
> "ecosystem" projects better.  That was the word they used at the time.
> Many of us said "hey, you're free to use github" and they told us that
> wasn't enough.
> 
> We eventually got the message and invited them in, and it surpassed our
> expectations and I think surprised even the most optimistic of us.  We
> ended up in a place where anyone with an OpenStack related idea can try
> it out and collaborate frictionlessly with everyone else in the
> OpenStack community on it, and in doing so, become recognized in the
> community for that.  The ability for someone to build something on top
> of OpenStack as part of the OpenStack community has been empowering.
> 
> I confess to being a skeptic and a convert.  I wasn't thrilled about the
> unbounded additional responsibility when we started this, but now that
> we're here, I think it's one of the best things about the project and I
> would hate to cleave our community by ending it.

I think that's a great point, Jim.

I spent a lot of time last week analyzing the "negative space" (things
that are on our project infrastructure but are not openstack), and there
are indeed a number of projects which would qualify as "companion
projects": David's ARA, the swift3 Swift middleware, or Neutron plugins
for some proprietary hardware that got kicked out of the Neutron
stadium. There aren't so many of those, but keeping those close to us is
definitely a good thing.

Ideally we would find a way to continue to host those, without creating
any doubt as to whether they are an official OpenStack project under TC
governance. Such options to address the confusion at the edge exist, and
they were explored in the previous thread (selective GitHub replication,
aggressive tagging, active removal of obviously-dead things, separate
branding/domains...). The main issue being, those options all involved a
lot of work for the infra team, work that is not conceivable with its
current limited resources. The only reason why I put the nuclear plan B
on the table is that we can't get the plan A properly done...

-- 
Thierry Carrez (ttx)