Hallo alle,
im Dritten Nationalen Aktionsplan im Rahmen der Teilnahme an der Open Government Partnership gibt es einen Punkt zum Aufbau einer "Open Source-Plattform der öffentlichen Verwaltung" [1] der sich stark an unserem Konzept "Ein Ort für öffentlichen Code" [2] orientiert und auch darauf verweist. Damit haben wir das Projekt nun nach dem Start der Pilotphase [3] auch erstmals für ganz Deutschland vertraglich fixiert.
Bis März 2023 soll eine, nicht nur für die Verwaltung geöffnete, Code-Plattform zur Verfügung stehen, die fortlaufend weiterentwickelt werden soll. Auf Seite 43ff könnt ihr den ganzen Plan lesen. [4]
Liebe Grüße
Alex
[1] https://www.open-government-deutschland.de/opengov-de/dritter-nationaler-akt... [2] https://fsfe.org/news/2020/news-20200910-01.de.html [3] https://www.land.nrw/de/pressemitteilung/land-startet-pilotprojekt-fuer-open... [4] https://www.open-government-deutschland.de/resource/blob/1567548/1936828/600...
Moin,
Am Donnerstag 01 Juli 2021 09:19:41 schrieb Alexander Sander:
Bis März 2023 soll eine, nicht nur für die Verwaltung geöffnete, Code-Plattform zur Verfügung stehen, die fortlaufend weiterentwickelt werden soll. Auf Seite 43ff könnt ihr den ganzen Plan lesen.
meiner Ansicht nach, werden sich die Erwartungen an diesen "Ort für öffentlich Code" _nicht_ erfüllen. Die Leute suchen eigentlich nicht nach Code, sondern nach Zusicherungen über diesen Code, am besten für ihren eigenen Einsatzzeck und im Zusammenhang dessen, was ingesamt verfügbar und möglich ist. Ein "Ort" allein und auch die Vernetzung unter Leuten mit (angenommen) ähnlichen Interessen, kann das nicht leisten.
Viele Grüße, Bernhard
Hallo Liste,
aus Erfahrungen in meinem Bundesland kann ich sagen, dass die Verwaltung bedauerlicherweise merkwürdige Vorstellungen von "Kooperation" hat: nur Verwaltungsmitarbeiter:innen erhalten Accounts, damit entfällt auch die Möglichkeit von Bug-Meldungen durch Bürger. Im Meilenstein steht zwar "Öffnung der OS-Plattform für weitere Nutzergruppen außerhalb der öffentlichen Verwaltung (vorbehaltlich der rechtlichen Prüfung)" aber die rechtliche Prüfung wird vermutlich dann das Problem sein ... Bürger könnten ja auf die Idee kommen, dort (urheber)rechtsverletzende Dinge zu lagern ...
Dabei wäre ein europäisches Git(lab) als Alternative zu gitlab/github.com dringend erforderlich. Naja, ein deutsches System reicht dafür sowieso nicht, es müsste schon europaweit sein.
Bernhards Einwand verstehe ich nicht: Es wird ziemlich sicher ein gitlab werden. Was für Erwartungen an ein git sollte ein git nicht erfüllen? Und wer sollte auf die Idee kommen, in einem git "Zusicherungen" zu suchen?
Ilu
Am 14.07.21 um 09:12 schrieb Bernhard E. Reiter:
Moin,
Am Donnerstag 01 Juli 2021 09:19:41 schrieb Alexander Sander:
Bis März 2023 soll eine, nicht nur für die Verwaltung geöffnete, Code-Plattform zur Verfügung stehen, die fortlaufend weiterentwickelt werden soll. Auf Seite 43ff könnt ihr den ganzen Plan lesen.
meiner Ansicht nach, werden sich die Erwartungen an diesen "Ort für öffentlich Code" _nicht_ erfüllen. Die Leute suchen eigentlich nicht nach Code, sondern nach Zusicherungen über diesen Code, am besten für ihren eigenen Einsatzzeck und im Zusammenhang dessen, was ingesamt verfügbar und möglich ist. Ein "Ort" allein und auch die Vernetzung unter Leuten mit (angenommen) ähnlichen Interessen, kann das nicht leisten.
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
Hi Ilu,
On 14.07.21 14:19, Ilu wrote:
Dabei wäre ein europäisches Git(lab) als Alternative zu gitlab/github.com dringend erforderlich. Naja, ein deutsches System reicht dafür sowieso nicht, es müsste schon europaweit sein.
wir arbeiten daran. In Italien und Frankreich gibt es sowas auch und wir sind da auch mit der EU-Kommission im Gespräch. Der Weg ist momentan, das zuerst national sowas aufgebaut wird und Erfahrungen gesammelt werden und dann wird in Bälde sicher auch eine Initiative von der Kommission kommen um das zusammenzuführen. Es ist einfacher, wenn das bottom-up aus den Mitgliedstaaten kommt und dann top-down als sucess story von der Kommission gepusht wird und in die Länder getragen wird, die bisher noch nix gemacht haben. In dem OGP-Plan steht das zwar nicht drin, wir haben das aber auf dem Schirm und ich bin zuversichtlich, dass das was wird.
Liebe Grüße
Alex
Moin,
Am Mittwoch 14 Juli 2021 14:33:00 schrieb Alexander Sander:
On 14.07.21 14:19, Ilu wrote:
Dabei wäre ein europäisches Git(lab) als Alternative zu gitlab/github.com dringend erforderlich. Naja, ein deutsches System reicht dafür sowieso nicht, es müsste schon europaweit sein.
aus meiner Sicht braucht es das nicht. Viel besser als zentrale, proprietäre Dienstleister wären dezentrale Dienstleister, von denen man umziehen und kooperieren kann und die nur Freie Software laufen lassen.
Gute Dienstleister gibt es schon, der beste den ich kenne ist Octobus/CleverCloud, welche https://heptapod.net/ laufen lassen (git und hg Support aus der EU).
wir arbeiten daran. In Italien und Frankreich gibt es sowas auch und wir sind da auch mit der EU-Kommission im Gespräch.
Die Versuche mit Berlios und anderen haben mir gezeigt: Eine moderne Software und Service gibt es nur, wenn die Kunden dafür (einzeln und vernünftig) bezahlen. Insofern würde ein öffentlich bezahltes Repo ohne Grenzen die besseren Dienstleister wie Octobus eher abwürgen (aus meiner Sicht).
Gruß, Bernhard
Hallo Bernhard,
Wenn es eine git-software mit dem feature set von gitlab CE gäbe, die mit anderen Instanzen federiert, wäre eine zentrale europäische Instanz nicht notwendig. Soweit ich weiß, gibt es das aber nicht. Es gab wohl Ansätze auf der Basis von ActivityPub (zB https://notabug.org/peers/forgefed), aber auf die schnelle finde ich keine Erfolgsmeldungen.
Insofern ist Größe in diesem Zusammenhang ein Wert an sich, damit die Zusammenarbeit funktioniert. Ein Fork soll in Verbindung stehen zum Hauptprojekt und das geht derzeit ohne Klimmzüge nur innerhalb einer Instanz. Deshalb sind github/gitlab.com groß. Federation wäre natürlich besser.
Ohne Federation macht jeder zusätzliche Dienstanbieter die Sache nicht besser, sondern schlechter. Insofern liegt es im Interesse der Sache, sie entweder abzuwürgen oder - falls technisch möglich - zur Federation zu zwingen.
Ein Dienst, bei dem Nutzer zahlen müssen, hat keinerlei Chancen. Dann geht doch jeder gern zu amerikanischen Konkurrenz oder hostet eben selbst. Selbsthosten wäre ja ok, wenn es denn Federation gäbe ...
Den Verweis auf https://heptapod.net/ verstehe ich nicht, denn das ist einfach eine weitere einsame gitlab Instanz. Soweit ich sehe, wird lediglich hg support hinzugefügt, was aber für die Masse der git Nutzer ziemlich unerheblich ist.
Viele Grüße Ilu
Am 15.07.21 um 17:53 schrieb Bernhard E. Reiter:
Moin,
Am Mittwoch 14 Juli 2021 14:33:00 schrieb Alexander Sander:
On 14.07.21 14:19, Ilu wrote:
Dabei wäre ein europäisches Git(lab) als Alternative zu gitlab/github.com dringend erforderlich. Naja, ein deutsches System reicht dafür sowieso nicht, es müsste schon europaweit sein.
aus meiner Sicht braucht es das nicht. Viel besser als zentrale, proprietäre Dienstleister wären dezentrale Dienstleister, von denen man umziehen und kooperieren kann und die nur Freie Software laufen lassen.
Gute Dienstleister gibt es schon, der beste den ich kenne ist Octobus/CleverCloud, welche https://heptapod.net/ laufen lassen (git und hg Support aus der EU).
wir arbeiten daran. In Italien und Frankreich gibt es sowas auch und wir sind da auch mit der EU-Kommission im Gespräch.
Die Versuche mit Berlios und anderen haben mir gezeigt: Eine moderne Software und Service gibt es nur, wenn die Kunden dafür (einzeln und vernünftig) bezahlen. Insofern würde ein öffentlich bezahltes Repo ohne Grenzen die besseren Dienstleister wie Octobus eher abwürgen (aus meiner Sicht).
Gruß, 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
Hallo,
was ich an git so "sexy" fand, war vor allem die Dezentralität und daneben die Vielzahl an unterstützten Transportprotokollen.
Es ist einfach Repos zu clonen, sodass von "wichtiger" Software zahlreiche Kopien (dezentral) existieren können (Gleiches gilt grundsätzlich auch für andere Inhalte).
Damit kann durch jedermann/-frau verhindert werden, dass Wissen und Inhalte "verlorengehen".
Niemand ist gehindert, mit cgit oder gitweb sich und für andere eigene bare-Repos mit Weboberfläche einzurichten (man kann auch beides kombinieren, was sinnvoll sein kann, weil beide Anwendungen über ein leicht unterschiedliches Featureset verfügen). Das ist dann aber nur "die halbe Wahrheit".
Was demgegenüber den Vorzug von Github und Gitlab ausmacht, ist das "Drumherum", also beispielsweise die Kombination mit einem Issuetracker etc. Es vereinfacht etwas das Leben, alles, was man so braucht, an einem Ort und unter einer Oberfläche zu haben.
Gleichzeitig erschwert das natürlich einen "Umzug" und bedingt dadurch eine gewisse "Zentralisierung". Diese führt wiederum dazu, dass nicht unerhebliche Hardwareresourcen (Server, Netzanbindung etc.) mit hoher Verfügbarkeit vorgehalten werden müssen, was einen entsprechenden finanziellen Aufwand erfordert.
Wenn also zu einer Dezentralität zurückgekehrt werden soll, was mir wünschenswert erscheint (s. o.), müsste zunächst das "Drumherum" so standardisiert werden, dass ein einfacher Umzug (so einfach wie das Clonen eine git-Repos) möglich wird.
Gruß Michael
On Fri, 16 Jul 2021, Dr. Michael Stehmann wrote:
Was demgegenüber den Vorzug von Github und Gitlab ausmacht, ist das "Drumherum", also beispielsweise die Kombination mit einem Issuetracker etc. Es vereinfacht etwas das Leben, alles, was man so braucht, an einem Ort und unter einer Oberfläche zu haben.
Gleichzeitig erschwert das natürlich einen "Umzug" und bedingt dadurch eine gewisse "Zentralisierung".
Github stellt bereits eine ganz gewaltige Zentralisierung dar. Und dann werden Leute gesperrt, weil sie in "Schurkenstaaten" wohnen.
Ein relativ einfacher Ansatz wäre, dass die Fehlerberichte Teil des Programmtextes oder wenigstens des Repositories werden. Naja, das Kommentieren der Fehlerberichte ist dann erst einmal nicht so einfach oder müsste erst wieder für den Benutzer einfach genug gemacht werden.
Es gibt schon Ansätze für Fehlerberichte im Programmtext und Git/Darcs-basiertes Wiki: https://hackage.haskell.org/package/lentil https://hackage.haskell.org/package/gitit
Wenn also zu einer Dezentralität zurückgekehrt werden soll, was mir wünschenswert erscheint (s. o.), müsste zunächst das "Drumherum" so standardisiert werden, dass ein einfacher Umzug (so einfach wie das Clonen eine git-Repos) möglich wird.
Wie Fefe letztens schrieb: Die starke Zentralisierung auf Plattformen wie Github oder YouTube oder Cloud-Dienste oder Facebook ist auch eine Folge der schlechten Internetanbindung der Haushalte. Wenn es einfach wäre, einen schnellen Hausanschluss zu haben, dann könnten viel mehr Leute ihren eigenen Server mit dezentralen Diensten zu Hause betreiben.
Ich werfe mal schnell ein, dass einige Leute an einer Erweiterung des föderalen ActivityPub Protokolls für verteilte Bugtracker und Pull Requests arbeiten :)
https://talk.feneas.org/c/forgefed/10
Paul
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
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
Hallo,
ich bin mit Ilu der Meinung, dass Personen, die Freie Software entwickeln, für ihre Werkzeuge und die Veröffentlichung nicht auch noch "Geld mitbringen" müssen sollten.
Ich denke, sowohl die Entwicklung, als auch das Studium Freier Software dienen der Bildung, sodass dies durch Institutionen, deren gemeinnütziger Zweck Bildung beinhaltet (das sind viele), auch unter Einsatz von Finanzmitteln gefördert werden könnte.
Die "Zersplitterung" könnte auch durch ein Linksammlungs-Portal aufgefangen werden, wobei der Inhalt dieses Portals zum größten Teil wohl auch durch Software (die wohl noch zu entwickeln wäre) "automatisch" generiert werden könnte. Auf diese Weise könnte auch der Hochschulbereich Aufmerksamkeit bekommen.
Wenn man die Zentralisierung auf proprietäre und kommerzielle Interessen verfolgende Anbieter "brechen" will, bedarf es IMO deshalb fantasievoller Lösungen, weil eine bloße "Kopie" (der Software oder des Geschäftsmodells) nicht zielführend erscheint.
Gruß Michael
Moin,
Am Freitag 16 Juli 2021 13:56:57 schrieb Dr. Michael Stehmann:
ich bin mit Ilu der Meinung, dass Personen, die Freie Software entwickeln, für ihre Werkzeuge und die Veröffentlichung nicht auch noch "Geld mitbringen" müssen sollten.
wer gute Werkzeuge und Plattformen haben möchte, der muss auch darüber nachdenken, wie diese finanziert sind. Und eine Wahl sollte es auch geben.
Gute Freie Software-Produkte sind in Initiativen organisiert, dort gibt es dann die Hauptversionen und meist Möglichkeiten Varianten und Beiträge zu finden. Es ist natürlich sinnvoll, dass auf einer Plattform an einer Stelle zu haben. Der Koordinationspunkt einer Initiative. Die Software-, Code- und andere Teile können dann verschiedenen bereitgestellt werden.
Ich denke, sowohl die Entwicklung, als auch das Studium Freier Software dienen der Bildung,
Die eigene und die Bildung anderer sind nicht die einzigen Zwecke Freier Software-Entwicklung...
sodass dies durch Institutionen, deren gemeinnütziger Zweck Bildung beinhaltet (das sind viele), auch unter Einsatz von Finanzmitteln gefördert werden könnte.
Ja, ich finde es richtig, dass Bildungsinstitute und andere Instituationen auch Räume anbieten. Es braucht dann vielleicht ein Management vom Lebenszyklus von Software-Komponenten. Manche sind einmal-Dinge, die werden irgendwann archiviert und zeigen vielleicht noch auf den damaligen Nachfolger. Andere werden reif und produktiv eingesetzt, die ziehen dann meistens um, früher oder später.
Und dann sollten die Nutznießenden der Software-Komponenten das finanzieren, und wenn Geld für die Werkzeuge und Plattformen fließen kann, dann passen die deutlicher besser zu den Initiativen und Produkten.
Gruß, Bernhard
Hallo Ilu,
ich will mal ein paar Gedanken aus der Praxis einwerfen.
On Fri, Jul 16, 2021 at 12:26:37PM +0200, Ilu wrote:
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.
Ich sehe hier nicht so recht den Praxisbezug. Maintainer der upstream-Projekte, die proaktiv nach Forks und Fixes suchen? Das halte ich für unrealistisch. Üblicherweise ist upstream in den allermeisten Fällen schon ausgelastet mit der eigenen Arbeit und dem, was von externen Contributern an sie herangetragen wird.
Aus Sicht von externen Entwicklern sehe ich ebenfalls den Praxisebezug nicht so recht. Wenn ich meinen Fix bei upstream unterbringen will, muss ich mich an deren Vorgaben orientieren. Im Zweifel kann ich ggf. auch einen Pull-Request gegen ein auf einer anderen Plattform gehostetes Repo stellen, aber sowas sieht man doch sehr selten.
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.
Mich würde hier interessieren, was da die Intention ist? Aus Sicht von externen Forschern, die nicht aktiv an der Entwicklung einer Software beteiligt sind? Die Beteiligten selbst kommen ja schon in Kontakt, selbst bei auf verschiedenen Plattformen gehosteten Git-Repos.
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.
Code, der da jetzt rumgammelt, wird da auch rumgammeln, wenn die Repos federiert sind. Selbst bei Github macht sich kein Maintainer die Arbeit, in allen Forks nach irgendwas zu suchen. Der Anstoß muss von der anderen Seite kommen.
Oder anders gesagt: wieso sollte jemand einen Fix in ein öffentliches Repo tun und dann upstream nicht bescheid sagen?
Was es hier eher bräuchte um diesen Effekt des vor sich hinrottenden Codes anzugehen, wäre auch in der Ausbildung mal zu zeigen, wie die Zusammenarbeit funktioniert und wie man seinen Code tatsächlich upstream unterbringt. Da fehlt es eher. Bei vielen Fixes wird nicht mal versucht die weiter zu tragen.
Grüße Alex
Hallo Alex,
Ich sehe hier nicht so recht den Praxisbezug. ...
dann komme ich mal mit Gedanken aus meiner Praxis als NUTZER:
Upstream ist schon vor Jahren eingegangen. Es gibt 30 Forks, von denen Nr. 5, 18 21 aktiv zu sein scheinen. Ich entscheide mich für Nr. 5. Irgendwann gibt es ein Problem und überraschenderweise ist Fork Nr. 13 aus dem Dornröschenschlaf erwacht und fixt das. Ich schreibe issues mit dem Fix bei Nr. 5, 18 und 21, aber dort passiert nichts. Ok, gut, also nutze ich jetzt Nr. 13. Ein Jahr später gibt es wieder ein Problem und Nr. 13 ist tot. Also suche ich wieder die anderen Forks ab ... usw. Das funktioniert, weil alle Forks auf github.com sind.
Oder eine mich interessierende Vereinssoftware. Die gibt es upstream, aber die Vereine forken die in ihre Repos und ergänzen Features. Da upstream ohnehin nix merged, macht auch niemand PRs. Also frage ich entweder bei den in Betracht kommenden Vereinen einzeln nach oder muss den gleichen Kram halt nochmal machen.
auch einen Pull-Request gegen ein auf einer anderen Plattform gehostetes Repo stellen, aber sowas sieht man doch sehr selten.
...
Bei vielen Fixes wird nicht mal versucht die weiter zu tragen.
Jo. Weils ohne Federation viel zu umständlich ist.
Oder anders gesagt: wieso sollte jemand einen Fix in ein öffentliches Repo tun und dann upstream nicht bescheid sagen?
Weils vergessen wird. Weil das Zeit kostet. Weil upstream sowieso nie merged. Weil upstream tot ist. Es gibt viele denkbare Gründe. Auf einer zentralen Plattform findet man den Fix aber trotzdem. Auf dem ganzen klein-klein nie.
Du gehst wie Bernhard von gut organisierten Strukturen bei großen Softwareprojekten aus. Das ist aber nur der allerkleinste Teil auf den git-Plattformen.
Viele Grüße Ilu
Am 16.07.21 um 14:35 schrieb Alexander Dahl:
Hallo Ilu,
ich will mal ein paar Gedanken aus der Praxis einwerfen.
On Fri, Jul 16, 2021 at 12:26:37PM +0200, Ilu wrote:
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.
Ich sehe hier nicht so recht den Praxisbezug. Maintainer der upstream-Projekte, die proaktiv nach Forks und Fixes suchen? Das halte ich für unrealistisch. Üblicherweise ist upstream in den allermeisten Fällen schon ausgelastet mit der eigenen Arbeit und dem, was von externen Contributern an sie herangetragen wird.
Aus Sicht von externen Entwicklern sehe ich ebenfalls den Praxisebezug nicht so recht. Wenn ich meinen Fix bei upstream unterbringen will, muss ich mich an deren Vorgaben orientieren. Im Zweifel kann ich ggf. auch einen Pull-Request gegen ein auf einer anderen Plattform gehostetes Repo stellen, aber sowas sieht man doch sehr selten.
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.
Mich würde hier interessieren, was da die Intention ist? Aus Sicht von externen Forschern, die nicht aktiv an der Entwicklung einer Software beteiligt sind? Die Beteiligten selbst kommen ja schon in Kontakt, selbst bei auf verschiedenen Plattformen gehosteten Git-Repos.
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.
Code, der da jetzt rumgammelt, wird da auch rumgammeln, wenn die Repos federiert sind. Selbst bei Github macht sich kein Maintainer die Arbeit, in allen Forks nach irgendwas zu suchen. Der Anstoß muss von der anderen Seite kommen.
Oder anders gesagt: wieso sollte jemand einen Fix in ein öffentliches Repo tun und dann upstream nicht bescheid sagen?
Was es hier eher bräuchte um diesen Effekt des vor sich hinrottenden Codes anzugehen, wäre auch in der Ausbildung mal zu zeigen, wie die Zusammenarbeit funktioniert und wie man seinen Code tatsächlich upstream unterbringt. Da fehlt es eher. Bei vielen Fixes wird nicht mal versucht die weiter zu tragen.
Grüße Alex
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
Hi,
Am Mittwoch 14 Juli 2021 14:19:07 schrieb Ilu:
Was für Erwartungen an ein git sollte ein git nicht erfüllen? Und wer sollte auf die Idee kommen, in einem git "Zusicherungen" zu suchen?
wie ich schon schrieb: * FS Produkte seien für eine bestimmten Einsatzzweck geeignet * Sie stellen die beste Lösung dafür da * Haben eine grundsätzliche Qualität * Bewertungen
Anders gesagt, die Sterne auf gitlab halten machen für ein wichtiges Kriterium, ob die Software-Komponente was taugt. Eine Suche auf einer solchen Plattform verwechseln sie mit umfangreicher Recherche. ;)
Gruß, Bernhard