Einstellung der Enwicklung Paperless Backup Programm

Meine Lieben. Ich persönlich beende hiermit die Weiterentwicklung des „Paperless Backup Programms“. Nicht, weil die Idee schlecht wäre, sondern weil ich schlicht nicht jeden Tag aufs Neue gegen sich verändernde Abhängigkeiten ankämpfen kann. Systeme, die permanent ihr Verhalten ändern oder plötzlich andere Voraussetzungen haben, machen eine stabile Weiterentwicklung unmöglich. Und ich möchte niemandem ein Werkzeug anbieten, das ich selbst nicht unter realen Bedingungen zuverlässig betreiben würde.

Keine Updates mehr von mir für Paperless Backup Programm

Mit dem Stand von heute werde ich keine Updates mehr liefern. Der Quellcode ist auf Codeberg verfügbar, und ich stelle das Projekt unter die MIT-Lizenz. Das bedeutet: Jeder kann es sich holen, weiterführen, verbessern oder komplett neu denken. Vielleicht findet sich jemand, der die Energie und Struktur hat, daraus ein Werkzeug zu machen, das unabhängig und zukunftssicher funktioniert. Vielleicht entsteht sogar eine kleine Community, die die Idee weiterträgt und optimiert.

Ich selbst kann das nicht leisten – und das spreche ich offen aus. Weitere Details dazu gibt es im Artikel.

Aktuelle Version funktioniert. Noch!

Aktuelle Version funktioniert. Noch. Stand 29.10.2025. Jeder kann sich diese Version herunterladen und sie läuft zum jetzigen Zeitpunkt einwandfrei. Aber ich kann nicht garantieren, dass das so bleibt. Diese Abhängigkeiten sind volatil, und wenn sich wieder irgendeine externe Komponente entscheidet, die Regeln zu ändern, steht man erneut vor dem gleichen Problem. Ich lasse die Version bewusst online, falls sich jemand findet, der das Projekt fortsetzen möchte oder eigene Anpassungen vornehmen will.

Disclaimer: Verwenden Sie diese Version nicht produktiv, weder privat noch geschäftlich.

Mein Paperless-Backup-Programm lief am Anfang wie ein Traum. Ich war richtig stolz darauf, dieses komplexe Konstrukt gezähmt zu haben. Tage später der Schlag ins Gesicht: Ich starte das System, will die Versionen laden, auf denen meine Backups basieren, und plötzlich wollen Tika und Docker, dass ich mich bei Docker Hub anmelde und einen Zugriffstoken hinterlege. Ohne Vorwarnung. Von jetzt auf gleich. Die fest definierte Version ließ sich schlicht nicht mehr ziehen – nur noch „latest“. Warum? Keine Ahnung. Kein Hinweis, keine Erklärung. Einfach aus. Ende. System ließ sich so nicht mehr pullen.

Tika will nicht mehr – nur latest funktionierte

Paperless selbst ist großartig. Die Idee dahinter ist klasse. Aber wenn ein System in seinem Kern auf vier externe Komponenten angewiesen ist, auf die es selbst keinerlei Einfluss hat, dann ist das kein zuverlässiges Fundament. Das ist Bastelware. Nerd-Spielplatz. Hacker-Setup für den Hobby-Keller. Für produktive Nutzung? Für echte Dokumentensicherheit? Ganz ehrlich: Finger weg. So etwas möchte ich nicht im Einsatz haben, wenn es um meine privaten oder geschäftlichen Dokumente geht. Ein System, das durch eine externe Entscheidung plötzlich nicht mehr funktioniert, verdient kein Vertrauen. Predikat: nicht für den realen Alltag geeignet.

