Re: Zentral oder dezentral Code-Hosten (war: Ein Ort für Code)

[Ilu]

Hallo Bernhard,

ich glaube unsere unterschiedliche Sichtweise kommt aus unserer 
unterschiedlichen Interessenlage. Ich habe zuletzt ein Projekt betreut, 
wo Student:innen und andere Amateure mit Hilfe von git 
zusammengearbeitet haben. Keiner von denen hätte jemals für die Nutzung 
der Plattform gezahlt, das wäre auch nicht angemessen gewesen. Und einen 
Account beantragen mit Studi-Ausweis - nee. Wir haben letztlich ein 
privates gitlab benutzt, aber ideal war das nicht, denn nach dem Ende 
des Projektes müssen die Teilnehmer:innen da wieder raus. Wo werden sie 
hingehen? Zu Github.

Ich zahle meinen Vereinsbeitrag für mein git, zwei Städte weiter zahlen 
andere für ihrs usw. - sinnvoll ist es nicht, denn die hängen alle 
isoliert in der Gegend und wenn man sehen will, ob ein git den Fix für 
ein Problem hat, muss man manuell eine Plattform nach der anderen 
abklappern. Oder rumfragen. Idiotisch.

Wenn ich gitlab/hub.com nutze, dann möchte ich schnell und einfach einen 
Überblick über eine Software und alle ihre Forks haben - das geht nur 
solange die Forks auf derselben Plattform sind, ansonsten finde ich die 
nicht. Praktisch lande ich immer auf github.com, selten auf gitlab.com, 
und niemals woanders.

Alle Uni-gitlabs sind Inseln, auf denen Code vor sich hinrottet, den 
niemals jemand zu Gesicht bekommt. Das müsste alles zusammen-federiert 
werden, die staatliche Plattform dazu und unsere hackspace-gitlabs 
würden wir auch dranhängen. Heptapod kann ja mitmachen oder auch nicht.

Viele Grüße
Ilu

Am 16.07.21 um 10:13 schrieb Bernhard E. Reiter:
> Hi Ilu,
> 
> Am Freitag 16 Juli 2021 00:25:35 schrieb Ilu:
>> Ohne Federation macht jeder zusätzliche Dienstanbieter die Sache nicht
>> besser, sondern schlechter.
> 
> da bin ich anderer Ansicht, vor Allem, wenn es ein Dienstanbieter ist,
> der komplett mit einem Freie Software-Produkt läuft.
> (Was bei github, bitbucket und gitlab __nicht__ der Fall ist.)
> 
> Beruflich und persönlich habe nutze ich viele Repos und Dienstanbieter,
> auch selbstgehostete. Das geht problemlos, ja die enge Interaktion hat
> manchmal Vorteile, manchmal aber auch Nachteile. Im Wege steht sie selten,
> ein Beispiel: Viele schnell gemacht Clones haben einen niedrigen Wert.
> 
> (Und ja, in eine Freie Software-Lösung liesse sich das Feature "Export"
> einbauen, ein (neo)-proprietärere Anbieter wie die genannten hat daran kein
> Interesse.)
> 
>> Ein Dienst, bei dem Nutzer zahlen müssen, hat keinerlei Chancen. Dann
>> geht doch jeder gern zu amerikanischen Konkurrenz
> 
> Wer nicht versteht, wie die Kostens des Dienstes bezahlt werden,
> der ist schnell Ware und nicht Kunde. Weiterehin führt ein kostenloses Angebot
> von Dingen die Geld kosten zur Verschwendung. Das ist der Grund, warum die
> proprietären US-Anbieter so groß sind, das scheintbar kostenlose Angebot ist
> ein Lockangebot für ein Freemium-Modell, sie sammeln User, Daten und
> Mindshare. Und schubsen in Richtung bezahlte Dienste.
> 
> Die Kosten dürfen niedrig sein, aber sie sollten da sein.
> 
> Die proprietätren Anbieter konnten die bisherigen Plattformen nur so stark
> ausbauen, weil sie viel Geld mit dem Hosting proprietärer
> Software-Komponenten verdienen. Und so die Software-Entwicklung ihrer
> Plattform finanzieren. Dort zu sein, bedeutet dieses proprietäre Geschäft
> und SW-Entwicklung zu unterstützen.
> 
>> oder hostet eben
>> selbst. Selbsthosten wäre ja ok, wenn es denn Federation  gäbe ...
> 
> Für viele Organisation ist Selbsthosten keine Option und zu teuer.
> 
>> Den Verweis auf https://heptapod.net/ verstehe ich nicht, denn das ist
>> einfach eine weitere einsame gitlab Instanz.
> 
> Das Angebot bei Heptapod hat mehrere Vorteile:
>    * Es läuft Freie Software (anders als gitlab.com)
>    * Es gibt Vielfalt und Wettbewerb beim SCM (hg und git)
>    * Es wird in der EU gehostet
>    * Es ist kaufbar (damit gibt es einen klaren Vertrag, was geht, kein
> willkürliches Abschalten von Inhalten oder Nutzenden)
> 
>> Soweit ich sehe, wird  lediglich hg support hinzugefügt,
>> was aber für die Masse der git Nutzer  ziemlich unerheblich ist.
> 
> git ist nur so gut, weil es Konkurrenzprodukte gibt.
> Wer weitere Verbesserungen möchte, der muss auch Konkurrenz fördern.
> (hg ist git in einige Bereichen weiterhin überlegen, die Vielfalt hier ist
> meiner Ansicht nach gut, aber das ist hier nicht der Hauptpunkt.)
> 
> Danke auch an Michael, Henning und Paul für Eure Diskussionsbeiträge.
> 
> Viele Grüße,
> Bernhard
> 
> 
> _______________________________________________
> FSFE-de mailing list
> FSFE-de at lists.fsfe.org
> https://lists.fsfe.org/mailman/listinfo/fsfe-de
> 
> Diese Mailingliste wird durch den Verhaltenskodex der FSFE abgedeckt.
> Alle Teilnehmer werden gebeten, sich gegenseitig vorbildlich zu
> behandeln: https://fsfe.org/about/codeofconduct
>