OpenOutreach: Lead-Generierung als selbst gehostete CLI mit zwei Kindprozessen

Welches Problem OpenOutreach löst und für wen

Der Ausgangspunkt ist eine Liste, die man sonst selbst zusammenstellt. OpenOutreach dreht das um: Der Input ist ein Satz über das eigene Produkt, der Output ist eine bewertete Person samt Begründung. Die README formuliert den Unterschied zu einem Cold-Mail-Sequencer so, dass man keine Liste mitbringt, und zu einer Lead-Datenbank so, dass das Ergebnis keine Zeilen sind, sondern ein Urteil pro Person in lesbarer Sprache. Wer eine Sequencer-Kampagne fährt, kennt das Problem: Die Liste ist der teuerste und fehleranfälligste Teil, und niemand kann später sagen, warum eine Adresse überhaupt drin war. OpenOutreach verschiebt die Arbeit von der Listenbeschaffung zur Beschreibung der Zielgruppe. Die Zielgruppe sind technisch versierte Anwender: Einzelpersonen, kleine Teams oder Agenten, die eine CLI aufrufen können und keine Weboberfläche brauchen. Der README betont ausdrücklich, dass es keinen Social-Network-Account und kein Scraping gibt, also auch kein Konto, das gesperrt werden könnte. Das ist eine bewusste Einschränkung, keine Nebenbemerkung: Wer Reichweite über LinkedIn oder ähnliche Netzwerke sucht, ist hier falsch.

Drei Pakete, eine Pipe: die Architektur

OpenOutreach ist laut README ein Orchestrator, kein Monolith. Zwei eigenständige Programme übernehmen die Arbeit: OpenOutFind für Discovery, Qualifizierung, Anreicherung und das CRM, OpenOutSend für den Versand, das Postfach und die Send Guards. Beide behalten eigenen Konsolenskript, eigenes Settings-Modul und eigene Testsuite. Das ist ein ungewöhnlicher Schnitt, weil ein Bündel die Kinder normalerweise zu Bibliotheken degradiert. Der Kontrakt zwischen ihnen ist öffentlich: outfind find 50 --json | outsend. openoutreach run ist dieselbe Pipe in einem Prozess, wobei die JSON Lines laut README weiterhin die Grenze überqueren, nur eben durch einen Puffer. Der Autor begründet das damit, dass ein zweiter, ungetesteter Pfad zwischen denselben Programmen den öffentlichen Pfad zur Lüge machen würde. Dieses Argument ist nachvollziehbar, hat aber einen Preis: Die Orchestrierung kann nicht mehr leisten als die Summe der beiden Kinder, und Fehlerdiagnose verteilt sich auf drei Pakete mit drei Versionsständen. Der Assistent liegt nur in OpenOutreach, weil die Kinder agent-first sind: Sie lesen ihre Konfiguration bei jedem Lauf aus OPENOUTFIND_* beziehungsweise OUTSEND_* und merken sich nichts. Für Skripte ist das richtig, für Menschen nicht.

Installation und die Kommandos im Alltag

Die Installation ist ein Befehl: uv tool install openoutreach, danach startet openoutreach den Assistenten, falls nötig, sucht Leads, kauft eine verifizierte Arbeitsadresse und verschickt die Mail. Wer nur die Einrichtung will, ohne etwas auszugeben, nutzt openoutreach init. Die beiden langen Textfelder lassen sich aus Dateien laden: openoutreach init --product-docs product.md --target target.md. Das ist der Punkt, an dem man die Zielgruppenbeschreibung versionieren kann, statt sie bei jedem Lauf neu zu tippen. Für die Suche gibt es openoutreach find 10, das laut README kostenlos ist und nicht ausgeben kann, sowie openoutreach find 10 emails, wobei jede Adresse einen Credit kostet. openoutreach send verschickt, was bereits gespeichert ist, openoutreach status zeigt Konfiguration, Blockaden und Zähler. Alles liegt in ~/.openoutreach, und die angeforderte Zahl ist immer mehr als der vorhandene Bestand, sodass ein zweiter Lauf fortgesetzt wird statt von vorn zu beginnen. Wer den Finder allein will, kann uvx --from openoutfind outfind find 10 aufrufen, den Sender entsprechend uvx --from openoutsend outsend send. Die Trennung von kostenlosem find und kostenpflichtigem find emails ist das klarste Sicherheitsnetz im ganzen Werkzeug.

