F-Droid-Treffen auf dem RC3-Kongress

Der Kongress des Chaos Computer Club findet gewöhnlich in persona statt, die Pandemie erzwang ein virtuelles Event, das sich RC3 nannte. Es wird von vielen Open-Source-Fans besucht, so ist es kein Wunder, dass dort Leute sind, die F-Droid und allgemein FOSS-Android-Apps lieben. 2019 hatten wir schon einmal ein F-Droid-Treffen auf dem Kongress. Dieses Jahr setzten wir für den 30. Dezember 2021 ein virtuelles Treffen an und gaben es im F-Droid-Forum bekannt, wie auch auf Mastodon und Twitter.

Ungefähr 10 Leute – überwiegend Maintainer verschiedener Open-Source-Apps – trafen und unterhielten sich für fast 3 Stunden. Da waren offenkundig Entwickler von F-Droid selbst (Client-App, Pakete und Server) aber auch von Apps wie K-9 Mail, AntennaPod, Etar, Event Fahrplan und Tiny Weather Forecast.

Neben weiterer, kleinerer Themen unterhielten wir uns über Folgendes:

  • Die meisten Apps mit offenem Quellcode werden von Freiwilligen in ihrer Freizeit entwickelt. Um an der Entwicklung der Apps als Teilzeitjob zu sitzen, brauchen Entwickler eine Einnahmequelle. Nur ein kleiner Teil der Entwickler kann von den eingenommenen Spenden leben. Wir besprachen die Erfahrungen von allen mit der Einnahme von Spenden. Ein wichtiger Aspekt ist, dass wiederkehrende (kleine) Spenden viel hilfreicher sind als unregelmäßige (große) Spenden, weil es das Vorausplanen einfacher macht. Wir sprachen über Wege, nach Spenden zu fragen ohne nervig zu wirken. F-Droid speichert schon Spendenlinks in den Metadaten der App ubd zeigt sie im Client des Nutzers an. Das Problem ist, dass nach dem Herunterladen die Info-Seite der App nicht mehr aktiv verwendet wird. Wir einigten uns, dass es gut wäre, auf der “Updates”-Seite der F-Droid-App nach Spenden zu fragen: wenn eine App für eine lange Zeit installiert war, könnte der Client fragen, an den Entwickler zur Unterstützung zu spenden. Die “Updates”-Seite wurde schon für solche Nachrichten vorbereitet, aber ein Entwickler muss noch den Rest implementieren.
  • Viele F-Droid-Nutzer betreiben ziemlich alte Android-Geräte. Ein möglicher Grund dafür könnte sein, dass sie sich um die Umwelt sorgen und keine funktionierenden Geräte wegwerfen möchten. Damit alte Android-Versionen weiter unterstützt werden, müssen App-Entwickler einen beträchtlichen Arbeitsaufwand betreiben. Ein Beispiel dafür ist die schwierige Unterstützung von HTTPS-Verbindungen auf alten Android-Versionen. HTTPS-Verbindungen betreffen nicht nur Browser-Anwendungen sondern auch Apps wie Wettervorhersage-Apps oder Podcast-Player. Wenngleich es möglich wäre, jede App mit dem notwendigen Code für Verbindungen mit modernen HTTPS-Servern auszuliefern, würde das die Größe jeder App um ungefähr 4 MB erhöhen. Es gab bereits Überlegungen, wie nur eine App den HTTPS-Code mitbringen könnte und wie er von dort in anderen Apps geladen werden könnte. Der hauptsächlich fehlende Punkt dabei war, welche App vertrauenswürdig genug wäre, derart sicherheitskritischen Code zu transportieren. Wir diskutierten, dass ein Einschluss in den F-Droid-Client keine gute Idee wäre, weil die App schon ziemlich komplex ist. Vorausgesetzt, dass sowohl Geräte, auf denen Google Services laufen, als auch Geräte, die mit microG ausgestattet sind, bereits einen Lieferanten für diesen Code besitzen, entschieden wir, dass wir lediglich eine Open-Source-Bibliothek schreiben, die mit diesen Systemkomponenten verhandeln. So gesehen wäre die Bibliothek im Grunde eine Open-Source-Neuimplementierung von Google’s ProviderInstaller, die dieselben System-APIs aufruft.
  • Es gibt bei F-Droid selten Rücknahmeaufträge für Apps, zum Beispiel aufgrund von Copyright-Ansprüchen. Oftmals ist es dann schwierig, die App-Autoren zu kontaktieren. Einige Apps nutzen Git-Repositorys ohne Ticketsystem und die E-Mail-Kontaktadresse wird beim Hinzufügen einer neuen App ins F-Droid-Repo nicht activ abgefragt. Wir besprachen, ein eigenes Feld in den Metadaten der Apps vorzuhalten, das eine E-Mail-Kontaktadresse aufnehmen könnte.
  • Einige Apps machen starken Gebrauch davon, verschiedene Build Flavors einzusetzen. Build Flavors sind unterschiedliche Versionen derselben App, die sich den Großteil des Quellcodes teilen. F-Droid unterstützt die Spezifizierung der Build Flavors, die bei der Veröffentlichung einer App verwendet werden sollen, dabei gibt es aber Schwierigkeiten mit Metadaten wie Screenshots und App-Beschreibungen. Wir diskutierten Möglichkeiten, wie mit diesem Problem umgegangen werden kann.
  • Ein Problem, das App-Entwickler häufig betrifft, ist, dass die Aktualisierung von Apps auf F-Droid ziemlich viel Zeit in Anspruch nimmt. Der Build-Server muss zuerst den Quellcode der Apps kompilieren. Danach werden die Apps manuell auf einem Computer, der nicht mit dem Internet verbunden ist, signiert. Eine Methode, die App-Entwickler nutzen können, um damit umzugehen, ist die Verwendung von Reproducible Builds. Mit reproduzierbaren Builds, vertreibt F-Droid die Apps mit der original Entwicklersignatur. Auf diese Weise können Anwender zwischen der F-Droid-Version und der Entwicklerversion einer App wechseln, ohne sie neu installieren zu müssen. App-Entwickler können dann kritische Aktualisierungen auf ihren Internetseiten veröffentlichen, aus der App heraus oder in ihrem eigenen F-Droid-Repository und Nutzer können weiter die App direkt aktualisieren – selbst wenn sie sie ursprünglich aus F-Droid installierten..

Wir hoffen, dass wir uns nächstes Jahr wieder persönlich treffen können.