Message 06078 [Homepage] [Navigation]
Thread: oxenT05739 Message: 2/2 L1 [In index]
[First in Thread] [Last in Thread] [Date Next] [Date Prev]
[Next in Thread] [Prev in Thread] [Next Thread] [Prev Thread]

Mission critical decisions in peer projects (was: [ox-en] keimform.de: ox4 Notes IV: Case Study of a Large Free Software Project)



Hi George, Christian, all!

There was this older post lying around I wanted to reply to at some point.

I quote more than usual to keep the context.

15 months (452 days) ago Christian Siefkes wrote:
On
the third day, *George Dafermos* presented a case study of the FreeBSD
project <http://fourth.oekonux-conference.org/program/events/35.en.html>.
He talked mainly about how the project is structured and how division of
labor emerges.

The *core team* comprises 9 people which are elected by the *committers*
and who, in turn, decide who gets commit rights). There are about 250
*committers* (who have the right to commit code to the code base) and about
5500 *contributors* (who have to filter their contributions through one of
the committers). This confirms the 1-9-90 rule of thumb: less than 1% of
participants steer the project (the core team), less than 10% contribute
regularly (the committers), the rest contributes occasionally (the
contributors). Officially, the core team also has the task to resolve
conflicts, but there are very few conflicts, and usually the involved
people resolve them by themselves.

People become committers through a mentoring process: If you submit
sufficiently many good patches, some committer will propose that you get
commit rights; if the core team accepts her proposition, she will usually
become your mentor, responding to your questions etc. and easying your
transition to your new position (but you already have full commit rights).
Usually new committers work about one year closely with their mentor, after
that they are sufficiently initiated to know how things go.

There are various teams caring for specific tasks: collecting donations,
documentation, security, marketing, release engineering, port (application)
management etc. People *self-select* for participation in some team and are
accepted by the core team; of course, the core team doesn't have any
commanding power over them.

The division of labor is emergent: not dictated by the top, but based on
the self-selection of people. People start at the periphery of the project
(reporting bugs, submitting small patches etc.); if they're interested in
the project, they will move closer and closer to the core.

For the development process, their are guidelines (recommendations), but no
strict rules. Usually developers test their code locally and ask the
community for review; after feedback and test, it is submitted to the
current (experimental) branch. After thorough evaluation, code from the
experimental branch is merged into the stable branch; every 3 to 6 months,
development of the stable branch is interrupted (only bug fixes are
allowed)--a "code slush" or "code freeze" occurs. After fixing bugs and
problems, a production release (meant for end users) is produced from the
stable branch. The release engineering team are strict "dictators"
supervising this process.

I think it's interesting that the one team which exercises strict,
"dictatorial" power isn't the core team, but the release engineering team,
one of the several task-specific teams surrounding the core. Clearly, the
quality of production releases is very important for the reputation and
success of a project, so the decisions of the release team are generally
respected even thought they aren't formally at the "top of the hierarchy."

This reads to me like the release task is mission critical *and* time
critical. Well, from my professional life I *know* this is the case ;-) .

What strikes me that in a mission critical *and* time critical task
the emerged regulations seem to be different. Well, intuitively I can
understand this very well. These are situations where you need a
decision quickly and it is useful for the whole project if the
decision is obeyed by everyone. Simply because you don't have the time
to let other decisions emerge.

That is also a situation where you really need experts. I.e. people
who are experienced and bright enough to make good decisions quickly.

When thinking about this what also strikes me is that peer production
projects have a strong tendency to avoid such situations - at least
compared to projects driven by alienation. AFAICS for the average Free
Software project you hardly have timelines for releases for instances.
Rather you create a new release when you have finished some big new
functionality or there are just enough smaller changes for a new
release. And in addition for a Free Software project it usually simply
makes no sense to set a release date - what should it be good for?
That is the "It's ready when it's ready" mantra.

On the other hand in the alienated part of my life I often saw
projects where nothing was clear but the release date. Ever heard of
"time to market"?

Distributions like FreeBSD or Ubuntu or even the Linux kernel - which
by its nature in some ways is similar to a distribution - is somewhat
different because you don't have clear factual reasons to create a new
release like new or improved functionality. After all a distribution
is a compilation of lots and lots of software and there is usually no
single part which justifies a new release. In such cases a time based
scheme is probably helpful to keep things moving.

I wonder what these tendencies mean for traditional considerations
about decision making. I know these tendencies from my anarchist
experiences already. In an (ideologically driven) consensus oriented
culture you also have the tendency to avoid time critical situations.
The funny things is that some anarchist thinking revolves about
protest, revolt and revolution and these are situations where timely
action is extremely necessary. I remember that the recommendations for
such situations even broke ideological barriers...

On the other hand mission in peer production projects critical
decisions which are not time critical are usually dealt with in a very
open way - the way we usually think of decision making in peer
production projects.

I wonder whether many problems in the world can be approached in such
a way that structural problems like time and mission critical tasks
are avoided. From my anarchist time I have a firm belief that this is
possible in many, many occasions. Looking at peer production it seems
to me that this is something which emerges if people are allowed to
collaborate in an unalienated way.


						Grüße

						Stefan


Thread: oxenT05739 Message: 2/2 L1 [In index]
Message 06078 [Homepage] [Navigation]