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@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

_______________________________________________
FSFE-de mailing list
FSFE-de@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

Reply via email to