Die CSV-Ausgabe und was sie für die Weiterverarbeitung bedeutet

Der Finder liefert eine Datei, nicht nur einen Bildschirmtext. openoutreach find 10 emails > leads.csv läuft, bis zehn weitere Leads mit Adresse vorliegen, gibt alle vorhandenen Leads als CSV aus und beendet sich. Exit 0 bedeutet, dass die angeforderte Menge erreicht wurde; ein vorzeitiges Ende gibt trotzdem die Zeilen aus und nennt den Grund. Die Spalten sind email, first_name, last_name, company, title, website, linkedin_url, reason, lead_id, qualified_at. Zwei Dinge fallen auf. Erstens enthält die Ausgabe eine Spalte reason, also die Begründung, warum eine Person als passend eingestuft wurde. Das ist der eigentliche Unterschied zu einer Lead-Datenbank, denn die Begründung ist überprüfbar und korrigierbar: Wer mit einem Urteil nicht einverstanden ist, ändert die Produktbeschreibung, nicht die Liste. Zweitens ist die Ausgabe idempotent gedacht, der geschriebene Stand ist immer die aktuelle Wahrheit. Das macht die Datei anschlussfähig an Werkzeuge, mit denen man ohnehin versendet. Das README bricht an dieser Stelle ab, daher lässt sich nicht bestätigen, ob die Spaltennamen einem bestehenden Importformat entsprechen. Wer darauf angewiesen ist, muss das vor dem ersten Lauf prüfen.

Der Credit-Verbrauch ist die eigentliche Kostenstelle

OpenOutreach selbst ist quelloffen, die Daten kommen aber aus einem lizenzierten Anbieter, und Adressen werden mit Credits bezahlt. Die README ist hier ungewöhnlich deutlich: openoutreach find 10 kostet nichts, openoutreach find 10 emails kostet einen Credit pro Adresse, und openoutreach run 5 gibt höchstens fünf Credits aus. Wer das ignoriert, kann in einem einzigen Aufruf ein Budget verbrauchen, ohne dass eine einzige Mail geöffnet wurde. Die Dokumentation nennt keine Preise, keine Credit-Obergrenze und kein Kontingent, deshalb lässt sich nicht abschätzen, was ein Lauf in Euro kostet. Das ist keine Kleinigkeit, sondern die zentrale wirtschaftliche Unbekannte des Projekts. Positiv ist, dass die Trennung im Kommando selbst liegt und nicht in einer Konfigurationsdatei, die man falsch setzen kann. Der Claude-Code-Skill soll laut README wissen, welche Flags Credits kosten und welche nicht, und niemals eine Adresse kaufen, die nicht angefordert wurde. Das ist eine Zusage über das Verhalten des Skills, kein Nachweis über die Abrechnung des Anbieters. Wer das Werkzeug produktiv einsetzt, sollte die Credit-Abrechnung außerhalb von OpenOutreach mitführen.

Grenzen: wo OpenOutreach das falsche Werkzeug ist

Der Versand läuft über das eigene Postfach, und das ist die zweite Einschränkung. Wer glaubt, damit automatisch zustellbar zu sein, irrt: Reputation, SPF, DKIM und DMARC des eigenen Mailservers bleiben das Problem des Betreibers, und die README behandelt das nicht. Ein weiterer Punkt ist die Datenquelle. OpenOutreach findet niemanden ohne den lizenzierten Anbieter; es ist kein Scraper und soll keiner sein. Wer Unternehmen außerhalb der Abdeckung dieses Anbieters erreichen will, bekommt keine Treffer, und zwar unabhängig davon, wie gut die Produktbeschreibung ist. Drittens die Oberfläche: Es gibt keine. Wer ein Vertriebsteam ohne Terminal-Kenntnisse führen will, braucht eine eigene Schicht über der CSV. Viertens die Qualifizierung selbst. Das Urteil stammt von einem LLM, das die Produktbeschreibung gegen die gefundenen Profile liest. Es gibt kein Label, keine Konfidenz und keine Kennzahl für die Trefferquote, jedenfalls nicht im vorliegenden Material. Wer eine belegbare Precision braucht, muss sie selbst messen, indem er die Spalte reason gegen die tatsächliche Antwortquote hält. Für Massenversand an gekaufte Adressen ist das Werkzeug ebenfalls nicht gedacht, weil jede Adresse einzeln bezahlt wird.

