App-Entwicklung für Linux

 (makealinux.app)
1 Punkte von GN⁺ 2023-12-11 | 1 Kommentare | Auf WhatsApp teilen
  • Für Linux auf Desktop und Mobilgeräten gibt es eine Nachfrage nach neuer Software, doch in App-Stores und Paketquellen gibt es zu wenige Anwendungen. Die Botschaft lautet daher, sich eher auf App-Entwicklung als auf neue Distributionen zu konzentrieren.
  • Auch Apps, die aus einem persönlichen Bedarf heraus entstehen, können durch öffentliche Entwicklung zu Lernmaterial und Community werden und so zur Erweiterung des Linux-Ökosystems beitragen.
  • Die Vielfalt von Hunderten Distributionen ist zwar eine Belastung, aber mit dokumentierten Paketierungs- und Verteilungssystemen lassen sich Apps an Nutzer in vielen Umgebungen ausliefern.
  • GNOME, KDE Frameworks, elementary OS, Electron und Ubuntu Touch bieten unterschiedliche Entwicklungspfade mit Gtk, Qt, Vala, JavaScript·HTML·CSS beziehungsweise QML.
  • Es gibt Distributionswege wie AppCenter, AppImage, Flatpak, Open Build Service und Snapcraft sowie Monetarisierungsmöglichkeiten über kostenpflichtige Apps, Dienste und unterstützungsbasierte App-Stores.

Warum Linux mehr Apps braucht

  • Nutzer von Linux auf Desktop und Mobilgeräten haben eine Nachfrage nach neuer Software.
  • Linux-App-Stores und Paketquellen bieten im Vergleich zu proprietären Plattformen zu wenige Anwendungen.
  • Technikbegeisterte werden dazu aufgerufen, ihre Leidenschaft und Kreativität lieber in neue Anwendungen für Linux-Nutzer zu stecken, statt noch mehr Linux-Distributionen zu bauen.
  • Die Kernbotschaft lautet: „Hört auf, Linux-Distributionen zu bauen, und baut Anwendungen.“

Welche Wirkung App-Entwicklung auf das Ökosystem hat

  • Wenn es eine App-Idee gibt, die man persönlich braucht, gibt es womöglich auch andere Nutzer mit ähnlichem Bedarf.
  • Wenn Anwendungen öffentlich entwickelt werden, können auch neue Entwickler leichter lernen und einsteigen, was der nächsten Generation der Linux-App-Entwicklung hilft.
  • App-Entwicklung ist kreative Arbeit, und auch das Erfolgserlebnis beim Abschluss eines Projekts kann eine Belohnung sein.
  • App-Entwicklung hilft beim Aufbau von Community, und die Linux-Community möchte Entwicklern oft dabei helfen, erfolgreich zu sein.
  • Fähigkeiten in der Softwareentwicklung sind gefragt, und es gibt viele kostenlose Lernressourcen.
  • Die Vorstellung, Linux-Nutzer würden Entwickler finanziell nicht unterstützen, ist ein Irrtum. Beliebte kostenpflichtige Apps und Dienste können neue Einnahmequellen schaffen.

Entwicklung für verschiedene Linux-Distributionen

  • Linux ist im Unterschied zu anderen Plattformen ein sehr vielfältiges Ziel, und es existieren Hunderte Distributionen.
  • Sobald eine Anwendung veröffentlicht ist, kann sie in der Regel in mehreren Umgebungen laufen.
  • Es gibt gut dokumentierte Paketierungs- und Verteilungssysteme, mit denen Entwickler Apps an Nutzer ausliefern können.
  • Jedes Entwicklungs-Framework und jede Linux-Distribution hat empfohlene Wege, Apps an Nutzer bereitzustellen.
  • Wenn die App bereit zur Veröffentlichung ist, kann man in der Entwicklerdokumentation die empfohlenen Paketierungsleitfäden nachlesen.

