Hmmm... die Tatsache, dass bei OpenSource die Entwickler meist weit auseinander sitzen (manchmal rund um den Erdball), würde äußerst heftige Adaptionen von XP erfordern, oder nicht? MatthiasBohlen

Vielleicht stelle ich mir das zu einfach vor, aber das wären meine Gedanken:

Selbstverständlichkeiten GemeinsameVerantwortlichkeit gehört quasi zur "Definition" von OpenSource EinfachesDesign ist normalerweise gegeben KurzeReleaseZyklen ist normalerweise gegeben (wenn auch die Zeitachse bei freiwilligen Entwicklern nicht so gut kontrolliert werden kann) FortlaufendeIntegration ist normalerweise gegeben

In einem gut strukturierten OS Projekt vorhanden SystemMetapher sollte vorhanden sein (die einfache, verständliche Systemstruktur ist wegen der größeren Fluktuation in einem OS-Projekt noch wichtiger als in einem XP-Projekt) ProgrammierStandards sollte vorhanden sein KomponentenTests für die Integration eines Patches könnte die Absolvierung der vorhandenen Test-Suite obligatorisch sein. Ebenso könnte eine Regel vorschreiben, dass jede neue Funktionalität von entsprechenden Tests begleitet sein muss.

Sinngemäß zu adaptieren PlanungsSpiel nachdem jeder primär seine eigenen Anliegen realisiert, geht es hier vorwiegend um die Planung und Priorisierung von Entwicklungszielen, die noch keinen Entwickler gefunden haben. KundeVorOrt vielleicht ersetzbar durch OnlineCommunityKnowHow? (via Forum, Wiki). Außerdem gibt es das Problem "Projektverzögerung durch mangelnde Information" nicht. CodeRefactoring vermutlich vom zentralen Entwicklerteam im eigenen Interesse wahrzunehmen (ist aber auch bei XP offenbar eine Frage des individuellen Engagements)

Nicht unmittelbar anwendbar, aber kein Problem ProgrammierenInPaaren nicht anwendbar, aber auch nicht so notwendig, weil für die Lösung von Problemen, die Überprüfung des Code und die Diskussion ohnehin viele Augen und Gehirne zur Verfügung stehen. NachhaltigesTempo nicht notwendig, da ohnehin jeder Entwickler sein eigenes Tempo bestimmt (es gibt auch keine aufgezwungenen Termine und niemand im Projekt hat das Recht Arbeitsleistungen einzufordern)

Ist das zu naiv gedacht? Ich glaube natürlich nicht, dass das die Realität in OS Projekten ist. Aber es erscheint mir manches als Zielvorstellung möglich. Es gibt auch größere Überdeckungen mit den TippsFürOpenSourceProjekte.

für [...] die Überprüfung des Code [...] viele Augen und Gehirne zur Verfügung stehen : Nicht alle Projekte haben ReviewVorCommit Regeln.

Da praktische alle Entwickler die Projekte benutzen an denen sie arbeiten ist jedoch meist eine implizite Test'Nach'Commit Phase im Entwicklungszyklus eingebaut.

KomponentenTests: Einige große Projekte (zB die GnuCompilerCollection) haben Testframeworks. Allerdings ist das ein Bereich in dem noch großer Aufholbedarf vorhanden ist.

KundeVorOrt: Im allgemeinen sind die Entwickler ihre eigenen Kunden. Das führt jedoch zu Betriebsblindheit und Suppenschüsselhorizont-Denken. Das merkt man vor allem bei Projekten wie DebianGNULinux, die große Mengen Software auf "exotische" Architekturen portieren, wo haarsträubende Konstrukte auftauchen.

Siehe auch WardsWiki:CombiningOpenSourceAndXp