Ganz ehrlich: Genau solche Entwicklungen zeigen mir, wie fragil das Ganze geworden ist. Wenn Projekte plötzlich ihre Lizenz drehen oder Funktionen hinter Mauern verschwinden, dann ist das für mich ein Warnsignal. Meine privaten Unterlagen vertraue ich so einem Konstrukt nicht an. Und geschäftliche Daten schon gar nicht. Ich stelle mir vor, ich baue mein gesamtes Dokumentenmanagement auf einer Kombination wie Paperless, Docker, Redis, Tika und Postgres auf – und dann entscheidet ein Anbieter, die Spielregeln zu ändern. Plötzlich steht mein komplettes System auf der Kippe. Das ist keine digitale Freiheit, das ist ein Risiko. Für mich war das ein Crashkurs in der Kategorie: So macht man es nicht.

Ich muss ehrlich sagen, für mich selbst war das am Ende keine gewaltige Hürde. Ich kenne mich aus, ich kann an den Stellen drehen, an denen man drehen muss, und kriege so ein System wieder ans Laufen. Das ist nicht der Punkt. Aber sobald man öffentlich Kritik äußert oder in einem Forum beschreibt, dass auf einmal etwas nicht mehr funktioniert, kommen sofort die typischen Antworten: „Du musst nur dieses Kommando ausführen“, „Dann hier anpassen“, „Danach dort noch schnell migrieren“, „Export hier, Import da, Cache löschen, Container neu bauen – dann geht’s doch.“ Natürlich funktioniert es dann. Natürlich lässt sich das irgendwie alles reparieren.

Aber genau das ist der Kern des Problems. Das ist nichts, was du jemandem erklären kannst, der einfach nur zuverlässig seine Dokumente verwalten will. Das ist nicht massentauglich, nicht alltagstauglich, und erst recht kein System, das man in produktive Umgebungen stellen kann, wo Fehler keine Option sind. Ich hatte wirklich geglaubt, dass es eine gute Idee sei, Paperless so aufzubauen, dass es jeder nutzen kann. Und es sah ja auch so aus, als würde es funktionieren. Kurzfristig lief es fantastisch. Doch dann kommen solche Überraschungen, plötzlich passt etwas nicht mehr, Container wollen neue Tokens, die Komposition muss ständig nachgebessert werden, und es gibt bis heute keine saubere eingebaute Backup- und Migrationslösung im System selbst.

Leider zu unsicher – finde ich

Da ist für mich der Punkt erreicht, an dem man sagen muss: Das ist kein Werkzeug für den echten Betrieb. Das ist ein Hobbyprojekt, technisch beeindruckend, aber nicht verlässlich genug, um darauf seine digitale Dokumentenwelt aufzubauen. Für Bastler und Enthusiasten ist das okay. Für normale Anwender, für Unternehmen oder jemanden, der einfach Ruhe und Stabilität will, ist es schlicht ungeeignet.

Man muss sich das einfach mal realistisch vorstellen. Heute läuft alles, morgen vielleicht auch noch. Aber was ist in zwei oder drei Jahren? Was, wenn Tika oder Gotenberg plötzlich ihre Lizenz ändern? Was, wenn Docker die Regeln weiter verschärft oder Zugänge beschränkt? Und dann kommt der Tag, an dem der Rechner den Geist aufgibt. Man will seine Dokumente wiederherstellen, alles neu aufsetzen – und plötzlich geht es nicht mehr, weil die Bausteine, auf die das ganze System angewiesen ist, nicht mehr frei zugänglich sind oder sich nicht mehr installieren lassen.

Das ist kein theoretisches Szenario. Genau solche Veränderungen passieren inzwischen ständig. Heute „Open Source“, morgen „Source Available“, übermorgen „nur mit Token und Account“. Und dann steht man da, mit einem Stapel wichtiger Unterlagen und einem System, das sich nicht mehr reproduzieren lässt. Zu viel Abhängigkeit, zu viele Stellschrauben, zu viele externe Faktoren.

Ganz ehrlich: Das ist mir zu heiß. Wer wirklich wichtige Unterlagen hat und langfristig sicher sein will, sollte die Finger davon lassen. Es gibt Ideen, die technisch interessant sind, aber sie gehören nicht in den produktiven Alltag. Paperless in dieser Form ist genau so ein Fall. Für Bastler nett. Für echte Datensicherheit ungeeignet.

