I wrote this up in an E-Mail discusison and figured that it was kind of cool so I figured I would blog it. Feel free to disagree.

Looking at the base level operating principles of Sakai – just like Apache – we believe in open source, open community, meritocracy, do-ocracy, and the collective wisdom of the community. In a sense we depend on intelligent brownian motion to “do the right thing”. We know that there is no way to take something as rich and diverse as Sakai and orchestrate it in the classic top-down corporate sense.
Our bylaws are very careful not to “appoint” anyone to positions of “power” like in a traditional corporate organization – no volunteer reports to any other volunteer or to Foundation staff. Viewed from an individual contributors perspective we attempt to be as egalitarian as possible. We never want a new member of community to feel that they “report to” anyone or are to “take orders” from anyone – we are all created equal – anyone can by their own investment and commitment – do anything they want to do in Sakai.
That said, Sakai is not random – nor do we make major decisions “by committee”. Tactical technical decisions are made by those volunteers with commit responsibilities for the various components of Sakai – we strongly encourage open engagement with the entire community – this is often teams of 1-5 people who have long term commitment to that software – but at the end of the day – the project teams for the parts of Sakai self-determine – just like Apache.
On top of that we have paid staff – the Executive Director, Project Coordinator, Branch Manager, Framework Architect, QA Director, and others (not all are paid at this time – some volunteer to be Foundation staff and all that entails).
This group of folks *is* coordinated and works together in an org chart way – people are paid – so this is “OK” – none of the volunteer developers “report” to the Foundation staff. The Foundation staff are there to serve the community and help the community communicate and coordinate amongst themselves.
There are times where the Foundation staff assert more control – that is not around development, but instead around releases and long term direction. Foundation staff consult the community all the time, but ultimately are empowered to make some decisions. For example, the Foundation staff will decide what goes in each release and when the release will happen.
The Foundation staff insure that we keep the community together – they are naturally motivated to listen to the community and do what is best for the *overall* community – not just individual developers or organizations. If the Foundation staff get uppity and start making bad decisions as seen by the community – we will fork the community and organizations will cease to see Sakai as providing value and Foundation Staff salaries will go away and we will have to lay off people. So the motivation to be responsive to the overall long-term needs of the community is important – the consequences of a Foundation staff member alienating the community in the long term are very tangible.
The Foundation staff in their coordination role can affect long term direction by giving advice to the volunteer community. Mostly this comes in the form of “I want to try X – do you think this will make it into the release?” or “Is there something that I should do to this tool or feature to make sure it fits into the release?” This way folks can have some sense of their individual work fitting into the always evolving plan/roadmap. Foundation staff do their best to publish the plans/roadmaps – always encouraging community comment to make the plans better.
That said – decisions do get made – and there are examples of decisions where there are several conflicting strongly held opinions among the community – we do not wait until everyone agrees – we make a decision and move on. Hopefully in the fullness of time these decisions will be “right” more often than not and those who were in opposition – will either be satisfied some other way – or satisfied later – or will change their opinion in time when it turns out the right decision was made. If the wrong decision is made – that will also become apparent in time and we will re-adjust – hopefully learning from our experience.
And if in the final analysis, a decision seems particularly difficult to resolve – the Executive Director makes the decision. Often the toughest decisions need to be made quickly or a lot of effort will be wasted.
In summary, Sakai takes great value from the “brownian motion” of the community’s ideas and enthusiasm – it is the source of Sakai’s energy – but we do have a few folks who try to steer things so as to move in some coordinated direction. There are checks and balances (very strong) that make sure that the folks “steering” Sakai do not drift far from the overall goals and needs of the community – their salary depends on keeping the overall community happy in the long run.
If you look at other open source efforts – including across Apache – those projects with some type of identified leadership do much better than those projects which are just a committee with no “committee chair”. Projects which have leadership like Jetspeed (David Taylor) and Pluto (David DeWolf) thrive much better in the long term than projects like WSRP4J where when you ask if it is OK to do something – then answer is effectively “sure – whatever”. The key is making sure to only have leadership that “adds value” and is “service-centric” – not leadership that becomes oppressive and power-centric.