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.
