Die Zukunft von GSAK

Der heutige Blogartikel soll sich mit der Software GSAK beschäftigen. Für alle Leserinnen & Leser, die GSAK nicht kennen: Dies ist eine Verwaltungssoftware für das Hobby Geocaching, welches durch umfangreiche Konvertierungsmöglichkeiten und Plugins alles, was das Herz begehrt, zur digitalen Datenhaltung für das Dosensammeln bereit hält.

Ich selbst sehe es im Moment so, dass GSAK alternativlos ist. Es gibt nichts, was an die Flexibilität und den Funktionsreichtum bei einer solchen aktiven und großen Community heranreicht. Leider geht GSAK auch mit einigen Probleme einher, die mir trotz meiner großen Wertschätzung der Software große Bauchschmerzen bereiten:

Gesundheitszustand des ursprünglichen Entwicklers

Ich kenne hierzu keine Details, sondern nur das, was in der Community auch bekannt ist. Der Autor von GSAK erlitt einen oder mehrere Schlaganfälle und musste die aktive Weiterentwicklung der Software aufgeben. Hierzu hat er den Quellcode in die Hände von einigen besonder aktiven Mitgliedern des Forums übergeben.

Offenheit der Software

Als Mitarbeiter einer Firma, die ihr Geld mit Open Source verdient und langjähriger Verfechter von europäischer digitaler Souveränität ist, bin ich der Meinung, dass Programme wie GSAK am besten nicht existieren sollten. Die dotcom-Blase hat gezeigt, dass Software ohne öffentlichen Quellcode der Wirtschaft und den Nutzern langfristig schadet. Gerade bei Software, die nicht viele Entwickler hat, ist es extrem wichtig, dass die Quellen unter einer vom Autor verfügten Lizenz öffentlich zugänglich sind.

Was mich auch stört, ist, dass die Plugins für GSAK (welche über den Macro Index verfügbar sind) nicht mit externen Versionskontrolldiensten wie GitHub oder Gitlab gehostet werden können - zumindest offiziell. Ich habe dies versucht, wurde aber ermahnt, den Link sofort wieder zu entfernen. Dies hat zur Folge, dass in der IT-Industrie etablierte Prozesse wie “Contributing.md” oder “Responsible Disclosure” Prozesse nicht ohne Weiteres etabliert werden können. Außerdem können dem Plugin ohne Versionskontrolldienste keine Lizenz über eine “LICENSE” File gegeben werden. Natürlich kann ich einen SPDX License Header in mein Makro einfügen, aber dies ist leider sehr unüblich in der GSAK Community, was dazu führt, dass die allermeisten Plugins “All-rights-reserved” bleiben.

Fehlende Zukunftsvision

Was mich auch nachhaltig bei solchen Projekten immer beunruhigt ist, wenn Projekte keine Zukunftsvision mehr präsentieren können. Für mich ist dies bei GSAK der Fall. Die Codebasis ist - meinem Informationsstand nach - in Delphi geschrieben. Die Sprache wird zwar noch aktiv weiter entwickelt, wird aber nicht von vielen Leuten beherrscht und die Community und Anbindungen für die Sprache sind nicht besonders groß. Hinzu kommt, dass es keine API gibt, mit der man von extern mit dem Programm kommunizieren kann.

Zudem ist das Projekt kaum in Weiterentwicklung, seitdem es ausgewählten Mitgliedern der Community zur Verwaltung übergeben wurde.

UI/UX

Für mich als Linux Entwickler ist zudem die UI und UX von GSAK ein großes Problem. Ja, ich weiß das ist ironisch, aber es gibt einfach keine Kommandozeile, mit der die Funktionalität der Software in Textform nutzbar wäre. Zusätzlich ist die grafische Benutzeroberfläche von GSAK nicht wirklich übersichtlich für Leute, die lediglich die Basisfunktionalität des Programmes nutzen.

Das Forum ist ein veraltet aussehendes phpBB Design, welches leider nicht wirklich auf Vordermann gebracht worden ist. Auch ein Wechsel auf die Forumssoftware Discourse, was dem Forum von GSAK eine moderne Optik geben würde, ist niemals passiert. Die Leute, die in dem Forum unterwegs sind, sind super hilfreich und geben mehr als ihr Bestes, um selbst den komischsten Fehlern auf den Grund zu gehen, aber das hilft der allgemeinen Usability leider nicht wirklich.

Funktionalitäten

Das größte Problem für mich als Plugin-Autor ist aber die Tatsache des fehlenden Language-Server-Protocols (kurz: LSP) Supports, welcher ermöglichen würde, eine vernünftige Umgebung zu schaffen, um Plugins zu entwickeln. Der vollständig ohne Syntax-Highlighting inkludierte Editor hat nicht einmal eine Hilfe für die Anzahl der Einrückungen oder andere Creature-Komforts, die moderne IDEs und Editoren überall besitzen.

Für Nutzer  wird sicherlich auch der fehlende Web UI Support langsam zum Problem. Es gibt Betriebssysteme wie Chrome OS und MacOS, welche darauf setzen, dass der größte Teil der Arbeit von Webservern erledigt wird. Auch Android basierte Tablets/Laptops sind ein Teil dieser Gerätegruppe. Natürlich sind moderne CPUs mehr als in der Lage, die Aufgaben von GSAK lokal zu erledigen, jedoch ist es auch üblich, mehr als ein Gerät zu haben. Eine WebUI würde es diesen Nutzen ermöglichen, einen einfachen Fernzugriff auf die Funktionalität zu bekommen.

Last but not least möchte ich darauf hinweisen, dass GSAK viele Funktionen für die Planung von gemeinsamen Geocaching Touren bieten, jedoch keine davon ermöglicht, Touren gemeinsam zu planen. Die Daten müssen mühselig im- & exportiert werden und es gibt keine Möglichkeit, Konflikte zwischen Geocashes einfach zu lösen.

Finales Schlusswort

Der Autor von GSAK hat grandiose Arbeit geleistet, um das umfangreichste Tool zur Planung und Verwaltung von Geocaches zu schreiben. Die Community wird ihm dafür immer dankbar sein, jedoch würde ich mir sehr stark wünschen, dass die Community gemeinsam schafft, das Tool ins 21. Jahrhundert zu holen. Ich habe auf Linux über Wine ohne größere Probleme die Möglichkeit GSAK auszuführen, jedoch sind das unnötige Umwege. Mit Programmiersprachen wie Rust, .NET Core, Golang, Java, C++ (via gtk, Qt) und mehr gibt es sehr viele Möglichkeiten, um Anwendungen robust und langfristig auf vielen Platformen anbieten zu können.