Manchmal ist es Notwendig ein Projekt zu Forken um es wieder zum laufen zu bekommen und den Truck Faktor zu minimieren.
Siehe z.B. den Machinekit Fork von LinuxCNC
Ein weiteres negativ Truck-Faktor Beispiel ist die 3D Druck CAM Software Slic3r -> wird genau von einem Entwickler entwickelt und 3rd-Party Patches werden nur selten gemerged.
Da fehlt nur eine ganz entscheidende Grösse in dem verwendeten Algorithmus: Zeit.
Wurde ein Projekt von jemanden vor 5 Jahren begonnen hat der wahrscheinlich den Löwenanteil des initialen Codes geschrieben. Wenn das nun 50% sind und danach diverse andere übernommen haben, sich um das Beheben von Fehlern gekümmert habe während der Ursprungsentwickler das Projekt verlassen hat, dann fallen die anderen einfach unter den Tisch und übrig bleibt Busfaktor 1. Übrig bleibt gar die Person die nicht mehr bei dem Projekt ist womit, nach dem Algorithmus wenn man einen Schritt weiter geht, das Projekt tot ist.
Was man eigentlich machen müsste ist auch die Beiträge bzw. Beitragsentwicklung über die Zeit zu ermitteln womit sich zumindest eine Tendenz ableiten lässt. Die müsste dann in die Berechnung einfliessen.
Ich halte es auch für ziemlich fragwürdig die Berechnung auf einzelnen Dateien anzuwenden. Nicht alle Dateien werden gleichoft angefasst oder haben das gleiche Gewicht in einem Projekte. Wenn also jemand vor langer Zeit mal ein Plugin geschrieben hat das seitdem keiner mehr angefasst hat zählt das mehr als wenn jemand im ore immer wieder Bugs fixt?
Etwas mehr Sinn würde eine Gewichtung machen, ggf. nkcht auf Dateien sondern Verzeichnissen. Dabei ist mit höchster Wahrscheinlich über einen längeren Zeitraum bzw. zuletzt angefasster Code wichtiger als ein einziger Commit mit einem riesen Codedrop der am Anfang landete.
Ganz im speziellen vermute ich das Projekte die 3rd-party libs committen durch den Algorithmus automatisch einen Busfaktor von 1 bekommen.
Viele Zweifel bleiben. Trotzdem toll das jemand was in die Richfung macht. Weiter so!
Ja, die Berechnungsmethode finde auch ich eher fragwürdig.
Ein in meinen Augen viel interessanteres und schon etwas älteres Projekt hatte ich vor einiger Zeit auf André Klappers Blog für Gnome Programme gefunden. Anhand einer von André veröffentlichten Arbeit konnte an anderer Stelle eine Tabelle generiert werden, die die Aktivität von Gnome-Projekten aufzeigt: Je höher der Score, desto niedriger die Aktivität. Die Liste ist zwar nicht vollständig, aber ich finde, sie ist ein guter Ansatzpunkt dafür, um kränkelnde/tote Projekte ausfindig zu machen. Die Grundlage dieser Liste findet man in dieser pdf.
Manchmal ist es Notwendig ein Projekt zu Forken um es wieder zum laufen zu bekommen und den Truck Faktor zu minimieren.
Siehe z.B. den Machinekit Fork von LinuxCNC
Ein weiteres negativ Truck-Faktor Beispiel ist die 3D Druck CAM Software Slic3r -> wird genau von einem Entwickler entwickelt und 3rd-Party Patches werden nur selten gemerged.
Das erinnert jetzt ganz stark an VIM.
... sind schein Webbrogramming Projekte, wo einfach niemand als der Autor selbst das gut findet.
Im Artikel ist zumindest erwähnt, die Studie basiere auf "133 populären Projekten".
Es gibt das ganze auch in Deutsch und nennt sich Ziegelsteintheorie.
"Was wenn jemanden ein Ziegelstein auf den Kopf fällt".
Da fehlt nur eine ganz entscheidende Grösse in dem verwendeten Algorithmus: Zeit.
Wurde ein Projekt von jemanden vor 5 Jahren begonnen hat der wahrscheinlich den Löwenanteil des initialen Codes geschrieben. Wenn das nun 50% sind und danach diverse andere übernommen haben, sich um das Beheben von Fehlern gekümmert habe während der Ursprungsentwickler das Projekt verlassen hat, dann fallen die anderen einfach unter den Tisch und übrig bleibt Busfaktor 1. Übrig bleibt gar die Person die nicht mehr bei dem Projekt ist womit, nach dem Algorithmus wenn man einen Schritt weiter geht, das Projekt tot ist.
Was man eigentlich machen müsste ist auch die Beiträge bzw. Beitragsentwicklung über die Zeit zu ermitteln womit sich zumindest eine Tendenz ableiten lässt. Die müsste dann in die Berechnung einfliessen.
Ich halte es auch für ziemlich fragwürdig die Berechnung auf einzelnen Dateien anzuwenden. Nicht alle Dateien werden gleichoft angefasst oder haben das gleiche Gewicht in einem Projekte. Wenn also jemand vor langer Zeit mal ein Plugin geschrieben hat das seitdem keiner mehr angefasst hat zählt das mehr als wenn jemand im ore immer wieder Bugs fixt?
Etwas mehr Sinn würde eine Gewichtung machen, ggf. nkcht auf Dateien sondern Verzeichnissen. Dabei ist mit höchster Wahrscheinlich über einen längeren Zeitraum bzw. zuletzt angefasster Code wichtiger als ein einziger Commit mit einem riesen Codedrop der am Anfang landete.
Ganz im speziellen vermute ich das Projekte die 3rd-party libs committen durch den Algorithmus automatisch einen Busfaktor von 1 bekommen.
Viele Zweifel bleiben. Trotzdem toll das jemand was in die Richfung macht. Weiter so!
Ja, die Berechnungsmethode finde auch ich eher fragwürdig.
Ein in meinen Augen viel interessanteres und schon etwas älteres Projekt hatte ich vor einiger Zeit auf André Klappers Blog für Gnome Programme gefunden. Anhand einer von André veröffentlichten Arbeit konnte an anderer Stelle eine Tabelle generiert werden, die die Aktivität von Gnome-Projekten aufzeigt: Je höher der Score, desto niedriger die Aktivität. Die Liste ist zwar nicht vollständig, aber ich finde, sie ist ein guter Ansatzpunkt dafür, um kränkelnde/tote Projekte ausfindig zu machen. Die Grundlage dieser Liste findet man in dieser pdf.