[openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

Ed Leafe ed at leafe.com
Fri Jul 14 21:10:35 UTC 2017

On Jul 14, 2017, at 2:17 PM, Zane Bitter <zbitter at redhat.com> wrote:

> * The pool of OpenStack developers is a fixed resource, and if we make it clear that some projects are unwelcome then their developers will be reassigned to 'core' projects in a completely zero-sum process. (Nnnnnnope.)

Yeah, I’ve heard this many times, and always shake my head. If I want to work on X, and X is not in OpenStack governance, I’m going to work on that anyway because I need it. Or maybe on a similar project. I’m going to scratch my itch.

> * While code like e.g. the Nova scheduler might be so complicated today that even the experts routinely complain about its terrible design,[1] if only we could add dozens more cooks (see above) it would definitely get much simpler and easier to maintain. (Bwahahahahahahaha.)

No, they need to appoint me as the Scheduler Overlord with the power to smite all those who propose complicated code!

> * Once we make it clear to users that under no circumstances will we ever e.g. provide them with notifications about when a server has failed, ways to orchestrate a replacement, and an API to update DNS to point to the new one, then they will finally stop demanding bloat-inducing VMWare/oVirt-style features that enable them to treat cloud servers like pets. (I. don't. even.)

Again, itches will be scratched. What I think is more important is a marketing issue, not a technical one. When I think of what it means to be a “core” project, I think of things that people looking to “get cloudy” would likely want. It isn’t until you start using a cloud that the additional projects you mention become important. So simplifying what is presented to the cloud market is a good thing, as it won’t confuse people as to what OpenStack is. But that doesn’t require any of the other projects be stopped or in any way discouraged.

-- Ed Leafe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170714/667b7201/attachment.html>

More information about the OpenStack-dev mailing list