Constitutionalizing an Open Source Project and Possible Outcomes
April 28th, 2008 | by Ozgur Cem Sen |I recently started writing this article study about Free Open Source Projects and their ways; internally and externally.
My initial goal was to analyze the internal and external dynamics of a FOSS project, especially constitutionalizing the internals, the identify the issues being faced, possible recommendations, outcomes and such.
Now, I am wiping what I’ve done so far, and opening this into a collaborative article. Feel free to add your opinions in the comments section. Once it’s ready to become an actual article/case study, I will contact the posters individually asking for their blessing about adding their pieces in the finalized paper.
Thanks in advance for your input.
5 Responses to “Constitutionalizing an Open Source Project and Possible Outcomes”
By Ozgur Cem Sen on Apr 28, 2008 | Reply
I’ll do the “comment kick-off”.
See it this way. Open Source, and hacker culture, goes hand in hand right ?
Can you put a hacker in a box? (I don’t mean a dark room with enough computing power)
By Al Warren on Apr 29, 2008 | Reply
Can a hacker be boxed? Within reason. As long as the box provides a safe haven free from distraction. And it must be flexible enough to allow creativity to flow free of any restrictions.
Let us consider that box in the context of a constitution created within the scope of a FOSS project. That constitution is traditionally formed to protect the IP of the project. But if it is poorly written or poorly implemented it becomes poison to the creative process. It might not be the constitution itself that poisons the process. It might actually be those who create or implement that constitution. It is in fact people who become that poison.
“Attention and focus are your scarce resources and you need to protect them”. Poisonous people tend to distract communities and scatter the attention and focus of the people who should continue developing new features or fixing bugs. Communities must avoid deadlock by not letting people derail forward progress. For instance, people in the community can ask endless questions or focus on perfection (in a design or feature set) and bogart the attention of developers.[1]
The premise is that within a FOSS project these “poisonous people” are the trouble makers of the community. But there might also be well intentioned contributing members who unknowingly become poison to the project. This can happen when a constitution is brought into a FOSS community with the intent of protecting the IP of the software. Within that constitution is a hierarchy of control such as a board of directors. If the constitution is poorly written or implemented, that control, which was originally written to protect the IP, can easily spill over into the creative process. That may not be a bad thing “if” that control is assumed by the hacker. But it can be the death knell of a project if control is relinquished to someone with neither the skills, knowledge, or experience necessary to produce quality code.
Let’s take the hacker moniker and apply it to a FOSS developer. The term developer is often misinterpreted as someone, anyone actually, who develops a product. But in a FOSS project, that term is usually reserved for the programmers who write the code. Programmers are a creative bunch. Much like an artist, they are free and open thinkers constantly analyzing their environment and thinking of ways to best structure the inner workings of the product. They are detail oriented logical thinkers who spend hours upon hours staring at line after line of code. It is an intense process that requires focus and unmitigated attention.
What happens in some FOSS projects is that a community member will gain control of the organization. That member is not a developer but rather an end user with the best intentions of the project in mind. But, because they are neither skilled nor knowledgeable in the art of creating software, they become a distraction rather than an asset.
Consider our canine friends. They have a social structure – the pack. They have a dominant leader. That leader controls the pack with calm assertiveness. But assertiveness is never a guarantee that the pack will respect that pack leader. Subordinate members of the pack are always on the lookout for weaknesses. The moment a member of the pack senses weakness it attacks. This is not out of anger or frustration. Packs don’t act on emotion. They act on instinct. And it is that instinct that insures their very survival.
Now contrast that with a group of developers within a FOSS project. You have a social structure. You have a dominant leader. As long as that developer rules with calm assertiveness everyone should be happy. So what happens when an end user takes control of the group? If that end user lacks programming skills the “pack” sees that as a sign of weakness. A subordinate developer begins to challenge that leadership and things quickly escalate to dominant aggression instead of calm assertiveness. This is an instinctive response focused on survival. That response is based entirely on preserving the integrity of the code.
There is a distinct difference between our pack of developers and a pack of canines. A pack of canines will simply replace their leader with a new dominant member. In the case of a pack of developers, if it becomes apparent that replacement of the leader is not an option, they will simply break off into a new pack. They have effectively broken out of the box. They create a new social structure free of distractions. They regain focus and attention in order to do what they do best – write code.
Can a hacker be boxed? As long as that box is secure. And as long as he/she can control the construction of the box.
1. Robert Kaye commenting on an OSCON presentation by Ben Collins-Sussman and Brian Fitzpatrick. See
http://www.oreillynet.com/conferences/blog/2006/07/oscon_how_open_source_projects.html
By Ozgur Cem Sen on Apr 30, 2008 | Reply
There is also the unavoidable adverse effects on the institution imposing a constitution on the project itself.
Usually the institution is formed around to project to protect it. At some point the protection becomes so heavy and suppressing; making it impossible to move forward. I like to quote it like “the institution protects the current code so well, even the insiders cannot touch it”
One very obvious outcomes of such occasions is that, the key developers start leaving the project, and start looking for other ways to save the project in turmoil.
*more to come.
By Daniel on Apr 30, 2008 | Reply
The effectiveness of a constitution also depends a lot on the motives of the group involved, and what they are used to.
A “suppressing and heavy” constitution may only seem that way to people who operated on the project under a looser set of guidelines. If you were introduced to it from the start, or expected it to be that way, would it be heavy and suppressing or just the way things are?
On motives: if the primary motivator is a financial reward, or an enjoyment reward also makes a big difference. People will tolerate a lot more pressure and hardship if they can justify a financial reward for it. But will tolerate a lot less if they are working volunteer for the fun of the project.
Trying for example to impose corporate project style pressure on a volunteer project runs the risk of alienating the team, who may want the work to relieve themselves of their corporate day jobs.
Conversely though, the right level of systems being in place can ease the burden of development and make the project much more enjoyable, cleaner and development progresses faster.
I have been working with my own team on putting beneficial systems, rather than protective, restrictive systems. Any system or rules that provide no benefit, but detract from the projects or the enjoyment of the staff, get removed.
By Ozgur Cem Sen on May 26, 2008 | Reply
Maybe I should’ve added “Attorney-alizing” to this post’s title.
More details to follow on that “attorney” stuff. I am posting this comment here, so I won’t forget about it.