acs at parvuscaptus
Feb 20, 2012, 8:11 PM
According to the timeline and my understanding of the exercise, every
option is still open. The point of a draft is to refine the details.
Reading the draft structure and the commentary/questions on this thread,
and then seeing the new thread on the technical committee, I believe there
that might be other ways to frame future discussions.
For one thing, I don't think it is easy to process and compare information
about draft proposals when they are written as prose, and I think there are
better representations to work through ideas before the word smithing.
Also, while I appreciate the sentiment to minimize disruption, there will
never be a better opportunity to adjust aspects of OpenStack so all
grievances and suggestions should be considered.
For the purpose of working out the structure, I propose we need a clearer
representation of what is being proposed.
One clear theme is identification of several positions and committees.
There has also been discussion concerning groups deserving representation
on the board, followed closely by what is the best proportional
representation for each group.
The draft proposal identifies two groups, individuals and strategic members
for the board. For the purpose of discussion, I think it will be easier to
compare options and trade offs if we represent this aspect of the
foundation in a table that identifies the groups, the proportional or
absolute representation, the mechanism by which the representation will be
determined, the qualifications for group membership, and any comments on
the rights and obligations of that class of membership.
The current proposal is simple enough, so I'll just keep it in line, but
for anything more complicated, I believe a spreadsheet will make things
easier to see and discuss than outlining the details in prose.
| Strategic Members | 2/3 | every strategic member has board representation
| multi-year monetary commitment | unclear beyond board and resource
| Individual Members | 1/3 | popular vote | 'do stuff' for the project |
continued participation | tbd |
If people think this representation helps clarify the board composition for
discussion, we can try using the wiki, but I personally think a shared
spreadsheet may be better for edits and discussion. (at least I think so)
There have been multiple suggestions to expand the classifications beyond
these two groups in various ways, supported with examples from the Linux
and Eclipse foundations.
One suggestion is a stratification of the Strategic (or whatever the label
will be) members into different levels by some yet undetermined measure of
commitment into tiers of precious metals. (I'm not a fan of the
Platinum/Gold/Silver labels, but that's mostly aesthetics)
In addition to stratification, I would like to suggest considering that
'Strategic' support might be divided into halves between strategics that
are building products based on OpenStack, and strategic users of OpenStack.
This is similar to the Eclipse structure of developers and consumers. Some
organizations may feasibly be both. I could see trade offs and benefits to
allowing representation (and resource commitment) to the same organization
for both, but my initial inclination would be only allow for one or the
This could be represented something like:
| Strategic Products | 1/3 |
| Strategic Services | 1/3 |
| Individual Members | 1/3 |
Of course, it gets ever more complicated if you stratify each group as some
have proposed, I still believe this representation is easier to understand
and discuss than paragraphs.
I also think the notion and eligibility of 'individual members' should be
clarified. The majority of individual contributors are likely to be
salaried employees of strategic members. I personally disagree with the
notion of hats put forward in the strawman. Trust is great, but not as a
basis for governance, and making interests and alliances explicit is more
open and transparent.
As alluded to in the initial email on the technical committee, the
foundation should probably outline specific things that are prohibited and
some mechanism for addressing grievances and infractions.
I would like to see similar breakdowns for the other proposed committees.
Namely, who will be represented in what numbers, who is eligible, and the
mechanism for appointment to the committee.
If there is not going to be 'user' representation on the board, what are
the powers, rights and responsibilities of the user committee? How to best
evaluate, prioritize and feed user interests into the development effort?
I would like to see the relationship between the different committees made
explicit. How do these groups interact with each other? What are the checks
Also, how do the committees relate to the executive director? How is that
position chosen? who is eligible? Is the hired staff of the foundation
eligible for participation in the committees?
Finally, for the moment, we haven't seen a public discussion about money. I
have had conversations with Mark, Jonathan and other parties, and I think
everyone agrees that there needs to be a significant monetary commitment.
Where I see differences is on the topic of what the foundation will
ultimately be responsible and obligated to do, which cannot fully be
resolved independent of the question of committed resources. These are two
sides of the same equation. I'm sure that's one of the questions that was
clearly left knowingly unaddressed, but I urge that these discussions are
brought out sooner rather than later.
Most of these things are best finalized with a group of people all in the
same room, a constitutional convention if you will. I believe that might be
what is implied by the drafting committee, so maybe in addition to further
comments on the topic of the drafted structure, we can get some more
details on what the process will be to move forward from the draft to a
fully ratified and supported foundation.
I look forward to seeing the foundation come together in a way that aligns
the considerable efforts being put into OpenStack by all parties.
Andrew Clay Shafer
-------------- next part --------------
An HTML attachment was scrubbed...