Wege für den Einstieg in die Entwicklung

  • GNOME

    • Das GNOME-Projekt entwickelt den GNOME-Shell-Desktop und unterstützt Entwicklung auf Basis von Gjs und Gtk.
    • Mit Gtk lassen sich populäre Sprachen wie Python, C, C++, Rust und JavaScript verwenden.
    • GNOME Developer Center

  • KDE Frameworks

    • KDE bietet den Plasma-Desktop sowie Werkzeuge und Frameworks für die Anwendungsentwicklung.
    • KDE Frameworks werden seit Langem für die Entwicklung verschiedenster Desktop-Anwendungen eingesetzt.
    • Genutzt werden vor allem das Qt-Toolkit und die Programmiersprache C++.
    • KDE Frameworks Getting Started

  • elementary OS

    • elementary OS versteht sich als schnelles, offenes und datenschutzfreundliches Betriebssystem als Alternative zu Windows und macOS.
    • Entwickler bauen dafür Desktop und Ökosystem zur App-Entwicklung auf.
    • Der Entwicklerleitfaden empfiehlt Vala und Gtk.
    • elementary OS Developer Guide

  • Electron

    • Electron ermöglicht es, plattformübergreifende Desktop-Apps mit JavaScript, HTML und CSS zu erstellen.
    • Entwickler können die riesige Bibliothek an node-Modulen nutzen, um Apps auf Basis von Web-Technologien zu bauen.
    • Electron Documentation

  • Ubuntu Touch

    • Ubuntu Touch ist ein Open-Source-Betriebssystem, das für den Einsatz auf Smartphones, Tablets, PCs und weiteren Geräten ausgelegt ist.
    • Native Ubuntu-Touch-Apps werden mit QML oder HTML erstellt; das Verhalten wird mit JavaScript, C++, Python, Rust oder Go definiert.
    • Ubuntu Touch Documentation

Stimmen von Entwicklern zum Linux-App-Ökosystem

  • Neil McGovern von der GNOME Foundation sagt, dass es ein florierendes App-Ökosystem brauche, um Linux zur breiten Masse zu bringen, und dass das Ziel eines offenen Desktops näher rücke, wenn jeder für Linux entwickeln kann.
  • Aleix Pol von KDE e.V. sagt, dass großartige Apps nötig sind, um Linux zum bevorzugten Betriebssystem zu machen, und dass sich mit den Entwicklungswerkzeugen das Umsetzen lässt, was man sich vorstellt.
  • elementary-Gründer Daniel Foré sieht darin nicht nur die Chance, großartige Apps für Desktop-Linux zu entwickeln, sondern auch Plattform-APIs zu schaffen und die Richtung des Desktops zu beeinflussen.
  • Jan Sprinz, Vorstandsmitglied der UBports Foundation, sagt, dass Linux-App-Entwicklung völlig anders sei als geschlossene Ökosysteme und dass man trotz technischer Konkurrenz für eine größere Vision zusammenarbeite.