Alternative: Instantly, Lemlist oder ein eigener Sender

Der naheliegende Vergleich sind Sequencer wie Instantly oder Lemlist. Der Unterschied liegt nicht im Funktionsumfang, sondern im Startpunkt: Diese Werkzeuge erwarten eine fertige Liste, die man aus einem Verzeichnis exportiert oder kauft, und sie optimieren danach den Versand über mehrere Stufen, Postfach-Rotation und Zustellbarkeitsprüfung. OpenOutreach macht das Gegenteil. Es beginnt bei der Beschreibung und endet bei einer bewerteten Person, und der Versand ist ein einzelner Aufruf aus dem eigenen Postfach. Wer bereits eine gute Liste und mehrere Postfächer hat, gewinnt durch OpenOutreach wenig und verliert die Send-Infrastruktur der Sequencer. Wer umgekehrt keine Liste hat und nicht weiß, wen er überhaupt anschreiben soll, gewinnt die Qualifizierung, zahlt aber pro Adresse. Eine zweite Alternative ist der Eigenbau: outfind find 50 --json | outsend ist ausdrücklich als offene Schnittstelle gedacht, sodass ein eigener Producer oder Receiver angehängt werden kann. Wer bereits einen Sender betreibt, kann nur OpenOutFind nutzen und die CSV in die bestehende Pipeline einspeisen. Das ist der günstigste Einstieg, weil er den Teil überspringt, den man schon hat.

Wartung, Lizenz und was vor dem ersten Lauf zu klären ist

Das Repository steht unter GPL-3.0, nicht unter einer permissiven Lizenz. Wer OpenOutreach intern einsetzt, kann das tun. Wer es verändert und weitergibt, muss die Bedingungen der GPL-3.0 einhalten, also Quellcode und Lizenz mitliefern. Wer es in ein eigenes Produkt einbetten will, sollte das vorher mit einer Rechtsabteilung klären; eine rechtliche Einschätzung ist das hier nicht. Zur Wartung liefert das Material wenig: Es gibt keine abgerufenen Releases, der letzte Push liegt bei September 2026, und das README bricht mitten im Abschnitt über die CSV-Ausgabe ab. Das ist ein Signal für die Reife der Dokumentation, nicht für die Qualität des Codes, aber es bleibt ein Signal. Die Architektur mit drei Paketen bedeutet drei Versionsstände, die zusammenpassen müssen, und die öffentliche Pipe ist der einzige Vertrag zwischen ihnen. Prüfe vor dem ersten produktiven Lauf mit openoutreach init, welche Felder der Assistent verlangt und welche davon in ~/.openoutreach landen. Prüfe danach mit openoutreach find 10 ohne das Argument emails, ob die Treffer zur Zielgruppe passen, bevor der erste Credit ausgegeben wird. Und prüfe, ob OpenOutSend an ein Postfach angebunden werden kann, dessen Zustellbarkeit du kontrollierst, denn das entscheidet darüber, ob die gefundenen Adressen überhaupt erreichbar sind.

Redaktionelles Fazit

Wer eine eigene Pipeline aus Skript oder Agent heraus steuert und die Credit-Kosten pro gekaufter Adresse akzeptiert, findet in OpenOutreach ein transparentes Werkzeug mit klarer Schnittstelle. Wer keine kostenpflichtige Datenquelle anbinden will oder eine grafische Oberfläche für ein Vertriebsteam braucht, sollte es nicht einsetzen. Prüfe zuerst mit openoutreach init, welche Felder der Assistent verlangt, und ob dein Lizenzmodell die GPL-3.0-Weitergabe eigener Änderungen erlaubt.

Offizielle Quellen

1. eracle/OpenOutreach on GitHub
2. Issues
3. License: GPL-3.0
4. Project website
5. README