Sie brauchen einen TYPO3-fähigen Server, das öffentliche Provider-Repo mit dem Docker-Stack und ein paar Stunden Setup-Zeit. Wer mit TYPO3 schon einmal gearbeitet hat, ist in einem halben Tag durch. Wer nicht — der nimmt einen TYPO3-Dienstleister oder bucht uns für ein Onboarding.
Haltung
Die grants-Erweiterung ist Open Source. Unter AGPL-3.0-or-later.
Der Quellcode wird auf GitLab veröffentlicht — frei einsehbar, frei prüfbar, frei nutzbar. Auch zum Selbsthosten. Wer Grantifex bei uns betreiben lässt, zahlt für Service. Wer selbst hostet, zahlt nichts an uns. Beides ist legitim.
IWarum Open Source
Förderwesen ist öffentliche Sache.
Öffentliche Organisationen und Stiftungen erwarten — zu Recht — dass die Werkzeuge, mit denen sie Steuergeld oder Stiftungsvermögen verteilen, nachprüfbar sind. Wer entscheidet über Bewilligungen? Wie wird gerechnet? Wer hat welchen Zugriff?
Closed-Source-Software auf US-Servern ist mit dem Anspruch europäischer Datensouveränität schwer zu vereinbaren. Open Source löst das — nicht weil es ideologisch besser ist, sondern weil Nachvollziehbarkeit aus dem Quellcode folgt, nicht aus einem Whitepaper.
Es ist kein Zufall, dass die EU-Kommission in ihrer Open Source Strategie 2020–2023 Behörden ausdrücklich auffordert, Open-Source-Lösungen zu bevorzugen, wo es technisch und wirtschaftlich vertretbar ist.
„Public money should produce public code. If it is public money, it should be public code as well." Free Software Foundation Europe — Public Money, Public Code
publiccode.eu — Public Money, Public Code, Initiative der FSFE. EU Open Source Strategy — Strategie der Europäischen Kommission.
IIWas AGPLv3 bedeutet
In einfacher Sprache: was Sie dürfen — und was die Lizenz verlangt.
Die AGPL — Affero General Public License Version 3 — ist eine der stärksten Open-Source-Lizenzen. Sie erlaubt fast alles. Sie verlangt eine einzige Gegenleistung.
Vier Rechte. Bedingungslos.
- Den Code nutzen — privat, kommerziell, in jedem Kontext. Für jeden Zweck, ohne Anmeldung oder Genehmigung durch uns.
- Den Code untersuchen und an Ihre Bedürfnisse anpassen. Lesen Sie, verstehen Sie, ändern Sie. Mit oder ohne unsere Hilfe.
- Den Code weiterverteilen — Kopien an Dritte geben. Original oder verändert, gegen Bezahlung oder kostenlos. Ihre Entscheidung.
- Den Code selbst betreiben — auf Ihrer eigenen Infrastruktur. Eigene Domain, eigene Server, eigenes Branding. Ohne uns zu fragen.
Eine Gegenleistung. Genau eine.
- Wer den Code verändert und als Online-Dienst anbietet, muss die Änderungen offenlegen. Auch dann, wenn die geänderte Version nie als Software ausgeliefert wird — sondern nur per Browser zugänglich gemacht. Das ist die berühmte „Affero-Klausel".
- Die Offenlegung erfolgt unter derselben Lizenz. Damit Verbesserungen für alle nutzbar bleiben — auch wenn ein Konzern den Code übernimmt.
- Lizenz- und Copyright-Hinweise bleiben erhalten. Beim Weiterverteilen wird die Herkunft des Codes ausgewiesen.
So bleibt die Software für alle nutzbar — auch wenn ein Konzern sie übernimmt. Wer fundiert weiterlesen will: der vollständige Lizenztext liegt bei der Free Software Foundation.
IIIVeröffentlichungsplan
Wann der Code veröffentlicht wird — konkret und ehrlich.
Die grants-Erweiterung wird mit dem Abschluss des ersten zahlenden Vertrags unter AGPL-3.0-or-later auf GitLab veröffentlicht. Voraussichtlich im Laufe von 2026.
Plattform produktiv
Funktionsumfang vollständig im Einsatz bei ersten Pilot-Stiftungen.
Erster Vertrag
Code-Audit, Lizenz-Header, Dokumentation, Repo-Aufbau auf GitLab.
Public Repository
GitLab geht öffentlich. Issue-Tracker, Pull-Requests, Diskussionen offen.
TER-Listing
Aufnahme in extensions.typo3.org — dem offiziellen TYPO3 Extension Repository.
Wir kündigen die Veröffentlichung hier an, sobald es so weit ist. Erinnerung gewünscht? Newsletter abonnieren oder dem GitLab-Repo einen Stern geben — letzteres geht selbstverständlich erst dann.
IVWas Open Source nicht heißt
Open Source heißt nicht „kostenlos im Wert".
Open Source heißt: der Code ist frei. Der Service ist Arbeit, die bezahlt werden muss.
Wer die Zeit und das Know-how hat, kann selbst hosten — und zahlt nichts an uns. Wer das nicht hat oder will, zahlt Grantifex dafür, dass jemand anderes diese Arbeit erledigt. Beides ist legitim. Beides hat unseren Respekt.
Der Preis bei uns deckt: Hosting, Backups, Updates, Sicherheits-Patches, Wartung, Weiterentwicklung, persönlichen Support. Was nicht im Preis steckt: Ihre eigene Arbeit, wenn Sie selbst hosten.
Der Code
- Quellcode der grants-Erweiterung
- Dokumentation & Setup-Anleitung
- Issue-Tracker & Diskussionen
- Pull-Requests & Code-Reviews
Der Service
- Hosting in Deutschland
- Updates & Sicherheits-Patches
- Tägliche Backups
- Persönlicher Support
- Weiterentwicklung mit Roadmap
VSelbst hosten
Eine Aussicht — keine fertige Anleitung. Noch nicht.
Self-Hosting nehmen wir ernst. Mit der Veröffentlichung kommt eine vollständige Schritt-für-Schritt-Anleitung im Repo. Bis dahin: das ist, was Sie brauchen werden.
# 1. Provider-Repo klonen $ git clone https://gitlab.com/grantifex/provider.git $ cd provider # 2. Konfiguration anlegen $ cp .env.example .env $ editor .env # Domain, DB, Mail eintragen # 3. Docker-Stack starten $ docker compose up -d ✓ typo3 running ✓ mariadb running ✓ redis running ✓ mailcatcher running # 4. Initiales Setup $ docker compose exec typo3 typo3 grants:install --admin [email protected] → Portal bereit unter https://grantifex.local → Backend unter https://grantifex.local/typo3 # Skizze. Endgültige Anleitung folgt # mit dem Repo-Release in 2026.
VIIm TYPO3-Ökosystem
Eines der ausgereiftesten Open-Source-CMS Europas.
Grantifex ist kein Solitär. Es lebt in einem Ökosystem mit aktiver Community, eigenen Konferenzen, klaren Standards und einem etablierten Marktplatz für Erweiterungen.
Die grants-Erweiterung wird im offiziellen TYPO3 Extension Repository (extensions.typo3.org) gelistet, sobald sie veröffentlicht ist. Damit findet sie jeder TYPO3-Entwickler — auch ohne uns zu kennen.
VIIMitmachen
Drei Wege, Grantifex besser zu machen.
Wer Lust hat beizutragen, kann das tun. Pull-Requests werden geprüft und integriert, wenn sie zur Roadmap passen.
Bug-Report
Sie finden einen Fehler? Issue auf GitLab anlegen — mit Schritten zur Reproduktion und betroffener Version. Wir bestätigen innerhalb von zwei Werktagen.
GitLab Issue · öffentlichFeature-Wunsch
Sie vermissen eine Funktion? Diskussion auf GitLab eröffnen. Wenn der Wunsch zur Roadmap passt, planen wir sie ein. Wenn nicht, sagen wir ehrlich warum.
GitLab DiscussionCode-Beitrag
Sie können das selbst bauen? Fork, Branch, Pull-Request. Bei größeren Änderungen vorher kurz abstimmen — sonst entwickelt jemand parallel an demselben Bereich.
Pull-Request · CONTRIBUTING.mdSie brauchen eine Funktion dringend?
Sie können die Entwicklung als Sponsoring beauftragen. Wir bauen das Feature gegen Aufwand — und es landet anschließend in der AGPL-Codebasis. So bezahlen Sie einmal, profitieren Sie selbst, und alle Grantifex-Instanzen bekommen die Funktion mit.
VIIIVertrauen statt Versprechen
Bis der Code öffentlich ist, müssen Sie uns vertrauen. Das ist nicht ideal.
Und wir wollen es nicht so stehen lassen.
Wir wissen, dass das ein Vertrauensvorschuss ist. Eine Erweiterung, die offiziell unter AGPL stehen wird — aber noch nicht öffentlich liegt. Das ist die Realität von früher Phase, nicht der Endzustand. Wir sind transparent darüber.
Sobald der Code veröffentlicht ist, fällt dieser Vorbehalt automatisch weg. Bis dahin bieten wir eine Brücke an: Code-Review unter NDA.
Lieber selbst prüfen, bevor Sie unterschreiben?
Test-Instanz unter Ihrer Subdomain, NDA-Einsicht in den Code, persönliches Gespräch. In dieser Reihenfolge — oder in einer anderen.