Wie man Apps teilt und verteilt

  • AppCenter

    • Ein offener Pay-what-you-want-App-Store und Build-Service für unabhängige Entwickler.
    • Das AppCenter Dashboard ist in GitHub integriert und unterstützt Releases sowie Issue-Tracking.
    • AppCenter Dashboard

  • AppImage

    • Desktop-Linux-Anwendungen können im AppImage-Format verteilt werden, um Nutzer gängiger Linux-Distributionen zu erreichen.
    • Das Konzept lautet: einmal paketieren und überall ausführen.
    • AppImage Packaging Guide

  • Flatpak

    • Ein Framework für die Verteilung von Linux-Desktop-Anwendungen.
    • Es wurde von Entwicklern geschaffen, die seit Langem am Linux-Desktop arbeiten, und wird als unabhängiges Open-Source-Projekt betrieben.
    • Flatpak Documentation

  • Open Build Service

    • Der openSUSE Build Service ist die öffentliche Instanz von Open Build Service.
    • Er wird neben der Entwicklung der openSUSE-Distribution genutzt, um Pakete für mehrere Distributionen wie Fedora, Debian, Ubuntu und SUSE Linux Enterprise aus derselben Quelle bereitzustellen.
    • openSUSE Build Service Help

  • Snapcraft

    • Snapcraft ist ein Kommandozeilen-Tool zum Erstellen von snaps.
    • snaps sind App-Pakete für Desktop, Cloud und IoT; sie werden als leicht installierbar, sicher, plattformübergreifend und ohne Abhängigkeiten beschrieben.
    • Snapcraft Documentation

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-12-11
Hacker-News-Meinungen

  • Ich halte die Prämisse für falsch, weil es unter Linux noch kein Bündel aus ABI-stabilen Kern-Frameworks gibt.
    Konkurrenzplattformen haben deutlich mehr grundlegende Frameworks wie CoreImage, CoreAudio, CodeML, SceneKit und AppKit, und sie brechen seltener.
    Auch snap und flatpak unter Linux sind interessant, aber sie wirken eher wie ein Umweg über Infrastruktur und Paketmanagement, statt das Problem in den Frameworks und Programmiersprachen selbst zu lösen, die Anwendungen verwenden sollen.

    • Die Linux-Enthusiasten-Community lehnt diese Richtung tendenziell aktiv ab. Denn sie will alles modular machen und passend für bestimmte Anwendungen zusammenbauen.
      Auch unter Linux gibt es de-facto-Standardbündel, aber weil sich Dinge ändern und verworfen werden, sind sie weniger stabil. Trotzdem ist es besser, als es auf den ersten Blick scheint, und Snaps können einige Probleme abmildern.
      Wenn sich Nutzer jedoch für Distributionen ohne solche Standards entscheiden, verliert man in dem Moment die Hälfte der potenziellen Nutzer, in dem man nicht jede ungewöhnliche Konfiguration unterstützt.
    • Ich habe irgendwo gelesen, dass das derzeit stabilste Ziel unter Linux Win32 über Wine oder Proton ist.
    • Der Kern davon waren GNOME- oder KDE-Frameworks und die FreeDesktop-Standards; zumindest war das vor 20 Jahren der Plan.
      Aber wie im Beitrag gesagt wird, konzentrieren sich die meisten weiter darauf, Distributionen zu bauen, und dadurch entsteht naturgemäß nur schwer ein einzelner Stack, der mit all den vielen eigenwilligen Distributionen Schritt hält.
      Am Ende nahm Google den Linux-Kernel, setzte zwei Bündel von Kern-Frameworks auf Basis von Java und JavaScript darauf, und für normale Verbraucher wurden diese Linux-Distributionen zu den Gewinnern.
    • Ich sehe die Hauptverantwortung bei den glibc-Entwicklern. Dinge wie Missbrauch von Versionsnamen und die jüngste Hinzufügung neuer ELF-Relocation-Typen machen die Distribution von Spiele-Binaries über mehrere Distributionen hinweg schmerzhaft.
      In der Regel bauen Spieleentwickler auf einer aktuellen großen Distribution und laden das Ergebnis bei Steam hoch. Wenn diese Distribution glibc 2.36 enthält, bekommt das Binary häufig ebenfalls Versionsnamen, die glibc 2.36 oder neuer verlangen.
      Am Ende muss man mit der symver-Direktive von binutils gas Versionsnamen erzwingen, die mit einer hinreichend alten glibc kompatibel sind. Persönlich halte ich 5 Jahre, vielleicht auch 7–8 Jahre, für einen vernünftigen Maßstab: https://sourceware.org/glibc/wiki/Glibc%20Timeline
      Normale Spieleentwickler wissen von solchen Problemen kaum etwas, und selbst wenn, würden sie sich diese schmerzhafte Arbeit nicht für 1 % des Marktes antun. Bei libgcc und, im Fall von C++, auch libstdc++ muss man statisch linken, um dieses ABI-Problem zu vermeiden.
      Immerhin stellt die Godot-Engine Build-Container bereit, die darauf Rücksicht nehmen, und auch Unity sieht in dieser Hinsicht sauber aus. Bei UT5.x weiß ich es nicht genau.
      Andererseits gibt es auch Engines, die nicht vorbereitet sind, etwa Electron-basierte Spiele. Ohne eine zur Distribution passende GTK+-Version wie bei Enlightenment, Qt, reinem X11 oder Wayland laufen sie unter Umständen nicht.
      Auch die vollständige Google-Blink-Engine korrekt zu paketieren und als Binary für eine breite Palette von ELF/Linux-Distributionen auszuliefern, ist nicht einfach.
      ELF/Linux ist wegen der allgemeinen ABI-Brüche feindlich gegenüber reiner Binary-Distribution, besonders bei SDKs und Kernbibliotheken.
      Wenn schon Spiele-Binaries so schwierig sind, werden Apps noch schwieriger sein. Ich sehe es schon kommen, dass Entwickler am Ende sagen: „Egal, installiert und nutzt einfach Microsoft SUSE GNU/Linux, alles andere unterstützen wir nicht.“
    • Wenn Linux eine Framework-Breite auf dem Niveau von macOS bieten würde, hätte ich auch private Projekte längst auf Linux ausgerichtet.
      Es ist großartig, viele Werkzeuge einfach nutzen zu können, ohne sich groß um Supportdauer, die bessere Fork oder die Kompatibilität mit anderen Drittanbieterbibliotheken kümmern zu müssen. Das reduziert die Reibung enorm und lässt einen einfach bauen.
      Das KDE-Qt-Ökosystem und GNOME/GTK kommen dem am nächsten, sind aber noch nicht auf diesem Niveau.

  • Vielleicht kenne ich einfach nicht das Muster, nach dem entschieden wird, wann man Paketnamen dev und version anhängt und was die beliebigen angehängten 1 oder 0 bedeuten, aber die erste Linux-Distribution mit konsistenten Regeln für Paketnamen dürfte Sympathien gewinnen
    libgnutls-dev
    libgtk-3-0
    libwayland-server0
    libxcb1
    libx11-6
    libffi-dev
    libncurses5-dev

    • -dev ist ziemlich einfach, weil es die Header enthält
      Die Zahlen sind Versionskennzeichnungen für Fälle, in denen mehrere Versionen gleichzeitig installiert werden können. Ausnahmen kann es allerdings geben, etwa wenn sie wie bei xcb1 Teil des Bibliotheksnamens sind
      Zum Beispiel konnte man irgendwann vermutlich libgtk-3-0 und libgtk-2-$something gleichzeitig installieren. Wahrscheinlich hat man den Namen beibehalten, damit Verweise auf libgtk-3-0 in alten Tutorials nicht kaputtgehen, selbst wenn libgtk-2 später entfernt wird
      Beim abschließenden 0 in libwayland-server0 bin ich mir auch nicht sicher. Ich sehe in /var/lib dieselbe Bibliothek mit verschiedenen .$number-Endungen, habe aber nie genauer nachgeforscht, welches Problem das exakt löst
    • Die Trennung von Binärpaketen und Quell-/Entwicklungspaketen ist eine Debian-Konvention. Wenn man eine Bibliothek nur nutzt, reicht das Paket ohne -dev; wenn man mit dieser Bibliothek entwickelt, braucht man zusätzlich das -dev-Paket, das die Header installiert
      Die angehängten 1 oder 0 sind nichts Besonderes, sondern einfach Teil des Paketnamens oder der Version
    • Bei Arch und dessen Derivaten gibt es so etwas größtenteils nicht
      -dev bezeichnet allerdings Dinge, die man nur braucht, wenn man gegen diese Bibliothek entwickelt
      Die Zahl ist die Hauptversionsnummer, also die Kompatibilitätsnummer. Dadurch können mehrere Hauptversionen, von denen unterschiedliche Pakete abhängen, ohne Konflikte einfach parallel installiert werden
    • Wenn man ein Programm baut, installiert man das -dev-Paket. Um nummerierte -dev-Pakete muss man sich normalerweise nicht direkt kümmern; falls nötig, sollte das unnummerierte Paket darauf weiterleiten
      Beim Build wird aufgezeichnet, welches numerische Suffix, also welche ABI-Version, verwendet wurde. Das sollte dem .so.N-Suffix entsprechen, aber man sucht es nicht direkt auf diese Weise
      Dadurch können mehrere inkompatible Kopien einer Bibliothek installiert sein, und die passende kann verwendet werden. Distributionen räumen alte Varianten normalerweise bei größeren Releases auf
      Bei der Installation sollten automatisch die beim Build aufgezeichneten Abhängigkeiten verwendet werden
    • Es gibt GoboLinux, und aus meiner Sicht löst es alles, ohne so komplex zu sein wie Nix. Aber niemand hat sich dafür interessiert

  • Das ist eines der größten Probleme, die die gesamte Linux-Plattform zurückhalten. Es wird oft als Vorteil dargestellt, aber ich sehe das nicht so
    Entwickler führen die große Auswahl gern als Stärke von Linux an, aber für viele Nutzer wird daraus das Paradox der Wahl, und sie kehren zu ihrer bisherigen Plattform zurück
    Unter macOS und Windows gibt es weniger Optionen, aber die verfügbaren Optionen sind deutlich ausgereifter und weniger fragmentiert
    Zum Beispiel: Wie viele Tiling Window Manager braucht man wirklich? Könnte man nicht den besten Tiling Window Manager auswählen und bessere Docks und Applets bauen? Und wie wäre es mit Apps und Launchern, die in das Paradigma eines Tiling Window Managers integriert sind?
    Stattdessen bleiben oft zehn Tiling Window Manager und halbherzige Workarounds obendrauf übrig

    • Menschen analysieren nicht exhaustiv alle Optionen, bevor sie sich entscheiden. Sie sehen sich ein paar Kandidaten an und wählen je nach Popularität oder Zugänglichkeit einen aus
      Erfolgreiche Ökosysteme sorgen dafür, dass man mit einer gut sichtbaren Option ein ausreichend gutes Ergebnis bekommt
      Dass es immer mehr Linux-Distributionen gibt, sind meistens nur kleine Unterschiede, die die sinnvolle Passung nicht wirklich verringern; als Problem sehen das nur sehr wenige, denen die Wahl einer Distribution ohnehin nie schwerfiel
      Anders ist es bei Dingen wie Wayland: Dort werden Plumbing und Hardware plötzlich wichtig, und um eine brauchbare Kombination zu wählen, muss man die interne Struktur bis zu einem gewissen Grad verstehen. Das ist ein echtes Problem
      Mac oder Windows mit Linux zu vergleichen, ist ebenfalls nicht besonders sinnvoll. Für 95 % der Verbraucher ist das Betriebssystem eine feste Eigenschaft oder Funktion des Computers, kein separates Produkt
      Wenn das Gesamtpaket passt, kaufen sie vielleicht einen Computer mit diesem Betriebssystem, aber sie werden es nicht separat auf ihrem Windows- oder Mac-Gerät installieren wollen
      Menschen mit genug technischem Wissen, um zufrieden zu sein, werden durch drei weitere Ubuntu-Derivate und zwei weitere Arch-Derivate kaum ernsthaft verwirrt sein
    • Einen Tiling Window Manager zu bauen macht Spaß. Kollaborativ Software zu entwickeln ist nicht nur ein Mittel, um ein bestimmtes Ergebnis zu erzielen, sondern auch ein Zweck an sich
      Open-Source-Entwickler zu sein bedeutet, Ziele und Mittel selbst bestimmen zu können; in der kommerziellen Softwareentwicklung hat man diese Freiheit oft nicht
      Es entstehen raue Kanten, aber der IKEA-Effekt greift, und am Ende mag man es
    • Dieses Problem liegt im Aufgabenbereich der Distributionen. Wer nicht so viele Wahlmöglichkeiten will, kann eine Distribution nutzen, die viele Entscheidungen stellvertretend trifft; man muss nicht darauf drängen, dem gesamten Ökosystem Optionen wegzunehmen
      Wenn alle dieselbe Software verwenden, entsteht ein Monokultur-Ökosystem, das anfälliger für Angriffe ist. Windows wurde auch deshalb so stark von Viren ins Visier genommen, weil das Ziel groß und einheitlich war
      Wenn man den Windows-Rechner eines normalen Nutzers kompromittieren konnte, ließen sich die übrigen ähnlich kompromittieren. Bei Linux ist das deutlich schwieriger
      Außerdem ist es freie Software. Wenn man niemanden dafür bezahlt, es zu tun, handelt es sich meist um Freiwilligenarbeit, und wir können anderen nicht vorschreiben, wofür sie ihre freiwillige Zeit einsetzen sollen
      Wenn es so viele Gruppen gibt und trotzdem niemand beitreten möchte, sollte man auch die dominanten sozialen Strukturen betrachten. Ein Ausgangspunkt könnte sein, Verhaltenskodizes abzuschaffen, die es erlauben, sogar Verhalten außerhalb des Projekts zu bestrafen
    • Ich glaube, es gibt mehr Launcher und Docks als Tiling Window Manager
      Und ich weiß auch nicht genau, was daran noch verbessert werden sollte. Dinge wie Ulauncher oder Albert sind viel mächtiger als das, was auf anderen Plattformen möglich ist, und ich wüsste nicht, wie man die UI noch besser machen könnte
    • Es sollte so viele Tiling Window Manager geben, wie Menschen Lust haben zu bauen

  • Mehr Software ist gut. Aber bevor man etwas von Grund auf neu baut, wäre es vielleicht sinnvoll, zu bestehenden Projekten beizutragen oder sich Projekte auszusuchen, die aufgegeben wurden oder etwas Pflege brauchen, damit sie mit aktuellen Compilern und aktueller Hardware wieder gebaut und ausgeführt werden können.
    Ich frage mich auch, ob es irgendwo eine Datenbank ruhender oder toter Projekte gibt, deren Wiederbelebung sich lohnen würde.

    • Es kann sein, dass etwas Bestehendes nicht auf die Weise gebaut ist, die ich anstrebe.
      Ein anderes Projekt wird vielleicht von jemandem geleitet, mit dem schwer auszukommen ist, oder von einer Community, die Vorschläge und Patches nicht annimmt.
      Soziale Prozesse und Blockaden können die Motivation zum Beitragen zerstören. Nicht alle können optimistische Teamplayer ohne Ecken und Kanten sein.
      Für mich ist es besser, von Grund auf neu anzufangen: Ich kann alle Variablen kontrollieren, muss keine bestehende soziale oder technische Infrastruktur anfassen, muss niemanden davon überzeugen, dass meine Idee gut ist, und will nicht mehr Zeit mit Streit und Diskussionen verbringen als mit Code.
      Die Erfahrung als Solo-Entwickler ist besser. Man ist nicht an Politik und soziale Prozesse gebunden, und der Versuch, Teamplayer zu sein, hat mir nur Schmerz bereitet.
    • In den meisten Bereichen gibt es zu viele minderwertige Versuche; würde man diese Energie auf die wenigen Top-Projekte bündeln, könnten einige hervorragende Apps entstehen.
      Zusammenarbeit kann belastend und anstrengend wirken, aber am Ende geht es darum, Ergebnisse zu liefern, und es ist besser investierte Zeit als die Arbeit an Projekten, die aufgegeben werden.
    • Ich frage mich, ob es bei den großen Linux-Paket-Repositories irgendwo Statistiken gibt, mit denen man nach häufig genutzten, aber nicht gewarteten oder funktional unvollständigen Apps suchen kann.

  • Es wird oft beklagt, dass es an Werkzeugen fehlt, um Apps zu bauen, die über mehrere Betriebssysteme hinweg kompatibel sind, aber dem stimme ich nicht zu. Es gibt auch Lösungen jenseits von Electron.
    Telegram nutzt Qt und liefert performante native Apps für alle drei Betriebssysteme aus.
    Flutter kompiliert auf allen drei Betriebssystemen und auf Mobilgeräten zu nativem Code.
    Kirigami ist ein QtQuick-Framework, mit dem sich Apps erstellen lassen, die sowohl auf Mobilgeräten als auch auf Desktops laufen.
    Man muss einfach Apps bauen. Es gibt keinen Grund, das als Ausrede zu benutzen, um Linux die Schuld zu geben.

    • Flutter verhält sich je nach Plattform leicht unterschiedlich und liefert dadurch auf allen Plattformen eine subtil schlechtere Erfahrung. Kirigami oder Qt Quick sind realistisch betrachtet auch kaum praktikable Optionen.
      Unter Windows, macOS und auf Mobilgeräten gibt es kaum Community oder ernsthafte Projekte. Das soll KDE nicht herabsetzen, aber so sieht die Realität aus.
      Auch die Lizenzierung von Qt Quick ist unter iOS nicht einfach oder wird im kommerziellen Einsatz sehr teuer.
      Dagegen investieren große Unternehmen in Electron und liefern sehr ausgereifte produktionstaugliche Werkzeuge; dazu kommen eine riesige Community und ein großes Library-Ökosystem, und es ist auch keine ungewohnte Sprache wie Dart.
      Telegram geht wirklich noch einen Schritt weiter. Der Client ist hervorragend.
    • Auch die Qt-basierte Telegram-App läuft auf macOS gut, aber die meisten Apple-Nutzer entscheiden sich für den Swift/Cocoa-Client für macOS und iOS[0].
      [0]: https://github.com/overtake/TelegramSwift

  • Das Problem liegt darin, dass OSS-Software oft nicht einmal wirklich versucht, mit dem Markt zu konkurrieren.
    Menschen, die OSS-Software nutzen, nehmen es als selbstverständlich hin, dass es an UX mangeln wird, und in der Praxis ist das auch oft so.
    Gewöhnliche proprietäre Software passt sich an, um die End-User-Experience gut zu machen, weil das Risiko besteht, dass Nutzer nicht zahlen; bei OSS gibt es dieses Risiko normalerweise nicht. Open Source muss ebenfalls Risiken ausgesetzt sein, die von den Endnutzern ausgehen.
    Mit Notes[1] wollte ich das ändern, merkte aber, dass es schwierig ist, allein von Werbung zu leben. Ich habe auch Zahlungen für Premium-Funktionen wie Kanban eingebaut, aber die App ist vollständige FOSS, sodass jeder sie leicht aus dem Source Code kompilieren kann.
    Bei der nächsten App[2] plane ich, sie vor dem Release als Closed Source zu führen. Ich kann nicht das Risiko eingehen, dass meine Arbeit nicht entlohnt wird.
    Wenn ich Geld verlangen kann, kann ich mehr in UX-zentrierte Apps unter Linux investieren, und ich glaube, dass das auch der Linux-Community hilft. Teile davon könnte ich als Open Source veröffentlichen, und in ferner Zukunft vielleicht auch alles.
    [1] https://github.com/nuttyartist/notes
    [2] https://www.get-plume.com

    • Die Schnittmenge aus Linux-Nutzern und Menschen, denen Freiheit wichtig ist, ist groß. Für viele ist eine nicht quelloffene Notiz-App wegen Vendor Lock-in und Datenschutzproblemen von vornherein keine Option.
      Wenn man das Programm also nicht als Open Source veröffentlicht, verliert man wahrscheinlich mehr, als wenn man es als Open Source veröffentlicht und das Risiko eingeht, dass ein Teil nicht zahlt.
      Ich denke, es gibt viel mehr Menschen, die für Open Source zahlen würden, als Menschen, die proprietäre Software nutzen wollen.
      Open Source bedeutet nicht, dass man den Code an alle verteilen muss; wenn man Geld verlangt, kann man den Source Code auch nur zahlenden Nutzern geben. Allerdings hätten sie dann das Recht, ihn zu verändern und weiterzuverbreiten.
      Wenn einem Open Source egal ist, kann man Notion oder Evernote nutzen. Wenn man eine moderne Open-Source-Notiz-App sucht, würde ich Logseq empfehlen.
    • Ich glaube, du triffst die richtige Entscheidung. Mit Open Source genug Geld zum Leben zu verdienen, ist extrem schwierig, und die Größenordnung ist um mehrere Zehnerpotenzen kleiner als bei Leuten, die von kommerzieller Software leben.
    • Ich verstehe die Frustration, aber es gibt auch Gegenbeispiele. Das ist nicht abwertend gemeint.
      Erstens sieht Notes Standard Notes ziemlich ähnlich. Wenn du Copyleft-OSS verwendet hast, um Notes zu bauen, finde ich es schwer, dich zu beklagen, solange du den anderen Programmierern, deren Arbeit darin steckt, keine Royalties zahlst.
      Zweitens bin ich vermutlich ein untypischer Nutzer. Ich nutze Linux seit über 20 Jahren, kann aber nicht einmal ein Bash-Skript oder einen Einzeiler in Perl richtig schreiben.
      Gerade weil ich nicht programmieren kann und die Arbeit anderer sowie die Freiheiten, die sie ermöglicht, zu schätzen weiß, habe ich für Software deutlich mehr Geld ausgegeben, als Privatpersonen auf anderen Plattformen normalerweise tun.
      Ich unterstütze unter anderem Kaisen und Debian, zentrale Utilities der FSF und Emacs, KDE, Mozillas Firefox, Betterbird, Syncthing, LaGrange, Joplin, ClipTo, SoulSeek und Dienste wie envs.net.
      Für manches zahle ich jährlich, für manches monatlich, für manches nur einmal.
      Als Standard Notes erstmals erschien, habe ich auch ein 7-Jahres-Abo bezahlt, war aber nach etwa zwei Monaten Nutzung nicht zufrieden und habe aufgehört. Es gibt auch Dinge wie Alacritty, die ich viel nutze, bei denen ich aber keine Möglichkeit zum Spenden gefunden habe; solche Fälle versuche ich zu minimieren.
    • Persönlich finde ich, dass KDE macOS und Windows weit voraus ist.
      Tatsächlich empfinde ich macOS als einen der schlechtesten Window Manager unter den populären Plattformen. Es ist hübsch und leicht zu bedienen, aber sobald man etwas über das Grundlegende hinaus tun will, braucht man magische Beschwörungen, die man nicht auf natürliche Weise entdecken kann.
      Natürlich sind Geschmäcker verschieden.
    • Ich habe dazu ein paar Gedanken. Obwohl ich diesen Bereich recht intensiv verfolge, hatte ich von dieser App noch nie gehört, und die Konkurrenz ist extrem hart.
      Ich habe geklickt, um mir den Premium-Preis anzusehen; auf Jahresbasis ist er vernünftig, aber mir wurde nur eine monatliche Abo-Option angezeigt, und das fand ich schwierig.
      Bei solchen Apps würde ich eher spenden als für eine Premium-Version zahlen. Bei Obsidian hat dieses Modell gut funktioniert.
      Frühzugriff auf Funktionen halte ich nicht für besonders wertvoll, aber viele haben gezahlt, um die Arbeit zu unterstützen.
      Außerdem glaube ich, dass eine große Open-Source-Community rund um ein geschlossenes Kernprodukt den Leuten einen Grund gibt, zu zahlen.

  • Es wäre schön gewesen, wenn der Beitrag ein paar Beispiele enthalten hätte.
    Mir fällt nicht wirklich jemand ein, der gerade eine Distribution baut, obwohl er eigentlich eine Anwendung bauen sollte. Wenn man es erzwingen will, vielleicht LinuxCNC? Aber dafür gibt es spezielle Kernel-Anforderungen, also könnte eine Custom-Distribution sogar passender sein.

    • Desktop-Umgebungen sind im Grunde Anwendungen, die sich mit ein, zwei Klicks oder einem Befehl leicht installieren lassen.
      Ich verstehe nicht so recht, warum abgeleitete Distributionen von abgeleiteten Distributionen nur deshalb veröffentlicht werden, weil sie eine andere Desktop-Umgebung mitbringen.

  • Statt „Hört auf, Linux-Distributionen zu machen, baut Anwendungen“ finde ich, man sollte eher aufhören, auf Leute zu hören, die einem vorschreiben wollen, was man tun und lassen soll.

    • Mich hat dieser Ton auch gestört.
      Trotzdem sind die Botschaft und die Informationen an sich gut.
      Persönlich hätte ich es eher so formuliert: „Linux-Nutzer wollen nicht noch mehr Distributionen. Sie wollen Software.“ Zumindest gilt das für mich.
    • Man sollte auch aufhören, auf Leute zu hören, die sagen, man solle aufhören, auf Leute zu hören, die einem vorschreiben wollen, was man tun und lassen soll. Nicht alles ist relativ; es gibt gute und schlechte Entscheidungen.

  • Ich bin vor Kurzem vom Mac auf Linux umgestiegen, weil ich leistungsfähige gebrauchte Hardware als Alltagsrechner nutzen wollte.
    Ich hatte auch früher schon Linux auf mehreren Maschinen installiert, aber diesmal ist es nicht nur ein Hobby.
    Ubuntu unterstützt meine Hardware und Peripherie gut, aber der App Store wirkt unfertig und irgendwie hineingezwängt. Trotzdem funktioniert fast alles wie erwartet.
    Mint, Debian und Arch würde ich mir auch gern ansehen, bin aber vorsichtig, weil offenbar viel Software mit Ubuntu im Hinterkopf geschrieben wurde.

    • Linux Mint basiert auf Ubuntu, daher lassen sich Ubuntu-Pakete problemlos nutzen. Im Grunde kann man es als das bessere Ubuntu betrachten.
      Es gibt auch eine auf Debian basierende Mint-Version, aber die ist eher eine Absicherung, um nicht kritisch von Ubuntu abhängig zu sein.
      Heutzutage ist es selbst mit exotischeren Distributionen kein großes Problem mehr. Wenn der Standard-Paketmanager die gewünschte App nicht anbietet, kann man AppImage, Flatpak oder Snap verwenden.
    • Unter den Dingen, die für Ubuntu geschrieben wurden, gibt es kaum etwas, das unter Arch oder den meisten aktuellen Distributionen nicht laufen würde.
      Als ich Arch nutzte, musste ich mich daran gewöhnen, welche Annahmen Leute auf Basis von Ubuntu treffen, aber meist ging es nur darum, Konfigurationsdateien zu patchen oder Umgebungsvariablen zu setzen.
      Das sind nützliche Fähigkeiten, die sich auch anderswo übertragen lassen.
    • Fedora sollte man unbedingt auch einmal ausprobieren.
      Ich wünschte, ich hätte es früher ausprobiert.

  • Warum sollte jemand das tun? Es ist schwieriger, und Linux-Nutzer zahlen nicht für etwas, das es nicht wert ist.

    • Weil die Welt davon profitiert, wenn es mehr gute freie Software gibt.