Schlagwort: projektmanagement

Dave Neary, langjähriges Mitglied der GNOME-Foundation und Maintainer von maemo.org, hat auf der MeeGo-Konferenz im November 2010 einen interessanten Vortrag zur Frage gehalten, wie eine Community scheitern kann. Er wählte dafür den Begiff »Anti-Patterns« (nach Christopher Alexander), also etwa »Muster destruktiven Verhaltens«. Viele (nicht alle) der aus der Software-Entwicklung gewonnenen Beobachtungen lassen sich auf andere commons-basierte Projekte übertragen.

Zu Beginn des Vortrags erklärt Dave den Begriff »Pattern« (»Muster«) mit einem Picasso-Zitat: »Good artists copy, great artists steal« (»Gute Künstler kopieren, großartige Künstler stehlen«). Wenn man ein Muster von etwas wirklich versteht, dann nimmt man es in sich auf (»stiehlt es«) und verwendet im eigenen, neuen Sinn weiter, anstatt das unverstandene Muster nur nachzuahmen (»zu kopieren«).

Der Witz ist nun: Nachahmung funktioniert in Communities nicht! Aus bloßer Nachahmung können stattdessen Anti-Patterns entstehen, die Dave Neary dann in 8 Punkten beschreibt — inklusive Vorschlägen (die sich v.a. an Maintainer richten), damit umzugehen.

(mehr …)

[There is an english version of this article]

Shit happens. Immer wieder. Wir machen Fehler, wir schaffen unsere eigenen Krisen in unseren Projekten. Frustration und Lern-Chance liegen dann eng beieinander. Die Frage ist nicht, wie wir Krisen vermeiden können, denn wir können nun mal nicht die Zukunft schauen. Die wichtigere Frage ist, wie wir mit Krisen umgehen, wenn sie denn mal da sind. Denn entweder unterscheidet sich ein commons-basiertes Peer-Projekt von proprietären Projekten gerade auch an dieser Stelle oder es hat eben doch keine andere Qualität.

Das ist deswegen so entscheidend, weil commons-basierte Peer-Projekte davon leben, dass sie möglichst die Beiträge aller beteiligten Menschen in das Projekt zu integrieren verstehen — anstatt per Exklusionskonkurrenz einen beträchtlichen Teil hinauszuselektieren, wie Martin zutreffend herausgearbeitet hat. Doch das »Ende von Selektion und Normierung« kommt nicht einfach nur deswegen, weil wir es so sehr wollen, sondern weil und nur wenn Peer-Projekte strukturell so angelegt sind, dass sie zur Integration und Konfliktlösung fähig sind.

Im Projekt »Factor E Farm« (FeF, auch »Open Source Ecology«, OSE) hat es jetzt geknallt. Öffentlich, das ist schon mal gut.

(mehr …)

[Es gibt eine deutsche Version dieses Textes]

Shit happens. Again and again. We make faults, we create our own crisis in our projects. Frustrations and chances of learning are close together. The question is not how to avoid crisis, because we can’t look into the future. The more important question is, how to deal with crisis once they are there. Either commons-based peer projects distinguish from proprietary projects especially at this point or there is no other quality.

This is so crucial, because commons-based peer projects live from the contributions of the participating people to be integrated into the project — instead of out-competing an enormous part of the people as Martin has well shown (german). But the »end of selection and normalization« does not only occur, because we wish it so much, but only because peer projekts are structurally designed in a way, that integration and conflict resolution is possible.

The project »Factor E Farm« (FeF, also »Open Source Ecology«, OSE) has crashed now. Publicly, which is good.

(mehr …)

Das, was wir in der Freien Software und anderswo im Freien Feld beobachten können, gibt es tendenziell auch in der proprietären Produktion. Sonst wäre es auch keine Keimform — die historische Tendenz zeigt sich überall. In der proprietären Produktion sind allerdings die Widersprüche anders gelagert. Während im Freien Feld die Frage vordringlich ist, wo die Leute Knete fürs Leben her bekommen können, um all die netten Sachen zu tun, die sie tun, ist im proprietären Feld diese Frage »geklärt«: Die Kohle ist da, gearbeitet werden muss. Entfremdung nennt man das. Aber auch unter entfremdeten Bedingungen können manchmal sinnvolle Dinge geschehen.

(mehr …)

This post finally concludes my coverage of the ox4 conference (part 1, part 2, part 3). On the third day, George Dafermos presented a case study of the FreeBSD project. 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.

(mehr …)

[Inofficial german translation of the englisch Call for Contribution]

Während der letzten Dekade ist das Phänomen Freier Software erfolgreich und weithin bekannt geworden. Es ist immer noch erstaunlich wie die Kreativität so vieler Freiwilliger im Bereich der Software zu Produkten führt, die für die ganze Menschheit nützlich sind. 1999 begann das Oekonux-Projekt dieses Phänomen zu untersuchen, um die besonderen Eigenschaften Freier Software als soziales und politisches Vorhaben zu verstehen.

Jenseits der Welt Freier Software entwickeln sich heute Projekte sehr schnell, die auf dem ähnlichen Anssatz der Peer-Produktion basieren, einschließlich Wikipedia und viele andere mehr. Es ist Zeit sich die Peer-Produktion in einer breiteren Perspektive anzuschauen.

(mehr …)

[Update 18.6.2009: Es gibt eine deutsche Übersetzung dieses Aufrufes]

During the past decade the phenomenon of Free Software has become successful and well-known. It is still amazing how in the realm of software the creativity of so many volunteers leads to products which are useful for the whole mankind. In 1999 the Oekonux Project started with analyzing this phenomenon and trying to understand the special features of Free Software as a social and political enterprise.

Today, beyond the Free Software world, projects based on a similar approach of peer production are rapidly emerging, including Wikipedia and many more. It is time to look at peer production from a broader perspective.

(mehr …)

I don’t know why Alan Cox is using »Town Council« instead of the good old term »Community«, but his lessons learnt from a project are interesting:

Release code right from the start. It doesn’t matter if its not very useful. (mehr …)

Während alle Welt interessiert, was uns Linus über die Kernel-Saison 2008 sagt, interessiert mich, was er sonst noch so sagt. Gefragt, ob die Linux- oder M$-Server-Entwicklung schneller laufe, antwortet er zunächst, dass er nichts darüber sagen könne, weil ihn der M$-Server einfach nicht interessiere, aber dann sagt er deutlich:

»Ich glaube schon, dass die Linux-Entwicklung tendenziell wesentlich effektiver ist als alternative Wege … als irgendein hinter-geschlossenen-Türen-kommerziell-proprietäres Modell«

(mehr …)

Obwohl schon eine Weile unter einer Creative Commons-Lizenz erhältlich, ist das Buch »Producing Open Source Software. How to Run a Successful Free Software Project« von Karl Fogel im deutschsprachigen Raum kaum rezensiert worden. Ok, das Buch wurde auf englisch verfasst, aber gleichzeitig ist es so interessant, dass es mehr Aufmerksamkeit verdient. Vielleicht erleichtert die folgende Besprechung ja den Einstieg. Übersetzungen stammen von mir.

(mehr …)