On WorldForge Project Organization Philosohy

This is a pretty deep topic that we could probably discuss without end. There's plenty of different ways to organize groups of individuals to achieve common goals (whether clear and completeable or rather vague and abstract like ours).

Personally, my own political philosophy leanings are towards decentralization, perhaps even sort of anarchical and self-organizing. I don't like the idea of some power monger dictating to me how to do my job (let alone my freetime hobby), and I'd assume most of you feel similarly.

However, anarchist philosophy is not exactly something many of us have been schooled in, and there's relatively few examples to pattern ourselves after, so instead we use a hierarchical organization - a style of organization all of us are schooled in and have a lot of experience with - but we make a lot of room for as much anarchy as we can handle. ;-)

For example, we always make it clear that everyone is allowed to work on whatever they feel should be worked on, and still feel part of the project. We trust that most individuals can figure out what's good for the project themselves or by talking with other developers or coordinators.

The vision is that we organize in smallish product teams. The teams should strive to make decisions by concensus, but since with programmers this is like wishing song from a troll, so each team has a coordinator identified with it.

We use the term 'coordinator' instead of 'leader' or 'manager'. Coordinators identify possibilities and suggest courses of action; they shouldn't just dictate to everyone how everything "must" be done. If we wanted to be forcibly directed like that we could just get a second job and be paid, right? I believe that a good leader is one who merely finds out where his team already wants to go, and just points the way; doing otherwise - while sometimes very necessary - is bound for strife and if done too often a recipe for disaster. It's important to remember that coordinatorship is a responsibility, not a reward for good work.

Another critically important function of coordinators is to facilitate broad communication. Many of us choose to work in a few small areas, and thus have limited knowledge of what others are doing. This is in part by necessity - the amount of time spent reading up on what everyone else is doing leaves little time for your own development work. So it is important for coordinators to try to "glue" people together. This includes not only looking for and identifying duplicate work or potential for collaboration, but also resolving miscommunications, disharmony, and other such problems. At the least, coordinators should strive to not continually be the cause of disharmony and so forth, else the project will die in flames.

But all this aside, please, PLEASE remember that all of the coordinators are human too, and in fact really are no different from other developers except in job title. (Certainly we're all paid the same.) They can and will make mistakes, they can be wrong, and they can easily get overwhelmed by the amount of work to be done. A lot more is expected of a coordinator than is expected from a regular teammember, both in terms of dedication and attitude. It's all too easy to lure your team coordinator into overcommitment. But there's a lot that a teammate can do to help alleviate these problems: Volunteer to write some process docs for the team; help foster and enhance both intra-team and inter-team communications; publish status reports of what you and your teammates are working on, regularly; or look for that ugly, nasty, thankless task that everyone wants done but no one ever volunteers to do, and do it yourself.