An Entwickler:innen, die an etwas Bleibendem mitbauen wollen
Wer abends Code schreibt, will meist nicht für die nächste Werbe-Plattform optimieren. Wir bauen Werkzeuge, die niemandem gehören und niemandem verkauft werden können — und freuen uns über jede ernsthafte Mitarbeit.
Schmerz
- Open-Source-Beiträge zu Projekten unter US-Firmen-CLA enden häufig als unbezahlte Vorarbeit für einen späteren Exit.
- Viele „Indie"-Projekte werden nach drei Jahren an einen größeren Anbieter verkauft, dessen Roadmap die Beitragenden nie unterschrieben haben.
- Open-Source ohne nachhaltige Infrastruktur kollabiert, wenn eine Person ausbrennt. Es gibt selten eine Trägerstruktur, die den Service-Betrieb wirklich übernimmt.
Angebot
- Pull Requests fließen in eine Code-Basis, deren statutarisch festgelegter Eigentümer ein Schweizer Verein in Gründung ist — kein Spätverkauf möglich.
- Stack ist konservativ und langlebig: TypeScript + Hono + Bun für Services, Svelte 5 + Astro für Web, SwiftUI nativ, Postgres, Drizzle, MinIO. Keine Framework-Karussells.
- Plattform-Backbone ist da: Auth (JWKS), Credits, Storage, Federation-Bus, Cross-App-Timeline, Event-Sourcing. Wer eine App bauen will, muss nicht das Backend neu schreiben.
- Code in 18 Repos auf git.mana.how, alle dokumentiert, die meisten mit CLAUDE.md-Onboarding-Notizen.
- Eigene npm-Registry (npm.mana.how) für interne Pakete, eigene Container-Pipeline auf Mac Mini — wer mit eigenen Apps andockt, hat die Infrastruktur, die sonst Geld kostet.
Es gibt zwei Sorten Open-Source-Arbeit, die unbefriedigend sind: die für ein Projekt, das später an Salesforce verkauft wird, und die für ein Projekt, das nach drei Jahren ohne Pflege im Repo zerfällt. Beides ist verlorene Lebenszeit.
Was wir versuchen, ist ein dritter Weg. Eine Trägerstruktur (der Verein), die den Service-Betrieb dauerhaft übernimmt, und ein Statut, das den Verkauf ausschließt. Der Code bleibt offen, die Infrastruktur bleibt im Verein, die Arbeit bleibt sichtbar — auch in zehn Jahren, falls die Vereinsführung mal komplett wechselt.
Was es konkret zu tun gibt: Plattform-Services härten (Backups, Off-Site, Observability), Apps polishen (PWA-Installation, Offline-Sync, Accessibility), Übersetzungen koordinieren, Cross-App-Brücken bauen, Dokumentation strukturieren. Wir haben einen Devlog mit ehrlichen Wochenberichten, der zeigt, was gerade dran ist, und einen offenen Issue-Pool auf git.mana.how.
Was es nicht zu tun gibt: an Wachstums-Metriken arbeiten, die hier niemand misst. Es gibt kein „Engagement-Team” und keine Conversion-Optimierung, die wir uns ausgedacht hätten, um eine Geschäftszahl zu retten. Was es gibt, ist die ehrliche Arbeit am Werkzeug.
Grundsätze in diesem Pitch
Probleme, die diese Gruppe besonders treffen
Industrie-Diagnosen mit Belegen Dritter — die strukturellen Muster, die diesen Pitch überhaupt nötig machen.
- Enshittification — Software wird über Zeit schlechterWenn Wachstum, Werbung und Aktionärsrendite den Takt geben, verschlechtert sich jedes erfolgreiche Software-Produkt zwangsläufig.
- App-Store-Tribut — 30 % an den GatekeeperWenn zwei US-Konzerne entscheiden, welche Software auf den Geräten landet, wird der Verteilungs-Kanal selbst zum Engpass — und 30 % Provision sind nur die sichtbare Seite davon.
Lösungen, die diesen Pitch tragen
Architektur-, Protokoll-, Policy- und Governance-Entscheidungen. Keine Marketing-Versprechen, sondern Eigenschaften, die in der Struktur sitzen.
- Föderation statt Lock-InWenn der Daten-Austausch über veröffentlichte Protokolle läuft, ist Verlassen nicht teurer als Bleiben — das nimmt dem Enshittification-Mechanismus seinen Hebel.
- Event-Sourcing als Daten-ArchitekturJede Änderung ist ein Event. Apps lesen Projektionen, schreiben aber nur Events — und der Ledger ist die einzige Quelle der Wahrheit.
- Local-First + Login-OptionalDas energie-effizienteste Rechenzentrum ist die CPU, die ohnehin schon in der Hosentasche liegt — und kein Konto ist die beste Privatsphäre.
- PWA vor Native — Web-App, wo es gehtEine gute PWA ist heute auf Android und Desktop praktisch ununterscheidbar von einer nativen App — ohne Apple/Google als Distributions-Mittler.
Wer wir nicht sind — und was offen ist
Nicht für
- Entwickler:innen, die Equity oder spätere Anteile am Erfolg suchen — die gibt es nicht, der Verein hat keine.
- Wer auf Move-Fast-Break-Things und tägliche Framework-Wechsel steht. Wir bauen konservativ, mit Tests, mit Doku, mit Migrations-Pfaden.
Offene Punkte
- Onboarding für externe Beiträger:innen ist noch dünn. CLAs, Code-of-Conduct, Review-Prozess sind in Arbeit, nicht alle Repos haben CONTRIBUTING.md.
- Bezahlte Mitarbeit ist mittelfristig denkbar (Förder-Mittel, s. /pitches/foerder-stiftungen), aktuell aber nicht finanziert.
- Issues-Tracker liegt auf Forgejo (git.mana.how), nicht auf GitHub. Discoverability ist niedriger als nötig.
Ihr passt nicht hier rein, aber an irgendeiner Stelle? Schaut auf /pitches die anderen Zielgruppen an oder schreibt direkt — der Katalog wächst.