Open Source verschiebt sich in die Kommerzrichtung …

Docker und Redis – zwei Namen, die die IT-Welt geprägt haben. Beide standen lange als Synonym für offene Entwicklung, freie Nutzung und die Freiheit, eigene Systeme aufzubauen, ohne an einen Anbieter gebunden zu sein. Genau deshalb wurden sie von Unternehmen, Admins und Entwicklern gern eingesetzt, oft sogar für kritische Systeme. Doch die Zeiten ändern sich. Und mit ihnen der Umgang großer Softwarehäuser mit dem Begriff „Open Source“.

Beginnen wir mit Docker. Als Container-Technologie revolutionierte Docker den Betrieb von Anwendungen, weil plötzlich flexible, portable Umgebungen möglich waren. Die Basis blieb offen, jeder konnte damit arbeiten. Doch im Laufe der Zeit verschob sich das Modell. Docker Desktop wurde zur kostenpflichtigen Lösung, und für professionelle Nutzung gelten heute klare Lizenzbedingungen. Der offene Kern ist weiterhin da. Nur der Alltag in Unternehmen zwingt zunehmend in die kommerziellen Schienen. Wer große Teams managt, Support braucht oder Integrationen erwartet, landet nicht mehr automatisch bei freier Software, sondern bei einem Geschäftsmodell, das die offene Idee nur noch im Fundament trägt.

Und dann ist da Redis. Ein Werkzeug, das wegen seiner Geschwindigkeit und Einfachheit schnell zur Standardlösung für Caching und schnelle Datenzugriffe wurde. Lange war Redis ein Paradebeispiel dafür, wie Community-getriebene Software wachsen kann. Doch auch hier setzte irgendwann das große Umdenken ein. Module bekamen Einschränkungen, die Lizenz wurde angepasst, und plötzlich war nicht mehr jeder frei, Redis nach eigenen Vorstellungen einzusetzen. Der Code blieb sichtbar – aber eben nicht mehr komplett frei. „Source available“ ersetzt wahre Offenheit, und das mit einem klaren Ziel: Kommerzialisierung und Schutz vor Cloud-Anbietern, die Redis als Dienst anbieten könnten, ohne den ursprünglichen Entwicklern etwas zurückzugeben.

Beide Fälle zeigen das gleiche Muster. Erst entsteht ein offenes Technologiewerkzeug, das durch Community-Beiträge und Vertrauen der Entwickler wächst. Dann kommt der Wendepunkt: Die Software wird geschäftlich wertvoll, Unternehmen möchten Kontrolle behalten, Einnahmen sichern und Konkurrenz ausschließen. Transparenz wird zur Fassade, und Open Source verliert Stück für Stück seinen ursprünglichen Charakter.

Das bedeutet nicht, dass diese Entscheidungen falsch oder unverständlich sind. Firmen müssen Geld verdienen, und erfolgreiche Projekte haben Kosten, Teams, Infrastruktur. Doch es zeigt eine neue Realität: Wer heute auf freie Software setzt, braucht ein wachsames Auge. Nicht jedes Open-Source-Label hält, was es verspricht. Und nicht jeder sichtbare Quellcode bedeutet Freiheit.

Für alle, die planen, Software langfristig einzusetzen, gilt deshalb ein einfacher Leitsatz: Nicht nur den Code anschauen, sondern auch die Lizenz. Nicht nur das Versprechen prüfen, sondern das Geschäftsmodell dahinter. Wahre Offenheit erkennt man daran, dass sie bleibt – auch wenn die Software erfolgreich wird. Docker und Redis erinnern uns daran, dass „frei“ und „sichtbar“ nicht dasselbe sind.

Programm unter MIT Lizenz veröffentlich – zum Quellcode Download

Ich habe das Programm auf Codeberg.org Git unter der MIT Lizenz veröffentlicht. Ein jeder kann das Programm Klonen und verwenden: git clone https://codeberg.org/ComputerRalle/paperless-backup-program.git

Paperless Backup Programm Version 5.25.10.100 Download