Winged Monkey

Jiří Stránský jstransk at redhat.com
Fri Oct 26 09:50:12 UTC 2012


On 25.10.2012 22:32, Hugh Brock wrote:
> Lesson 1: A single upstream project should do one thing,
> well. Deltacloud is actually a good example of this; it has profited by
> limiting itself to a stateless cloud API. Most of the OpenStack
> services -- Glance, Swift, Cinder, Nova, Quantum -- also conform to this
> principle. Heat has also explicitly tried to limit itself to one key
> feature -- manage multi-tier applications on OpenStack -- with
> reasonable success.
>
> Lesson 2: Build things in small pieces that a single developer can
> understand without too much effort. Our community will, in the end, be
> built by interested developers who find a piece of what we're doing
> valuable to something they're doing. We may at times finding ourselves
> doing *more work* to keep things small. This is a perfectly reasonable
> cost for the benefit we will derive from upstream adoption.
>
> Lesson 2b: Keep project teams small. If a project is complex enough that
> it needs more than three developers to make forward progress in it, it
> will soon be incomprehensible to outsiders, thereby failing Lesson 2.
>
> Lesson 3: The umbrella project for a set of individual projects should
> have good, open governance, in which not just coding standards and API
> styles but also the overall project goals and metrics are agreed by a
> committee in an open process that has at least some degree of
> formality. In other words, it should be possible to debate the structure
> of an API, put it to a vote, and have it be a settled question from
> thereon. Otherwise the individual projects under the umbrella will fail
> Lessons 1 and 2.
>
> Lesson 4: The umbrella project must itself have a compelling goal that
> gets people excited and is easily understood. OpenStack is a
> free-software reimplementation of EC2. Everybody wants private cloud and
> everybody wants to not be locked in, so OpenStack is really
> compelling. (Note Aeolus has quite similar goals, just on a meta-cloud
> level.)
>
> Lesson 5: The umbrella project has to get talked about at a lot of
> conferences by a lot of different people.

I agree with this and btw it goes very much in align with Dave Neary's talk at community training I attended recently. I have some notes about making Aeolus more "community friendly". I will take a look at them soon and see if they're more fit for mailing list or Aeolus dev conference.

> 1. We need to fix the governance. This means that you folks, the Aeolus
> developers, need to figure out what model we are going to follow for
> making architectural decisions, API decisions, coding style decisions,
> and so on, put it in place, and stick to it. I would suggest that that
> model be more sophisticated than "argue about it on the mailing list and
> never come to a conclusion," which is what we've done to date.

+1, I also have a few notes about this.

J.



More information about the aeolus-devel mailing list