Joseph Hardin 2008 Thoughts

Thoughts on the Sakai Community

The board is a part of this community, and constitutes part of the leadership of the community; not the sole leadership by any means, but part of it. One precept is that the community is the center of the Sakai Project, not the board per se. The code is the result of a healthy community. The board provides a way, through the Foundation, to satisfy certain legal necessities, and as a steward of the funds that we have collected from members. So, what beyond this activity of providing a legal home for the code and trademark, our collective intellectual property, and the fiduciary responsibilities of management of the funds, should the board be doing?

Let's look at some places the board has done stuff. One is in organizing the conferences. This seems a useful activity, at least until they become community-based and more self sufficient. As an aggregator of funds, the board certainly, at least initially, has a role as a facilitator here. But, as in all other activities the board undertakes, it should look upon the conferences as an incubated project, one that should find a way to support itself. It is something of an historical accident that the board chair was also the conference chair, a combination of lack of alternatives early on, and my personal interest in seeing the conferences realized. This should spin off as soon as a way can be found, and, just as we devolve more of the conference decisions to various community members, such as the track leads who now control the sessions for this conference, the control of the conferences themselves should progressively move closer to those doing the conferences. There is some principle of disintermediation here, similar to one fundamental dynamic underlying the success of open source. This is one the board should promulgate every chance it gets.

In thinking about board activities, I find it useful to recognize that the board is not directing a software development project. It is not a central source of funds or resources to move the collective code base forward. It is the source of coordinating resources, such as those for the Projects Coordinator, or for the QA work, and there may be other areas where coordination is valuable, but it is the actions of individuals (corporate in some cases, individual people in others) that are the locus of software development. This is as it should be. From the beginning, Sakai has emphasized the notion that desires should lead to actions, not lobbying for action by others.
"If you feel strongly enough about something, you should go do it," "There is no magic fairy dust," "Do you want something done? Great, go find others to work with you, and go do it," have all been deeply ingrained in the Sakai creed. And I don't think the board bestows any particular authority, not should it, when it comes to determining software development priorities for the Sakai Community. Sakai Community members do that. And, of course, board members are also members of the community, so they can do what they like vis a vis initiating software development efforts. If a board member feels that some direction of development is important then she should work in that direction, not go to the board and lobby it to. Go to the lists. Build a collaborative effort. Work with colleagues. This is particularly important in developing the community-wide ethic of self-empowerment and self-determination, the ethic that is the foundation of the community. Every time the board qua board takes the initiative away from the community, it does the community a disservice. Every time a board member, as community member, initiates an effort, perhaps alone, perhaps in concert with others, he does the community a service.

There are some principles that I think are important here, one is the above fundamental notion of action being initiated and undertaken by those closest or feeling most strongly about it: "You get to make decisions if you have skin in the game" is one way of looking at this, not just because you're on the board.

Another is that "we do not have to agree to move forward." This sounds odd at first since it's somehow natural to think that thinking the same is good for a community. It surely is on some things, some shared elements, sometimes changing, sometimes recast to appear unchanging. But I think this gets turned on its head in open source projects. First note that one of the key ideas behind open source has been the radical reduction of coordination costs, embodied in the loosely coupled model that informs distributed software development efforts, and the use of the net and all its affordances to replace central decision-making. This leads to a reduction in the need for consensus, and a reduction in all the associated costs of gaining that consensus. Consensus is expensive, to attain and to maintain. And while consensus can sometimes be a powerful tool to keep fledgling groups together, be they nations or software development efforts, I would suggest the need for consensus is reduced as the community matures and differentiates, and as core values emerge. Our core cohesive values are embodied in the code, constantly reaffirmed by our adoption of it, and constantly renewed by the work we do around it, alone and together. The working code is a recurrent reality check on us and our different approaches to making working code. We have found different ways to do this, and need less and less to agree on how we go about this in each individual case. We need to agree about less and less as we go along. This becomes a positive value for the support of diversity within the community (see below).

Democratic models have sometimes arisen to replace consensus with majority rule, but I would argue that in distributed communities like Sakai's, systems of referential authority have appropriately arisen to largely replace democracy. Sometimes referred to as meritocratic models of coordination or authority delegation, these are especially useful as the complexity of an artifact increases and the focus of individual portions of the community stray from overarching concerns to more specialized areas, as they must if a project like Sakai is to be successful. As in other open source software development projects, the code itself acts as a creator of common ground and coordinator of activities, and the lists and wikis and such act as an open communication mechanism. The idea of transparency embodies some of these notions. I don't have to agree with what you're doing in a community like Sakai's but I have a strong interest in knowing what you are doing. I can then make better decisions about what I do, or perhaps, take the time to talk to you about what you are doing, maybe join your effort, maybe try to encourage you to take a different route. Hence we have the advantage in needing even less agreement on lots of things than other types of communities might that have, for instance, only corporate identity, or a shared set of norms to maintain their cohesion and ability to sustain coordinated actions. Indeed, the less we must agree to in order to move forward, the less we need to agree on, the more liquidity there is in the community's actions, the more diversity the community can tolerate and the more various resources we can bring to bear to a large set of problems. The goal of online discussion is thus quite often not consensus, but communication. Not having to agree and still be able to move forward is a good thing.

The board, in this space, should help the community, to the extent it can, in change management and recognition and validation of diversity. We are in an evolving and emerging community of lots of different types of people and organizations, and the board can help make sense of the, often seemingly conflicting, approaches to problems that different people use, and the different values that different people ascribe to various activities and methods. We need to help discuss within the community the variety of working and indeed thinking styles that are extant in our community, and lead in making such explanations part of the openness that the community cherishes. There are many ways to develop good code, to design good user experiences, or have good sessions at a conference. Our job is not to choose between them as the board, but rather to recognize those that are successful and those that are not and, through an open discussion within the community, try to figure out what we can learn from them, and, perhaps, inform the activities of those actually doing the work. The board, along these lines, needs to bring its deliberations out from the board list and into the open forum and/or advocacy list. To the extent that there are black boxes within the community, whether of code, or of communication, or of conduct, the community will have less freedom of movement, less information to base its choices on, and will consequently feel, and be, less empowered.

These are relatively disconnected thoughts, I know, but are leading me in the direction of focusing on the activities of a minimalist board. This is very different from the usual self-perceptions of such groups, who look to growth and the extension of their influence as an overarching goal. That is not what I would argue for here. Efforts to extend the board's influence into various areas should be chosen very carefully and the question must always be asked: "Why the board? Why not a group of doers?" "What is special about the board's knowledge of X?" The burden should always be on the board to answer that. Coordination of various activities is probably just as well done, in my experience, better done, by a group that grows up naturally, feels strongly about something and decides to actually do it.