| 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] |
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] | |