Of Communes, Contracts, & Codesets

Here’s a bit of personal trivia for all of you: I used to live in an intentional community (that’s the politically correct euphemism for a “commune”). Many times when I talk to people about Open Source software communities, I think about it in terms of living in community. There are numerous similarities, particularly in regards to the compensation scheme, membership requirements, and the organization of the work force.

In the community in which I lived, no one was paid for their work, instead, the work inured to the benefit of the community as a whole and you, as a member of that community, shared in the bounty. So, while the guys in the kitchen may not get a paycheck, they got reimbursed by the labor of the people who grew the food in the garden, or the labor of the dishwasher who cleaned up the kitchen, or the labor of the people working in the business that generated the money that kept the electric bills paid.

Division of labor resembled a modified meritocracy. That is, you were encouraged to contribute where your skills fit best, but you were not forced to do so. A great electrical engineer who wanted to tend the garden was welcome to do so, though the purest efficiencies might not be realized by that assignment. This is a trade-off that comes from maintaining the freedom of the individual and it is one of the things that is key to keeping the community members happy. Compensation was indirect, but in no way could it be said to lessen your obligation to work, as everyone had to do their part to keep the system functioning.

While you as an individual were not indispensable, you were tied into dependence on the community. If enough people laid down on the job, things would of course grind to a halt, but since everyone had a vested interest in the status quo, that generally did not happen. Critical matters were kept in check by peer pressure, necessity, and in a surprising number of situations, by simple pride in a job well done. Moreover, even though the compensation scheme was indirect, it could never be argued that the individuals were not employed by the Community. Clearly they were. The members worked for the Community, at the direction of, and at the tolerance of the Community, and they derived benefits from their association with the Community.

Membership in the community was voluntary, but not without condition. No one could force you to join or contribute, but if you showed up and simply took without giving, you would find yourself unwelcome before very long. For important or sensitive jobs, you needed to be nominated by more senior members of the Community; a new-comer wasn’t going to be given access to the checking accounts. Assets, like the labor that created them, were assigned to the Community. You may work in the community for 5 years, but that doesn’t mean you can drive off with one of the community’s automobiles when you decide to leave permanently. Similarly, open source developers may work long and hard on a project, or even a specific piece of code, but that doesn’t mean they can take it away and claim it as their own, denying others use of it.

Consistent with ownership, the care and tending of the community assets was governed by the community. While an individual may want to paint all the cars with tiger stripes, the individual was restricted from doing so as they don’t have the right to unilaterally make major decisions that affect the community’s assets. The right to make major modifications belongs only to the community, the owner of the asset. I would argue that a software developer, or even a group of developers, working on a code set doesn’t have the right to make major changes to the software infrastructure or fork the code set, without prior consultation and approval of the community. The right to make major modifications, or take the software in a radically new direction, should belong to the community, the owner of the asset.

The situation I have described, wherein mutual promises are given in exchange for value, would be what most would call a contract. It is not an express contract, but rather an implied one. The relationship between the member and the community is an agreement which exists based upon its circumstances. Moreover, repudiating the contract would be unfair and might even result in one of the parties being unjustly detrimented (or enriched).

It seems to me that there’s an implied contract in the open source world between developers and their community. The contract includes an obligation for the developers to be responsive to the needs of the community and to work on behalf of the community’s best interest. One of the corollaries of this would be that the software is an asset of the community and critical decisions relating to that asset must be made with prior consultation of that community. A large open source community will involve members, users, and clients who have expended much time, effort, and in some cases money, in promoting the community and its asset. Those same individuals have relied on the developers to act responsibly and to maintain good faith and fair dealings. Developers need to recognize that being a member of an open source community is not a one way street and that membership includes obligations. The community and its assets are not the developers’ to do with as they please.

Originally published in the Bangkok Post 1 September 2005

Leave a Reply

Your email address will not be published. Required fields are marked *