Forum .LRN Q&A: Response to Request for Comment: dotLRN Technology Governance
That's why I've been trying hard to think of an example of a project comparable to dotLRN with a proven track record (committees that don't stifle innovation) and compare their governance model.
How about the Continental Congress? That was a committee that didn't stifle innovation. Now, if I made the same claim about today's Congress, some might find the statement to be a bit more problematic. What's the difference? It's all about what the committee does. Rules make our nation(s) possible. They make cooperation between nations possible. They make free markets work. Rules are, in turn, made by committees of stakeholders. The difference between rules and committees that make innovation possible and rules and committees that stifle innovation depends largely on what the committees do and do not try to accomplish. The Continental Congress created the rules of a game where anybody could play. Their goal was not to control the game but to define it in such a way that playing that game was to everyone's benefit. The goals of today's Congress are, unfortunately, often quite different.
The critical question in our case is this: What is it that the committees are supposed to do? Are they supposed to micromanage the development of the application? If so, then we would have real cause to worry. However, that is not how the purposes of any of these committees have been defined.
Keep in mind that the dotLRN "governing" bodies in no way restrict what Open Source developers can do; the GPL ensures that. Innovation still comes from the bottom--by design. The committees are designed to create an environment that both fuels the grass roots source of innovation and provides participants with better ways to get the most out of the product of that innovation. The fuel innovation by providing a channel of information to the developers (and I use the term "developers" to mean the teams of people who are scratching their own itches, including but not limited to programmers) from the wider world about what other people might find useful. They in no way direct the efforts of the individual development teams, except perhaps by encouraging and supporting them with funding, feedback, and inspiration. Once the development has happened in the Open Source style that has proven so effective, the committees collectively help to evaluate and categorize the output of the individual efforts to make sure that output will be as useful as possible to as many constituents as possible. Again, anybody can do whatever they want with the code, as long as they don't call it dotLRN. The existence of these committees in no way stops anyone from trying anything. What the committees do, collectively, is apply a seal of approval to a subset of the code that emerges as a result of the innovation that the combination of Open Source and open markets brings. They lower the barrier for people and organizations who want to play the game but are afraid that they don't have sufficient knowledge to choose the combination of Open Source parts that meet their needs at an acceptably low risk. If you don't care about the dotLRN seal of approval, then you as a developer or consumer are in no way constrained by what they have to say. They have power only to the degree that consumers and developers choose to opt into their system. In other words, their power rests entirely in their ability to nurture and sustain a community that agrees to invest (time, money, risk, whatever) in dotLRN because the benefits they gain from doing so outweigh the rules that the community imposes as the price of entry. That's no different than OpenACS, really.
Committees are neither inherently good nor inherently bad. Rules are neither inherently good nor inherently bad. Markets are neither inherently good nor inherently bad. Open Source is neither inherently good nor inherently bad. Licenses are neither inherently good nor inherently bad. All of these are simply tools we use to tune the incentives that various stakeholders have to innovate, participate, and collaborate. All of them can be used poorly or well.
I think the design we have on-hand promises to serve our collective purposes well, if we remain vigilent and remember that they are means to a collective end.