Open Stack

On Fri, 20 May 2016, Thierry Carrez wrote:

> The other approach is product-centric: "lower-level pieces are OpenStack 
> dependencies, rather than OpenStack itself". If we are missing a lower-level 
> piece to achieve our mission and are developing it as a result, it could be 
> developed on OpenStack infrastructure by members of the OpenStack community 
> but it is not "OpenStack the product", it's an OpenStack *dependency*. It is 
> not governed by the TC, it can use any language and tool deemed necessary.
>
> On this second approach, there is the obvious question of where "lower-level" 
> starts, which as you explained above is not really clear-cut. A good litmus 
> test for it could be whenever Python is not enough. If you can't develop it 
> effectively with the language that is currently sufficient for the rest of 
> OpenStack, then developing it as an OpenStack dependency in whatever language 
> is appropriate might be the solution...

I don't think language does (or should) have anything to do with it.

The question is whether or not the tool (whether service or
dependent library) is useful to and usable outside the openstack-stack.
For example gnocchi is useful to openstack but you can use it with other
stuff, therefore _not_ openstack. More controversially: swift can be
usefully used all by its lonesome: _not_ openstack.

Not being in OpenStack (where "in" means "of the product") is good
for OpenStack, good for the project and good for opensource in general:

* Outside the OpenStack bubble, looking in, one can see a bunch of
   complexity and a bunch of bad architecture decisions but rarely
   see the good stuff that is actually there, so it is easy enough to walk
   away. Good stuff that a larger audience could benefit from may get
   dismissed, if that good stuff has an opportunity to have an
   independent identity, it can be useful.

* A project that is used by a larger and more diverse audience
   (people-wise and technology-wise) will of necessity be more
   robust.

* A project that defines itself as independent will be required to
   have strong and narrow contracts to satisfy its diverse audiences.

* A project that has those strong and narrow contracts can use what
   ever language it likes and still be useful and nobody really needs
   to care all that deeply except for the people making it. If they
   want to be in a language that infra doesn't want to support,
   that's fine: there are plenty of other ways to do CI.

* An openstack which is more narrow is far easier for people to
   comprehend and contemplate.

* A broad opensource world that has lots of nice things is a better
   one.

-- 
Chris Dent               (╯°□°)╯︵┻━┻            http://anticdent.org/
freenode: cdent                                         tw: @anticdent