kungfuratte
I think things could get a lot more interesting if other software that is more like classic bulletin boards and forums would implement ActivityPub. I mean, such online forums are still able to thrive in their respective niches. If such forums would become compatible with Lemmy, Kbin or Friendica, it could bring a whole new dynamic to this part of the Fediverse. At the same time, it would help these niche forums get more attention (even though I’m not sure if all or even most of them are interested in that).
Meiner Meinung nach sollte der Fokus stärker auf die Communitys und viel weniger auf den Instanzen liegen, diese sollten einfach nur die Funktion von Severn haben und dann auch Sever genannt werden.
Aber inwiefern ist das denn nicht der Fall?
(Also nicht, dass ich den Punkt der Überkomplexität nicht verstehen würde, aber die Instanzen sind doch eigentlich für die meisten Dinge, die man hier so macht, eher von untergeordneter Bedeutung.)
Gut gefällt mir, wie man auf Bild 9 der Galerie sieht, wie der Fahrradweg trotz dieser Begrenzungssteine zugeparkt wird.
In diesem Twitter-Thread von Frank Sauer gibt es eine ganz interessante Perspektive auf den aktuellen Vorgang. Ich würde das (als Laie) selbst nicht unbedingt alles so unterschreiben, aber zum Verständnis der Lage ist es doch ganz aufschlussreich.
Streumunition ist in der Tat nach Osloabkommen bzw. Ottawakonvention und dem Übereinkommen über Streumunition geächtet. - Allerdings erkennen viele Staaten (darunter eben auch die USA) diese Abkommen nicht an.
Ich habe den Eindruck, dass offenes API und offene Anwendungen in der Hinsicht letztlich in dieselbe Richtung deuten.
Ich gebe dir insofern recht, als dass (gerade im ÖPNV-Beispiel) die Schaffung einer offenen Plattform vermutlich erst mal mehr Mehrwert bringt als die Öffnung der Software.
Aber: Auch die Softwareplattform leidet ja daran, schlimmstenfalls nur eine Insellösung zu sein, die für einen Verkehrsverbund oder sogar nur ein Verkehrsunternehmen funktioniert. Selbst wenn die APIs einigermaßen standardisiert sind und ähnlich auch bei anderen Verkehrsbetrieben zum Einsatz kommen, besteht ja immer das latente Risiko des Wildwuchses. Nicht die beste Voraussetzung für die Entwicklung zuverlässiger Drittanbieter-Apps. Eine von den Verkehrsunternehmen gemeinsam entwickelte Lösung, die im öffentlichen Besitz wäre, könnte das Problem potenziell entschärfen.
Andererseits wäre natürlich auch ein Szenario denkbar, in dem ohnehin alle/viele Verkehrsunternehmen ihre Software von ein und derselben spezialisierten Softwarefirma kaufen. In dem Fall wäre die Entwicklung quelloffener Software eine gute Möglichkeit, die Abhängigkeit von diesem Unternehmen zu verringern.
Letztendlich muss man aber natürlich sagen, ich fabuliere hier jetzt auch viel herum und überstrapaziere das Beispiel damit vermutlich.
Ich könnte mir vorstellen, dass es für die Otto-Normal-Oma auch relevant sein könnte, dass öffentlicher Code zumindest potenziell kostspielige Doppelentwicklungen unnötig macht.
Es gibt ja wirklich viel Spezialsoftware, die irgendwo in Verwaltungen und Ämtern zum Einsatz kommt. Wenn alle öffentlichen Einrichtungen, die ähnliche Probleme zu lösen haben, eine gemeinsame offene Software entwickeln würden, dürfte das doch mittel- und langfristig kostengünstiger sein, als wenn jeder bei der lokalen Softwareschmiede ein eigenes Programm in Auftrag gibt.
Beispiel: Nahverkehrsapps. Es gibt einen unfassbaren Wildwuchs an oft total unterschiedlich funktionierenden Apps (die vermutlich jedes mal an die bestehende IT des Verkehrsunternehmens angeflanscht wurden). Grundsätzlich sollen aber ja all diese Programme mehr oder weniger das Gleiche tun. Würden da nicht auch Oma und Otto profitieren, wenn sie überall eine ähnliche App, die sich nur im Branding unterscheidet, nutzen könnten? Und wer weiß, vielleicht ließe sich auf Grundlage so einer gemeinsamen Entwicklung ja langfristig sogar eine gemeinsame Infrastruktur schaffen, sodass eigentlich überall nur noch eine App erforderlich wäre? Möglicherweise würden irgendwann auch Verkehrsanbieter aus anderen Staaten beginnen, die Anwendung mit weiterzuentwickeln.
Ich denke, viele der Vorteile offenen Codes ergeben sich erst mittel- und langfristig. Vermutlich ist das verbunden mit den initial oft etwas höheren Kosten der offenen Entwicklung, einer der Hauptgründe dafür, dass es häufig nicht gemacht wird.