openstack-poc team mailing list archive

[Eric Day <eday@xxxxxxxxxxxx>]

> > I'm not sure what barriers there really are right now that prevent
> > contributors. Swift and Burrow are setup the same way as Nova and
> > Glance on Launchpad, and Keystone is on github. If Swift and Burrow
> > don't have the same openness, but keystone does, I don't think this
> > has anything to do with the tooling or autonomy since up to this
> > point they have been more or less the same. I think it has more to
> > do with visibility or attractiveness of work that needs to be done.
> 
> I would partly agree with this, sure. However, I don't see how having
> *more* autonomy helps bring OpenStack projects together nor encourage
> cross-project contributions.

My point was that more autonomy doesn't help, but it doesn't hurt
either. More autonomy may help motivate more developers and produce
better code though, which does help.

> > Swift is fairly mature so it doesn't require the same level of
> > attention. It probably isn't going to gain the same popularity as
> > the VM fabric components though.
> 
> I disagree, but we can agree to disagree.
> 
> > Burrow is still early on and does have the same visibility yet,
> > and will probably not have the same popularity either even when it
> > is mature.
> 
> I disagree again :)

http://www.elastician.com/2010/06/aws-by-numbers.html

It's not perfect data of course, but the fact is VM services are
more popular. My experiences have supported this. Many people who
I've talked to about cloud and Amazon think AWS == EC2. Some have
never even heard of their other services.

I'm not saying Swift and Burrow can't have thriving communities,
but we should not expect them to be the same as Nova.

> > All this is perfectly fine of course, we just need to realize each
> > project is somewhere different on the spectrum, or on an entirely
> > different spectrum. Drawing comparisons between them can sometimes
> > be comparing apples to oranges, which is why I think less policy and
> > more autonomy is a better route.
> 
> I don't see how you reach that conclusion. If we are to compare
> OpenStack projects to each other, we either view them as interrelated
> components of a cloud computing platform, or we don't. If you do view
> them as interrelated, then having the projects follow an agreed-to set
> of vetted options makes them more comparable as apples. If you don't
> agree with the overall philosophy, then everything will always be
> apples and oranges.

I'm saying if you have expectations for Burrow to have the same level
of community as Nova, we're always going to be disappointed. This has
nothing to do with being interrelated, just with your original point
that the contributor community for these projects are not where Nova
is. The point I'm trying to make is this is not due to tooling or
autonomy, but due to the nature of the projects.

As a result, I don't think freedom of choice in tooling or more
autonomy will hurt this, as is being demonstrated by Keystone to
some degree already. If devs want to contribute, they will find a way
whether it's bzr, git, hg, or emailing patches. What we do gain is more
motivated devs and community who may have a greater sense of ownership,
especially as we start accepting more projects into OpenStack.

Personally, I don't have much preference, but some people do. I don't
want to discourage great projects or devs due to policies that I
don't think give us much.

I understand not everyone shares this opinion or vision for what
OpenStack is, but as you say, we'll just have to agree to disagree. :)

-Eric