Open Stack

On Thu, 31 Mar 2011 00:44:07 -0400
Todd Willey <todd at ansolabs.com> wrote:

> I haven't disagreed with those points.  I'm not advocating the removal
> of blueprints or changing the way we select release goals.  I only
> don't want to be so strict that we push back against our users instead
> of being their allies.  Openness and transparency don't exist in a
> project just because it uses blueprints, and a lack of using
> blueprints does not correlate to being closed or opaque.  When it
> comes to high level goals, specs are pretty much required to achieve
> openness (I get that, really I do).  But when it comes to individual
> patches and one-off contributions, openness and transparency are
> served by merge proposals and reviews.

Been heavily involved in Linux kernel development, I would tend to
agree.

Sounds like the importance of blueprints is overrated. If you look at
Linux kernel development (more than ten times developers and
development speed, I guess), you see that lots of developers can work
well without something like blueprints.

I think that eliminating barriers to contribute code is much more
important for success. If you ask people to do something before
involvement (sign CLA, create a launchpad account, writing a blueprint
for a tiny feature), you have less change to see that they would be
new developers.

I don't think that blueprints are helpful for some problems discussed
in this thread (e.g. prioritizing new features). I think that we need
more strong lead for them. I like to see maintainer per subsystem (not
per project) to coordinate developers on a daily basis.

I don't think that openness and transparency are not related with
blueprints. You can simply discuss, make a decision, etc on public
mailing lists.

Duplicating work isn't necessarily bad. Likely developers solve the
same issue differently so we can understand different approaches
better and have the good code in the end.