Politisch führt da natürlich kein Weg dran vorbei. Und die Opfer (also die Leute, die es dann praktisch benutzen müssen) interessieren in der Politik eh keinen.
Soweit ich einen Blick auf git geworfen hab, entspricht das genau dem Chaoshaufen, der Linux ist und schon immer war - was der entscheidende Grund war, dass ich Linux 1995 in die Tonne gehauen hab.
Der Auslöser war damals das ping Kommando, und es ging darum, ein paar DSL Links auf Funktion zu überwachen. Wie man der FreeBSD manpage entnehmen kann, hat ping zwei verschiedene Returnwerte: 1 bedeutet, es funzt nicht. 2 bedeutet, Gegenstelle antwortet nicht.
Bei Linux war das anders: dort fand man es lustig, diese Werte zum Jonglieren zu nehmen. Genauer gesagt: im Quellcode unter /usr/src waren sie genau umgekehrt verwendet als im ausführbaren Binary.
Nun möchte ich aber, wenn ich das Verhalten einer Software nicht verstehe, genau unter /usr/src nachlesen, was diese Software tut. Und mehr noch, wenn mir das Verhalten nicht gefällt, möchte ich unter /usr/src das entsprechende Bit ändern, "make install" sagen, und fertig - und jedenfalls nicht erst eine Forschungsreise antreten dahingehend, wo vielleicht irgendwie der tatsächlich korrekte Code aufzutreiben sein könnte.
Und das ist exemplarisch. Nicht nur ist Linux ein zusammenkopiertes Sammelsurium von allem möglichen Utilities von irgendwoher ohne eine autoritative Linie oder gar eine konsistente Versionsverwaltung darin, sondern das, was man dann kredenzt kriegt, ist sogar in sich selber nicht schlüssig, d.h. praktisch nicht brauchbar.
Und git ist dann -später- just zu dem Zweck entwickelt worden, um genau eine solche Arbeitsweise, nämlich einen Chaoshaufen, zu unterstützen. Die Diskussion war natürlich politisch, die Schlagworte waren "the cathedral and the bazaar" - man hat die herkömmliche kommerzielle, streng reglementierte Softwareentwicklung mit der linux-typischen Arbeitsweise des Chaoshaufens verglichen, und ist auf dasselbe gekommen, was dann später auch die Agile-Fans verbreitet haben: dass die klassische Software-Entwicklung zu unflexibel und zu wenig innovativ ist.
Aber wie ein Bazaar funktioniert, weiß auch jeder, der schon mal in Asien war: entweder man hat da Verwandte. oder man wird übers Ohr gehauen.
Dass FreeBSD damals schon das beste aus beiden Welten kombiniert hatte, und, vor allem, wunschgemäß funktioniert hat und nutzbar war, ist natürlich niemandem aufgefallen. Aber das hatten wir ja alles auch schon vorher: wenn sich jemand mal wirklich hinsetzt und was taugliches macht, dann geht das unter und wird "vom Markt verdrängt"; siehe Video2000 und viele ähnliche Beispiele. Und nach hundert Nachbesserungen und Flickschustereien kriegt man dann das Nötige doch irgendwann mal getan, und vor allem: Leute haben derweil eine Beschäftigung.
Kann man natürlich so machen. Muss man aber nicht.
Genau - eine rein sozialpolitische Bewertung unter Ausklammerung der fachlichen Aspekte und Verzicht auf Technikfolgenbewertung.
Ein Problem ist, dass schon der Begriff "konservativ" heute negativ besetzt ist - auch das ist freilich eine rein sozialpolitische Bewertung ohne technisch-fachlichen Bezug.
Und das andere Problem ist schlicht das, dass man es sich leisten kann: man hat nicht mehr die Hände voll damit zu tun, dass etwas überhaupt mal zum Funktionieren gebracht wird, sondern kann sich sozialpolitische Eskapaden leisten. Man ist dekadent.
Muß man das? Liegt darin irgendein Wert-an-sich?
Wie wäre es, stattdessen technisch-fachliche Bewertungen vorzunehmen? Aber ja, das wäre dann das, was man früher mal "deutsche Ingenieurarbeit" nannte - und das will man ja auch nicht mehr (außer im Ausland).
Soweit ich einen Blick auf git geworfen hab, entspricht das genau dem Chaoshaufen, der Linux ist und schon immer war - was der entscheidende Grund war, dass ich Linux 1995 in die Tonne gehauen hab.
Der Auslöser war damals das ping Kommando, und es ging darum, ein paar DSL Links auf Funktion zu überwachen. Wie man der FreeBSD manpage entnehmen kann, hat ping zwei verschiedene Returnwerte: 1 bedeutet, es funzt nicht. 2 bedeutet, Gegenstelle antwortet nicht.
Bei Linux war das anders: dort fand man es lustig, diese Werte zum Jonglieren zu nehmen. Genauer gesagt: im Quellcode unter /usr/src waren sie genau umgekehrt verwendet als im ausführbaren Binary.
Nun möchte ich aber, wenn ich das Verhalten einer Software nicht verstehe, genau unter /usr/src nachlesen, was diese Software tut. Und mehr noch, wenn mir das Verhalten nicht gefällt, möchte ich unter /usr/src das entsprechende Bit ändern, "make install" sagen, und fertig - und jedenfalls nicht erst eine Forschungsreise antreten dahingehend, wo vielleicht irgendwie der tatsächlich korrekte Code aufzutreiben sein könnte.
Und das ist exemplarisch. Nicht nur ist Linux ein zusammenkopiertes Sammelsurium von allem möglichen Utilities von irgendwoher ohne eine autoritative Linie oder gar eine konsistente Versionsverwaltung darin, sondern das, was man dann kredenzt kriegt, ist sogar in sich selber nicht schlüssig, d.h. praktisch nicht brauchbar.
Und git ist dann -später- just zu dem Zweck entwickelt worden, um genau eine solche Arbeitsweise, nämlich einen Chaoshaufen, zu unterstützen. Die Diskussion war natürlich politisch, die Schlagworte waren "the cathedral and the bazaar" - man hat die herkömmliche kommerzielle, streng reglementierte Softwareentwicklung mit der linux-typischen Arbeitsweise des Chaoshaufens verglichen, und ist auf dasselbe gekommen, was dann später auch die Agile-Fans verbreitet haben: dass die klassische Software-Entwicklung zu unflexibel und zu wenig innovativ ist.
Aber wie ein Bazaar funktioniert, weiß auch jeder, der schon mal in Asien war: entweder man hat da Verwandte. oder man wird übers Ohr gehauen.
Dass FreeBSD damals schon das beste aus beiden Welten kombiniert hatte, und, vor allem, wunschgemäß funktioniert hat und nutzbar war, ist natürlich niemandem aufgefallen. Aber das hatten wir ja alles auch schon vorher: wenn sich jemand mal wirklich hinsetzt und was taugliches macht, dann geht das unter und wird "vom Markt verdrängt"; siehe Video2000 und viele ähnliche Beispiele. Und nach hundert Nachbesserungen und Flickschustereien kriegt man dann das Nötige doch irgendwann mal getan, und vor allem: Leute haben derweil eine Beschäftigung.
Kann man natürlich so machen. Muss man aber nicht.
Trotzdem danke ich aus dem Bauch heraus, dass eine Migration von svn zu git zwar zu Diskussionen und Gemotze führt, aber doch durchsetzbar ist.
Genau - eine rein sozialpolitische Bewertung unter Ausklammerung der fachlichen Aspekte und Verzicht auf Technikfolgenbewertung.
Ich meinte mehr die Community außen herum. Auch die ist bei weiten nicht so erzkonservativ, wie man auf den Blick meint, aber es gibt eine kleine und sehr Laute Gruppe, die scheinbar schon aus Prinzip jede größere Änderung ablehnt. Es ist zumindest auf den Mailinglisten auffällig, dass in jeder Diskussion immer die gleichen Namen "dagegen" sind.
Ein Problem ist, dass schon der Begriff "konservativ" heute negativ besetzt ist - auch das ist freilich eine rein sozialpolitische Bewertung ohne technisch-fachlichen Bezug.
Und das andere Problem ist schlicht das, dass man es sich leisten kann: man hat nicht mehr die Hände voll damit zu tun, dass etwas überhaupt mal zum Funktionieren gebracht wird, sondern kann sich sozialpolitische Eskapaden leisten. Man ist dekadent.
Nun ist es in meinen Augen so, dass die Frage zwischen Fortschritt und Beibehaltung des Bestehenden bei Software immer eine Gradwanderung ist. Auf der einen Seite möchte man keinen Fortschritt des Fortschritts willens, vor allem nicht in einem per Design eher konservativen System wie FreeBSD. Sonst wären wie nicht FreeBSD sondern Linux oder Windows, was im Moment jedes halbe Jahr größere nutzersichtbare Änderungen einbringt. Aber auf der anderen Seite muss man auch mit der Zeit gehen.
Muß man das? Liegt darin irgendein Wert-an-sich?
Wie wäre es, stattdessen technisch-fachliche Bewertungen vorzunehmen? Aber ja, das wäre dann das, was man früher mal "deutsche Ingenieurarbeit" nannte - und das will man ja auch nicht mehr (außer im Ausland).