Revision 591: Tiptap

Transcript

[0:00] Ist das kostenfrei zu benutzen? Genau. Also TipTap, das Editor-Framework selbst, ist Open Source unter MIT-Lizenz.
Wir waren dann so ein bisschen nach drei Jahren müde geworden von dem Agenturgeschäft und wollten einfach eigene Produkte bauen und selber sozusagen die Seite wechseln des Spielfeldes von Agentur zu Produkt.
Das Bezahlmodell, wie habt ihr das gemacht? Wenn du Nice-to-have-Features hast, für die du dann am Ende Geld nehmen möchtest, dann wird es wahrscheinlich deutlich schwerer werden, dafür im Monat einen Abo-Preis zu verlangen, als wenn du wirklich Schmerzen löst mit den Sachen, die du gegen Geld anbietest.

[0:37] Music.

[1:02] Revision 591.
Kennst du das auch? Du willst mit einer neuen Technologie starten, aber das Internet ist zu voll mit wirrem Content in verschiedenster Qualität? Du suchst kompaktes Wissen, was dich direkt produktiv macht, mit echter Erfahrung von Experten und Expertinnen, die für deine akuten Fragestellungen da sind? Dann solltest du mal im TrainerInnen-Netzwerk von Workshops.de vorbeischauen. Hier findest du eine Community aus über 80 TrainerInnen, welche gemeinsam Material erstellen, sich gegenseitig unterstützen und weiterbilden, um möglichst nachhaltige und hochqualitative Weiterbildungsangebote zu schaffen. Es gibt, Sowohl Intensivschulungen über mehrere Tage, als auch Masterclasses, welche durch über einige Monate unterstützt.

[1:59] Bist du auf der Suche nach einer qualitativen Weiterbildung im Bereich Webentwicklung?
Oder möchtest du dich selbst als Trainerin einbringen?
Dann bist du bei workshops.de genau richtig. Schau einfach mal vorbei für alle Informationen.
Wir freuen uns auf dich! Hallo und herzlich willkommen beim Working Draft.

Revision 591: Tiptap

https://workingdraft.de/591/

[2:27] Wir sind heute zu dritt. Mit mir vom Team dabei ist der Hans. Hallo Hans. Hallo.
Und wir haben wieder einen Gast mit am Start und zwar den Philipp Isig. Hallo Philipp, du warst noch nie bei uns. Stell dich doch gerne mal vor, wer du bist.
Hallo ihr zwei. Ich bin Philipp und bin Co-CEO und Co-Founder von TipTap.

[2:48] Magst du gleich mal darauf einsteigen, was denn TipTap ist? Wir hatten schon mal eine Revision drüber. Das war die 395, die haben wir nochmal rausgekramt. Aber für die vielleicht wenigen Personen, die es vielleicht noch nicht gehört haben, erzähl gern nochmal, was das Produkt ist.
Ja, sehr gerne. Ich glaube, die Revision hattet ihr mit dem anderen Philipp. TipTap ist ein Headless Editor Framework und damit kannst du eben Rich-Text-Content-Editoren entwickeln, die du in deiner eigenen Applikation brauchst.
Das heißt, wir sind ein Developer-Tool.
Und du als Frontend-Developer nutzt uns am Ende, um eine App wie Notion zum Beispiel oder Google Docs zu bauen.

[3:29] Ja, TippTap habe ich ja auch schon in Einsatz, genau wegen diesem Headless-Ansatz.
Ich denke, den Headless-Ansatz kennen jetzt mittlerweile doch schon viele Frontend-Developer da draußen, gerade bei Storyblog und ich glaube Contentful, die auch diese Ansätze verfolgen.
Was bedeutet denn bei euch im Rahmen eines Rich-Text-Editors, dass es headless ist?
Ja, lustiges Storyblock nutzt im Übrigen auch TipTap tatsächlich. Headless bedeutet bei uns, dass wir eben keine UI und kein klassisches HTML, CSS-Markup mitliefern. Du hast also die komplette Freiheit als Fontend-Developer tun und lassen zu können, was du möchtest.
Und zusätzlich zu dem Headless Approach sind wir dann eben auch noch framework-agnostisch, das heißt, du kannst das Ganze mit React oder Vue.js oder Vanilla JavaScript benutzen. Und wir haben eben noch die, und das hast du vielleicht auch schon benutzt, Extension-Architektur. Das bedeutet, du bist in der Lage, selber Erweiterungen für den Editor zu entwickeln und dir damit am Ende einen Interface zusammenzubauen, was komplett auf deine Bedürfnisse als Developer oder Produktteam eben angepasst werden kann und hast keine fertige All-in-One-Lösung, die du dann umfangreich irgendwie auseinandernehmen und wieder zusammenbasteln musst.

[4:52] Du hast auch grad schon das Stichwort Notion gesagt. Wenn man sich jetzt mal so die Editoren draußen anschaut, ich denk da irgendwie so an so einen CK-Editor und TinyMCE und noch so einen Trixx-Editor.
Immer, wenn ich mir die angeschaut hab, dann kam da, glaub ich, auch schon so eine UI mit.
Und das war dann meistens so diese Toolbar, die da so on top hängt.
Da sind mein Bold und mein Italic-Button dran.
Notion ist ja schon, ob man's jetzt mag oder nicht, sei da hingestellt, Aber ein viel freierer Ansatz.
Das fühlt sich hier oft an wie so ein weißes Canvas.
Und dann kommt da eher so ein fliegendes Menü, wenn ich Slash tippe oder wenn ich Punkt schreibe, kommt AI.
Das heißt, mit Headless hab ich dann bei euch auch diese Möglichkeiten, dass ich da jetzt nicht diese Toolbar oben bobbeln hab, sondern ich hab tatsächlich auch irgendwelche fliegenden Menüs.
Genau. Also, das kannst du ja im Endeffekt selber zusammenbauen als Frontend-Developer, wenn du das so haben möchtest.
Notion ist tatsächlich immer so der Benchmark für viele Entwickler und Entwicklerinnen, auch auf unserem Discord-Server, wo es immer heißt, ich brauche Notion-like Behavior, also das ist schon fast so ein Synonym geworden.
Wir sagen immer lieber Block-based, weil es für uns eher Blöcke sind, Content-Blöcke, aber Notion-like ist eigentlich so das Top-1-Feature, was alle nachfragen.
Tatsächlich ist es so, weil du auch so ein bisschen gerade erwähnt hattest, die UI-Leiste oben mit deinem Bold, Italic und ein bisschen von Formatierung.

[6:20] Da haben wir ja schon gesehen in den letzten Jahren, dass immer mehr Anwendungen im Endeffekt komplexere UI für die Erstellung von Inhalten benötigen.
Und dass der klassische Editor immer mehr verschmilzt mit der gesamten Applikations-UI zu einer Anwendung.
Wo Notion jetzt sicherlich das populärste Beispiel ist, aber auch vielleicht andere Produktivitätstools, wo du einfach merkst, dass Editor und Applikations-UI gar nicht mehr so strikt auseinanderzuhalten sind wie früher noch.
Und ich glaube, was Notion und Google, vielleicht dann auch mit Google Docs, das ist ja auch eine sehr umfangreiche Anwendung, wo du Inhalte erstellen kannst, eben geschafft haben, ist, dass sie mit Hunderten von Mitarbeitenden solche Produkte seit Jahren gestalten und programmieren und immer besser verbessern, oder immer weiter verbessern und eben die Messlatte unfassbar hoch hingen für so eine User Experience.
Und dass kleine Teams mit wenig Budget, also zum Beispiel ganz junge Startups oder Solo-Freelancer, die ein kleines Produkt bauen wollen oder auch Unternehmen, die gerade erst anfangen, so ein Produkt zu entwickeln, für die ist es dann eben schwer bis unmöglich, diese Messlatte zu erreichen.
Und das erschwert so ein bisschen den Wettbewerb und damit verhindert es auch ja eigentlich die Auswahl für End-User ein bisschen am Produkt, weil die immer so im Kopf haben, ich nutze sowas wie Notion oder Google Docs und will eigentlich diese UX, diese UI auch bei anderen Anwendungen haben.

[7:42] Und mit TipTap haben wir so ein bisschen, glaube ich, ohne es wirklich gewusst zu haben, am Ende durch die Architekturentscheidungen, ja, ich sag mal so den Editor-Markt liberalisiert und dafür gesorgt, dass jetzt plötzlich auch viele Einzelteams, kleine Development-Teams eben in kurzer Zeit so eine Anwendung entwickeln können.
Du hast ja schon viele wahre Punkte gesagt, eben gerade mit der Messlatte.

[8:07] Die haben da natürlich für Jahre dran gearbeitet. Aber wir haben auch gemerkt, also wir hatten ja auch bei Savvy Rich-Text-Editoren und die anfragen, bevor die überhaupt von Kunden und Kundinnen kamen, kamen die schon intern aus dem Team, so, ich möchte, gut, Build, Drag & Drop war jetzt noch irgendwie drin, aber ich möchte da draufklicken und dann möchte ich, dass das machen.
Und ich hab mal versucht, so Workarounds zu machen, mit CSS einfach, dass zumindest, wenn ich über die Seite scrolle, dass diese Toolbar irgendwie halt oben kleben bleibt.
Aber danach war ich so machtlos an den Editoren, die ich in Verwendung hatte, weil es nicht mehr weiterging.
Weil ich einfach keine API, keine Schnittstelle hatte und dran gebunden war.
Konnten teilweise noch nicht mal Icons oder SVGs austauschen, warum auch immer ein Bold-Button ein SVG haben musste.
Aber ich konnte es teilweise nicht austauschen. Und damit sagst du natürlich sehr wichtige Punkte.
Allerdings bedeutet das auch, damit das vor allem so kleine Start-ups verwenden können, ist das kostenfrei zu benutzen?
Genau, also TipTap, das Editor-Framework selbst, ist Open Source unter MIT-Lizenz.
Das kannst du dir sofort auf npm herunterladen. Und das, was am Ende Geld kostet, sind im Endeffekt separate Services, die du dazu buchen kannst, die im Endeffekt, ja.

[9:29] Daten im Backend weiter verarbeiten.
Weil das ist, glaube ich, auch so ein bisschen die zweite Erkenntnis, die wir hatten.
Du hast, ich glaube, so eine relativ große Macht an Frontend-Developern in der gesamten Developer-Kohorte, und hast aber mit diesen immer komplexeren Editor-Interfaces auch viel mehr Arbeit, die eigentlich im Backend passieren muss, indem du die Daten dort dann aus dem Editor verarbeitest, anreicherst oder eben mit solchen Funktionalitäten wie Realtime-Collaboration, wo mehrere User zusammen den Content bearbeiten können oder eben mit AI, wo du im Editor mit AI Features den Text nochmal anreicherst.
Das sind alles Sachen, die funktionieren im Backend und im Frontend Developer.
Ist nun mal kein Backend-Developer und diese Backend-Services nehmen auch teilweise schwer komplex zu entwickeln, gerade wenn es dann ad scale geht.
Und das sind die Punkte, wo wir sagen, okay, das können wir entwickeln. Das ist ja in der Regel auch nicht die Value Proposition von deiner eigenen Software, in der dein Editor dann stattfindet.
Und tatsächlich haben uns auch häufig Anfragen erreicht, wo es dann eben hieß, das ist nicht unser Kerngeschäft, darum wollen wir uns eigentlich gar nicht kümmern.
Und da eröffnet sich dann natürlich für uns die Tür, das als Cloud-Service anzubieten.
Und plötzlich hast du ein SaaS-Produkt neben dem Open-Source-Framework.

[10:49] Ja, das ist auch der spannende Punkt. Ich glaube, auf den müssen wir nochmal ganz verstärkt eingehen.
Also, ich weiß nicht, wir haben ja alle wahrscheinlich in der Vergangenheit irgendwie mal Open-Source-Software genutzt.
Sei es ein NPM-Install, was wir haben, oder haben auch selbst vielleicht Open-Source-Software geschrieben.
Die Frage ist ja immer, was man sich so ein bisschen denkt, wenn mal so ein Projekt ein bisschen erfolgreicher wird, wie kann ich denn das jetzt auch vielleicht verwandeln in ein Business, will ich das überhaupt?
Und das habt ihr ja mit TipTap dann gemacht, also ihr habt jetzt TipTap irgendwie als Open Source Software anfänglich gehabt.
Wie seid ihr dazu gekommen, dass das jetzt überhaupt, dass ihr euch überhaupt Gedanken gemacht habt, da ein Business drumherum zu formen?

[11:35] Ja, spannende Frage tatsächlich. Ich glaube, da muss man nochmal einen Schritt zurückgehen und gucken, wo wir ursprünglich eigentlich herkommen. Denn da ist es dann entstanden am Ende auch. Wir haben ursprünglich eine Agentur gegründet. Das war in 2015. Da haben wir uns als Freelancer zusammengetan damals, meine Co-Founder und ich, und haben zu Acht eine kleine Digitalagentur ein Digitalstudio hier in Berlin gegründet und tagein, tagaus Web-Applikationen und Web-Software entwickelt für Kundinnen und Kunden. Und für uns irgendwann, lass mich nicht lügen, ich glaube, es war 2018 beschlossen, dass wir als Agentur künftig auch eigene Produkte entwickeln wollen.

[12:21] Wir waren dann so ein bisschen nach drei Jahren müde geworden von dem Agenturgeschäft, was dann für uns doch immer sehr oft nach Schema F ablief und wollten einfach eigene Produkte bauen und selber sozusagen die Seite wechseln des Spielfeldes von Agentur zu Produkt und haben dann im Endeffekt folgendes gemacht. Wir haben aus dem Umsatz der Agentur ein bisschen was raus geschnitten und damit versucht, einen Teil des Teams zu finanzieren, zu experimentieren, in welche Richtung wir da gehen können und da sind dann eben einige kleine Tools und Helferprogramme entstanden, Mac-Apps und.

[13:01] In 2020, glaube ich, war es, haben wir TipTap als Side-Project von einem der Co-Founder in die Agentur reingeholt, und haben dort dann das gesamte Framework nochmal neu entwickelt.
Das war dann TipTap 2.0.
Es gab dann einen kompletten Rewrite in TypeScript.
Wir hatten plötzlich eine vollständige Dokumentation.
Wir haben es von Vue.js entkoppelt, wie ich schon meinte. Dann ist das Framework agnostisch geworden und eben die Extension API.
Aber TipTap war auch zu dem Zeitpunkt ein Side-Project der Agentur.
Also den Umsatz haben wir über das klassische Agenturgeschäft gemacht.

[13:36] Und uns war aber klar, wir wollen diesen Weg gehen, wir wollen ein eigenes Produkt entwickeln.
Und am Ende haben wir die Zahlen schon dafür gesprochen.
Also TipTap war eben auch als Side-Project schon super populär geworden, was GitHub-Stars und Anzahl der Downloads auf NPM anging und die aktive Community.
Das Einzige, was für uns noch so ein bisschen fehlte, war dieses Puzzleteil, die macht man eigentlich aus einem Open Source Projekt jetzt Geld, weil irgendwie müssen wir es ja am Ende verdienen.
Und die bittere Erkenntnis war eben, dass GitHub-Stars deine Miete nicht bezahlen, beziehungsweise Open Source kein Business Model ist. Und wir haben dann verschiedene Dinge probiert auf dem Weg dahin.
Haben, ich glaube, in 2020 angefangen mit GitHub-Sponsoring.
Also haben rumprobiert und ausprobiert, wie man Sponsoren mit Perks im Endeffekt holen kann.
Haben dann in 2021 versucht, mit TipTap Pro Extensions das erste Mal zu monetarisieren, also eben Geld zu nehmen für Erweiterungen von TipTap, die eben vielleicht jetzt nicht ganz so sehr am Editor-Case dran sind.

[14:42] Und andere Dinge wie Screencasts aufgenommen. Wir haben dann mit Hokus Pokus verrückterweise gleich das zweite Open Source Projekt gestartet, um eben Realtime Collaboration zu ermöglichen, im Editor. Und das waren alles so Sachen, mit denen haben wir probiert, im Endeffekt so ein bisschen Geld zu verdienen neben dem Open Source Kern.
Also eigentlich, genau, es gibt diesen Open Source Kern, das ist das Wichtige. Und dann habt ihr angefangen, also erst mal das in die Agentur gezogen. Das heißt, da waren auf einmal mehrere Leute, die potenziell ein bisschen Zeit jede Woche hatten, irgendwie auch dem Open-Source-Projekt sozusagen ja Arbeit zuzubringen und zusätzlich habt ihr überlegt, was können wir denn außenrum um diesen Core machen, womit wir vielleicht Geld verdienen können. Du hast jetzt angesprochen diese Extensions, aber ihr habt auch ein neues Produkt daraus entwickelt, also Live-Editing hast du gerade genannt. Kannst du dazu noch ein bisschen was sagen?
Ja, ähm...

[15:43] Also es war dann relativ schnell klar, dass das mit Live Editing, wie du es genannt hast, also die Realtime Collaboration im Editor, dass das auf jeden Fall auch ein super spannender und eigentlich auch noch relativ unbefleckter Markt ist.
Also da gab es eben zu dem Zeitpunkt, als wir das damals entwickelt haben, noch keine richtigen kommerziellen Lösungen, beziehungsweise grundsätzlich auch noch wenig Lösungen im Open-Source-Bereich, die einfach zu benutzen waren.
Und da haben wir dann eben ein zweites Framework entwickelt Und das muss man auch fairerweise sagen.

[16:15] Nicht komplett selber von der Pika aufentwickelt, sondern auf Basis von Yjs, was eben am Ende eine Implementierung von CLI-Tees ist.
Und das verpackt und einfach anwendbar gemacht als Node.js-Backend.
Und du konntest dann eigentlich mit relativ wenigen Klicks dir eben, ja, Realtime-Collaboration in deinen Editor reinholen auf einem einfachen Level.
Und was aber immer schwierig war, war das Ganze auf einem Server zu verpacken, also zu sagen, ich lade das jetzt auf einem Server hoch und plötzlich brauchtest du eben die Server-Seite nicht, also TipTap ist die reine Frontend-Seite und da hast du deine Frontend-Developer im Endeffekt am Ende versorgt und plötzlich hattest du mit Hocus Pocus als Backend-Service die Backend-Developer-Server-Seite.
Und da wurde uns das erste Mal bewusst, das at scale zu bauen und auch so, dass es robust und skalierbar und sicher ist und die Daten nicht plötzlich verloren gehen und weltweit sozusagen Menschen kollaborativ im Editor arbeiten können.
Das ist dann, wenn du es seriös als Business betreiben willst, doch nochmal eine andere Liga, aber eben auch eine große Chance, dann den Cloud-Service anzubieten.

[17:25] War das dann auch sozusagen der Einstieg, was ihr jetzt macht mit den Backend-Services im Allgemeinen dann?
Ein Einstieg, genau. Also wir haben ja verschiedene Dinge ausprobiert. Ich glaube, was für uns oder, nein, ich spreche nur für mich.

[17:39] Wir haben ja mit dem Pro Extensions im Endeffekt sind wir erst in so eine, ich würde mal sagen, in so eine Open Core Richtung gegangen.
Das ist der Kern von TipTap, der dann halt ein sehr großer Kern war, frei verfügbar ist unter MIT Lizenz.
Und ein Teil eben die sogenannten Extensions, davon gab es einen ganz kleinen Teil, für den wollten wir halt gerne Geld haben.
Und auf der einen Seite war das eine charmante Idee und man könnte auch sagen, für beide Seiten fair, weil das waren Extensions, die haben jetzt nicht in den Kern des Editors gehört.
Aber auf der anderen Seite bin ich persönlich grundsätzlich einfach kein großer Freund vom OpenCore-Ansatz, weil du, glaube ich, strategisch doch Gefahr läufst, in so eine Richtung zu gehen, wo der OpenCore zu einem Lost Leader Produkt wird und du Gefahr läufst, in Community-Reibereien zu kommen, wenn du plötzlich immer mehr Wert aus dem OpenCore rausnimmst und ihn eigentlich hinter eine Paywall packst.
Bin ich dankbar gewesen, dass wir dann eine Möglichkeit gefunden haben, eben nicht OpenCore zu machen, sondern neben dem Open-Source-Teil eben sehr losgelöst eine SaaS-Applikation zu bauen eigentlich.

[18:51] Also und nochmal, um da drauf einzugehen, also was beim OpenCore halt passieren kann, ist, dass dann halt die Firma außenrum halt den Core verschmälert, meinst du, und da ist dann gar kein richtiger Wert mehr drin?
Also das ist eine Gefahr, das muss so nicht sein, aber es kann ja auch sein, dass die Community das vielleicht irgendwann so sieht, dass die interessanten neuen Features plötzlich nur noch hinter der Paywall hängen und du vielleicht auch das Problem hast, dass die Community selber gar nicht mehr dein Produkt pflegt.
Also was Open Source doch am Ende so spannend macht, ist eigentlich, dass Menschen zusammen Software entwickeln.
Und wenn du eben einen schlanken und ich sag mal im schlimmsten Fall unbrauchbaren OpenCore hast, dann bist du der einzige, der den entwickelt und dir fehlt eigentlich die aktive Community drumherum, die das ganze Thema ja vorantreibt.
Das wäre vielleicht für mich eine Gefahr, die ich sehen würde, wenn du halt die falschen Entscheidungen triffst, was ist jetzt Open Source und was ist Proprietär.
Also Community ist auf jeden Fall ein gutes Stichwort. Ich meine, du hast ja gesagt, ihr hattet zu dem Zeitpunkt, als ihr das auch in die Firma gezogen habt oder auch da drumherum Produkte entwickelt habt, hattet ihr ja schon einige GitHub Stars, sage ich jetzt einfach mal, wahrscheinlich auch einige Installs damit.
Trotzdem ist ja dann, nehme ich mal an, sehr schwierig, Leute noch in das Bezahlmodell oder, sagen wir mal in die Services drumherum zu bekommen oder fiel euch das einfach? Wie habt ihr das gemacht?

[20:16] Also das kommt ja natürlich darauf an, wie komplex die Probleme sind, die du mit diesen bezahlten Services löst.
Wenn du nice to have Features hast, für die du dann am Ende Geld nehmen möchtest, dann wird es wahrscheinlich deutlich schwerer werden, dafür im Monat einen Abo-Preis zu verlangen, als wenn du wirklich Schmerzen löst mit den Sachen, die du gegen Geld anbietest.
Und das ist auch ein Prozess, bei dem, würde ich sagen, sind wir heute noch weit davon entfernt, dass wir da die absolute Lösung oder den heiligen Gral gefunden haben.
Das ist im Endeffekt ein permanentes Ausbalancieren, weil du eben auch gucken musst, welche Features braucht dann am Ende auch die Community und für welche Features, hast du ja richtig gesagt, ist sie auch bereit zu bezahlen.
Ich glaube, am Ende diese Backend-Services anzubieten, das ist eben ein komplexes Problem, was wir lösen.
Und was wir eben noch beweisen müssen, ist aber, dass das eben auch in Skalierung funktioniert.

[21:17] Diese Nice-to-have-Features, wie jetzt, dass man die Realtime-Collaboration hat, ich glaub, du hast gesagt, über einen Hocus-Pocus-Server.
Und ich glaube, es gibt hier auch die AI Pro-Extension.
Selbst, wenn die jetzt Geld für euch einbringen sollten, wenn Leute sagen, okay, ich bezahle für diese Pro-Extension, die kosten aber euch ja auch wiederum Geld, da müssen ja Server laufen.
Und die, was weiß ich, 0,011 Cent pro Anfrage zu wahrscheinlich OpenAI oder Ähnlichem gehen ja dann auch auf die Rechnung.
Also kann man da überhaupt mit dem ... Oder wie seid ihr denn da als größtenteils wahrscheinlich Developer, zu diesen Wirtschaftsfragen gekommen?
Und wie habt ihr ausgerechnet, was sollte das denn pro Monat kosten, wenn jemand AI zum Beispiel nutzt, wenn ihr selbst auch die laufenden Kosten dafür habt?

[22:06] Ja, also das Gute ist, du musst deinen eigenen OpenAI-Key bei uns hinterlegen.
Das hat nämlich ganz einfache AGB- und Termthemen tatsächlich, weil OpenAI in seinen Terms relativ streng ist, was die Benutzung ihrer API angeht.
Und da wir unmöglich wissen können, in welchen Anwendungsfällen du in deinem TipTap-Editor unsere AI benutzt, können wir auch unmöglich wissen, ob du damit gegen die Terms von OpenAI verstößt.
Und weil uns das irgendwann vor so eine gewisse Komplexität gebracht hat, dass wir nicht wussten, wie wir das alles abfangen sollen, ohne dass im schlimmsten Fall unser eigener API-Zugang gesperrt wird, was dann wiederum alle User betrifft, die das benutzen, haben wir gesagt, komm, das wird so ad-scale nicht funktionieren. Wir bauen das am Ende so, dass im Endeffekt du deinen eigenen Open-AI-API-Key, was für ein Zungenbrecher, hinterlegst bei uns im Backend.
Damit bist du verantwortlich für das, was dort passiert. Und was wir dir anbieten, ist eben das Backend, was das ganze Processing übernimmt, das die Prompts schreibt, die die Extension für den Editor anbietet.

[23:12] Und dort ein Preismodell zu finden, das im Endeffekt, also das habe ich, oder das haben wir auch gelernt, Pricing ist niemals abgeschlossen.
Du bist eigentlich permanent dabei, zu rekalibrieren und herauszufinden, Welchen Schmerz löst du und was ist die Userschaft bereit für diesen Schmerz am Ende zu bezahlen, den du löst?
Wie viel wollen sie für die EBO 800 ausgeben, die du ihnen da ins Regal stellst?

[23:38] Und vielleicht auch wie groß ist der Geschwindigkeitsvorteil? Also ich glaube, was wir mit TipTap erreichen wollen, ist, dass du als Produktteam, als Software-Company oder als Development-Team am Ende deine eigene Go-to-Market-Zeit drastisch reduzierst, weil du eben im Endeffekt eine Editor-UI, wie sie Notion hat, in Wochen oder Monaten nachbauen kannst und nicht in Jahren und das Ganze eben mit einem kleinen Team statt hunderten von Developern und Designern.
Und trotzdem nochmal auf den Preis zurückzukommen, ich meine klar, das ist nie abgeschlossen, man macht viel AB-Testing wahrscheinlich, guckt, was sind die Leute bereit zu zahlen, fragt seine Kundinnen und Kunden, hättet ihr auch noch 10 Euro mehr im Monat gezahlt oder sowas, irgendwie muss man ja starten, habt ihr da am Anfang irgendwie nochmal einen groß aufgezogen, würde man wahrscheinlich eine Marktanalyse machen und mal gucken, was sind potenzielle Kunden und guckt sich mal die Community an und fragt da mal 15, 20 Leute.
Die Möglichkeiten hat man vielleicht auch nicht immer. Wie seid ihr da am Start dran gegangen?

[24:45] Ich glaube, ganz am Anfang haben wir uns gefragt, was wir selber bereit wären, für die Lösung auszugeben.
Und haben in uns reingehorcht und gesagt, wäre ich als Developer bereit, 29 Euro im Monat für Pro Extensions auszugeben?
Wäre ich als Developer bereit, 99 Dollar oder Euro im Monat auszugeben für Feature X, Y und Z?
Und das hatte den Vorteil, dass wir selber uns in die Augen schauen konnten, wenn wir die Pricing Seite betrachtet haben und gesagt haben, hey, ich wäre bereit dafür, diese Summe auszugeben, ich kann das auch gut verargumentieren anderen gegenüber, ich muss mich da nicht verbiegen.
Die schlechte Nachricht daran ist, dass wir Developer sind. Und als Developer im Herzen natürlich ganz anders auf die Sache gucken, als jetzt zum Beispiel jemand, der in einem Unternehmen die Macht über die Kreditkarte hat.
Der guckt ja aus einer ganz anderen Perspektive drauf. Der denkt vielleicht am Ende, wenn das Ding 29 Dollar kostet, kann das nicht gut sein.
Das ist so günstig, da ist irgendwo ein Haken dran.
Oder vielleicht triffst du diese Zielgruppe gar nicht erst, weil die schon nach, ich sag mal vom Pricing und von der Struktur her, seriöseren Lösungen Ausschau hält.

[26:01] Ich wollte da gerade einschreiten, weil wenn ich mir jetzt einfach mal überlege, was Büroflächen kosten, sollten Firmen noch Büros haben oder ein Mittagessen mal für die Firma spendieren.
Gerade aktuell in München wahrscheinlich heiß im Rennen sind die Wiesentische.
Aber wenn ich mal diese Preise vergleiche mit 99, klange jetzt schon besser, aber du hast gesagt, es ist am Anfang 29 Euro oder Dollar pro Monat.
Das ist wahrscheinlich, keine Ahnung, was ein Developer normalerweise sonst pro Stunde kostet für eine Firma mit Steuern.
Aber das klingt ja schon nach sehr wenigen Stunden.
Ich habe mich aber dann gerade gefragt, sobald dann die, Ich will jetzt gar nicht so die Developer sagen, sondern quasi die Firmen hinter den Developern einen bezahlten Dienst haben.
Hattet ihr das Gefühl, dann gibt es auch andere Erwartungen, was Support angeht?

[26:50] Ja, und vielleicht noch mal einen Schritt zurück, ich nenne unseren alten 29-Dollar-Plan haben wir dann irgendwann liebevoll Indie-Hacker-Pricing genannt, weil das sind ja auch genau die Leute, die du damit ansprichst, also Menschen, die im Endeffekt das auch in ihren Freizeitprojekten einsetzen und eben für 29 Euro oder Dollar sich den Zugriff erkaufen auf Pro-Extensions und mit diesen Personen bist du dann teilweise aber auch noch am Verhandeln, ob sie nicht nur 10 Dollar bezahlen könnten, weil das eben ein Freizeitprojekt ist und das aus, ich sag mal, aus dem eigenen privaten Haushaltsbudget bezahlt wird.
So, und das dann zu skalieren zu einem Unternehmen, was eben irgendwann auch ein zehn- oder zwanzigköpfiges Team bezahlen soll, wird halt schwierig.
So, und du hast vollkommen recht, wir haben dann die Preise erhöht und festgestellt, jetzt kommen tatsächlich auch mehr Unternehmen, weil du dir zwangsläufig auch Gedanken darüber machst, was sind denn die Bedürfnisse jetzt von einem Unternehmen im Pricing?
Das ist ja nicht mehr nur der Zugriff auf Features. Das sind ja auch Punkte wie Support, Garantien, SLRs, eine Uptime, vielleicht Sachen wie ein Single Sign-on, etc.

[28:00] Und diese Unternehmen, die wünschen sich dann natürlich auch den Support, den du gerade angesprochen hast, und erwarten natürlich, dass du dort zur Verfügung stehst, um Fragen zu beantworten.
Und da liegt es dann an dir als Unternehmen, wie weit du sozusagen sagen, in welcher Preiskategorie diesen Support auch leisten kannst und möchtest, weil am Ende muss.

[28:21] Ja klar sein, dass wenn in so einem kleinen Team wie wir es jetzt sind, wir sind aktuell zu zehnt, da gibt es keinen dedizierten Support Engineer. Das bedeutet, bei uns machen die Core-Maintainer noch den Support und jede Stunde, die mein Core-Maintainer nicht an meinem Open-Source-Projekt sitzt oder an der SaaS-Applikation daneben, bedeutet für mich, dass die eigentlich ziemlich gut bezahlt sein muss. Und deswegen fängst du dann plötzlich an, dir darüber Gedanken zu machen, wie viel Stunden Support du eigentlich leisten kannst und möchtest.

[28:52] Das ist ja dann auch ein Stück weit eine andere Arbeit, als wenn man sie halt nur in einem Open Source Projekt macht. Das ist wieder dieser Shift. Du hast zwar auf der einen Seite diesen Core Open Source, aber dann musst du halt auch denken, okay, wie baue ich denn eigentlich das Business drumherum auf und vor allem, wie spreche ich denn die Leute auch an, dass die zu mir kommen und überhaupt ihr Geld zu uns bringen wollen.
Wir haben eben davon gesprochen, Developer wollen vielleicht ein Hobbyprojekt damit bauen, schön und gut, sind bereit 29 Euro, vielleicht auch 100 auszugeben im Monat, wenn sie sagen, ja, das ist ja für meine Firma.
Wenn ich jetzt mal so in unser Unternehmen reindenke, da haben wir Applikationen, die halt alle auf Enterprise-Level laufen, da müssen halt Verträge erstellt werden zwischen den Companies.
Allein sowas kannst du halt nicht von 99 Euro im Monat decken, sondern da brauchst du halt irgendwie ein größeres Budget.
Was war so euer Weg? Habt ihr angefangen erst mal mit den kleineren Kunden und darüber halt so ein bisschen Traction generiert?
Und wie schafft man es dann vielleicht auch sozusagen vom Marketing her, diese Leute anzusprechen oder dann halt auch an die Firmen ranzukommen?

[30:06] Das Gute ist ja, dass du als Developer-Produkt im Endeffekt diesen, es heißt ja immer so schön, Product-Led-Growth-Ansatz hast, also das heißt, das Open-Source-Framework als solches erfährt natürlich schon eine gewisse Popularität und die Zielgruppe von diesem Open-Source-Framework sind am Ende eben Frontend-Developer und diese Frontend-Developer beschäftigen sich natürlich sehr intensiv mit dem Produkt. Und ich sage mal, andere Unternehmen, die proprietäre SaaS-Lösungen erstellen, investieren eben sehr viel Budget in Marketing. Und als Open-Source-Produkt ist dein Marketing oder dein Vertriebskanal eigentlich die Dokumentation und die Qualität im Endeffekt der Developer Experience, wie gut die ist. Und diese Developer tragen das ja im besten Fall dann in dein Unternehmen rein.
Der Frontend-Developer ist vielleicht in einer Explorationsphase für ein neues Projekt oder Produkt, findet dann eben bei seiner Recherche TipTap, setzt TipTap ein, stellt fest, wie schnell und einfach das funktioniert und wird in der Dokumentation auch irgendwo lesen, dass wir eben Cloud-Services anbieten für AI oder für Realtime-Collaboration.

[31:17] Und kann das dann im Endeffekt erstmal in einem kostenlosen Plan, den wir zur Verfügung stellen, testen Und wird dann aber zwangsläufig, wenn er das in einem Business-Kontext einsetzen will, eben zu der Person gehen, in einem Unternehmen, die die Macht über die Kreditkarte besitzt.
Und diese Person kommt dann im Endeffekt, also kommt auf die Größe des Unternehmens auch an natürlich, aber in der Regel hast du dann natürlich irgendwann mit den Personen im Unternehmen zu tun, die sich dann darum kümmern, mit dir die Verträge abzuschließen.
Wenn es dann sozusagen aus diesem gesamten Self-Service-Bereich nämlich immer rausgeht.
Ja, also, wo du dann nicht mehr auf den Standard-Terms arbeitest, die du eben auf der Webseite anbietest, sondern wo es dann schon darum geht, dass die nochmal eigene Terms haben wollen, eigene Garantien und so weiter und so fort.

[32:03] Der altbekannte Enterprise-Plan, der dann auch da Contact Us sagt im CTA.
Genau, den haben wir auch.
Ja, das habe ich mir gedacht, aber nochmal kurz, also das heißt, der Hauptweg für euch ist immer über die Developer gewesen bisher, die halt sozusagen vom Produkt ausgehend gesagt haben, oh cool, dieses Produkt möchte ich verwenden und dann halt die Services drumherum, die eventuell ja dann das weitere Interesse geweckt haben.
Genau. Ich glaube, der Online-Marketing-Spezialist oder die Online-Marketing-Spezialistin nennt es Bottom-Up-Motion, dass wir eben von unten sozusagen von den Personen, die selber entwickeln und das Handwerk ausüben im Endeffekt dann unsere sogenannten Fans haben, die das nach oben tragen.

[32:57] Und sicherlich wird man auch gucken müssen, dass man von der anderen Seite heran aber auch Lösungen anbietet, dann auf der Webseite und sagt, zum Beispiel ein Engineering Manager, also jemand, der dann wirklich weiter oben ist in der Team-Hierarchie, der sucht dann vielleicht nochmal nach anderen Lösungen, dass man für diese Personen dann wahrscheinlich in Zukunft auch Use-Case-Seiten oder Category-Seiten anbietet und dann im Endeffekt von beiden Seiten die Bedürfnisse geweckt oder befriedigt hat.
Also Zielgruppen.

[33:29] Jetzt hast du recht. Also Zielgruppen gerechte Ansprache einfach so, je nachdem, also welche Entscheider, wo, auf welchem Level bewegt man sich und diese Informationen halt entsprechend aufbereite.
Ich glaube, ich habe es bei manchen Produkten schon mal gesehen, für Engineering Manager, für Developer, für die Business Leute oder sowas in der Richtung.
Ich weiß nicht, ob es gut funktioniert, zumindest wenn man sich den Börsenkurs anschaut, kann es so schlimm nicht sein, aber MongoDB macht das zum Beispiel ganz gut, finde ich, ist am Ende auch ein Open-Source-Produkt und hat aber auf ihrer Webseite zum Beispiel auch Kategorien, wo sie sagen, MongoDB für Banken, für Versicherungen etc., und offensichtlich ist das jetzt kein Menüpunkt, der einen Developer interessiert, der springt halt gleich in die Dokumentation.
So, aber du hast trotzdem auch die andere Seite sozusagen im Unternehmen abgeholt, das ist schon richtig.
Ja stimmt, MongoDB ist eigentlich auch ein ziemlich erfolgreiches Produkt, was ja aus dem Open-Source-Bereich kommt und drumherum aber mittlerweile auch echt große Firma ja hat, also ich meine, Ich weiß jetzt nicht, wie es euch geht, aber ich werde des Öfteren mal von deren Salesleuten auch kontaktiert.

[34:44] Um einmal darüber zu sprechen, was wir denn da noch für Einsatzchancen bei uns sehen.
Ich glaube MongoDB und GitLab sind zwei relativ gute Beispiele dafür, wie du aus einer Open-Source-Kompanie ein extrem erfolgreiches Unternehmen bauen kannst oder aus einem Open-Source-Produkt.

[35:00] Ja, du hast es bei uns auch noch aufgeschrieben, ihr habt da auch über Hacker News dann das Produkt gelauncht. Kannst du dazu noch ein bisschen was erzählen?

[35:11] Mehrfach tatsächlich, genau. Wir haben jetzt, ich glaube, vor zwei Monaten haben wir den Hacker-News-Launch vollzogen und ich glaube, was die Urban Legend ist, ist, dass auf Hacker-News zu launchen am Ende so ein bisschen durchs Feuer gehen werden kann, weil die Community dort doch auch sehr kritisch ist und ja, ein guter Litmus-Test eigentlich für dich am Ende da ist.
Darstellt. Und wir haben da tatsächlich viele Tipps und Ratschläge am Ende befolgt, wie man launcht, ohne den Launch jetzt zu versemmeln oder sich dort sozusagen im schlechten Licht darzustellen.

[35:57] Was heißt ein Launch da ganz konkret? Sorry, wenn ich mal reinkretsche.
Hackernews-Lunch, dein Produkt dort bewerben. Wir hatten die Möglichkeit, über unseren Investor direkt auf die Startseite von Hackernews zu kommen. Und das Angebot haben wir genutzt.
Und dann landest du eben auf der Startseite, hast riesig viel Traffic, sowohl auf dem Artikel, aber auch auf deiner eigenen Webseite. Da geht es dann schon auch darum, sicherzustellen, dass deine eigene Infrastruktur das aushält und nicht direkt mit dem Hackernews-Artikel auf der Frontpage deiner eigenen Webseite zusammenkracht, also da gab es dann tatsächlich auch ein paar Formeln und Größenordnungen, bei denen wir sicherstellen sollten, dass das alles noch funktioniert mit Workload und Traffic etc.

[36:41] Und ich glaube, was man grundsätzlich nicht tun sollte, ist, wenn man sein Produkt dort bewirbt, im Marketing- oder Sales- oder PR-Stil zu schreiben oder zu versuchen, das eigene Produkt zu verkaufen.
Das mögen wir, glaube ich, selber auch nicht, wenn wir auf Hacker-News unterwegs sind, wenn wir das Gefühl haben, das wird jetzt hier eine Verkaufsveranstaltung.
Dementsprechend war im Endeffekt unser erstes Ziel, den Text nicht wie so ein Pitch oder eine Eigenwerbung aussehen zu lassen.
Und mit den Usern selber im Endeffekt auch nicht wie mit Kunden zu sprechen, sondern mehr wie mit Gleichgesinnten, also in den Kommentaren.
Und zumindest bei uns, was eben sehr speziell ist, und vielleicht habt ihr das auch schon mitgekriegt, wenn du als Open Source Projekt auf auf Hacker News launcht oder dort Artikel verfasst, dann solltest du schon dir bewusst sein, dass wenn deine Open Source Lizenz nicht von der OSI akzeptiert ist, du auf jeden Fall Rückfragen kriegen wirst.
Warum würde ich Open-Source-Projekt nennen, wenn es doch keine von der OSI akzeptierte Lizenz ist oder geprüfte Open-Source-Lizenz ist?
Also da kann man sich schon ein bisschen darauf vorbereiten, dass dann da Rückfragen kommen werden.
Und ich glaube, was man tun sollte, und das haben wir dann auch strikt beachtet, ist eben möglichst sachlich, aber persönlich zu schreiben und vielleicht auch bescheiden.
Also du versuchst eben keine Buzzword zu verwenden.

[38:05] Und eigentlich sehr schnell auf den Punkt zu kommen, welches Problem dein Produkt löst, warum es wichtig ist und wie du es eben erreicht hast.
Und dann eben auch der Hacker-News-Community die Möglichkeit zu geben, das Produkt auszuprobieren und es sich anzuschauen, weil du so am Ende auch besseres Feedback erhältst zu deinem Produkt.
Und falls das jetzt zum Beispiel nicht geht, weil es hinter einer Paywall ist oder weil du dich registrieren musst dafür, dann zumindest eine Demo oder ein Video vom Produkt zur Verfügung zu stellen.
Und falls du Pricing hast, hilft dir auf jeden Fall ein transparentes Pricing zu haben, weil auch dafür, und finde ich auch zu Recht, kann man schnell gerüffelt werden, wenn das Pricing super intransparent und unverständlich ist.

[38:47] Und ansonsten haben wir, glaube ich, an dem Tag, wo wir gelauncht haben, versucht super engagiert auf Kommentare zu antworten, die dann auch eine richtige Diskussion ermöglichen.
Und, ähm, ja, ich glaub, womit man leben muss, ist, dass es immer ein paar Menschen gibt auf Hacker-News, die im Endeffekt, ja, der Kritik wegen einfach nur schreiben wollen.
Und diese Personen, glaub ich, die Kritik nimmst du dankend an und kommentierst sie freundlich.
Aber ich glaub, ein Fehler wäre, sich dann gezwungen zu fühlen, diese kritisierende Person überzeugen zu müssen.
Weil das Spiel gewinnst du halt im Zweifelsfall nicht. Und da dann doch wie in jedem Forum oder wie in jedem Netzwerk, die die Mehrheit der Hacker-News-User eben still ist und mitliest.
Ich glaube, es geht auch darum, denen zu zeigen, was sie sich für ein Bild von dir machen, wie du auf Kritik reagierst und da nicht so einen Kommentarsturm loszutreten.

[39:40] Du hast ja am Anfang gemeint, ihr habt eine MIT-Lizenz, wenn ich mich richtig erinnere. Wie seid ihr denn dann genau auf die Lizenz gekommen?
Ja, verrückterweise. Mal gucken, wie oft uns das noch auf die Füße fällt, die loseste aller Lizenzen zu wählen.
Um ehrlich zu sein, ich glaube, ohne viel Gedanken. Also da wir ganz oder ja, da ganz, ganz ursprünglich gar nicht klar war, dass wir das Produkt kommerzialisieren wollen oder daraus ein Unternehmen bauen, ist dann irgendwie, ja, wie soll ich sagen, es ist obvious, dass du die MIT-Lizenz als Developer nimmst.
Die ist ja schon fast voreingestellt, also im übertragenen Sinne, aber du kennst sie halt selber, du hast schon mal gehört, dass das die loseste Lizenz aller Lizenzen ist, mit der du auch selber am wenigsten Arbeit hast.
Und dann wurde es MIT und jetzt sind wir an so einem Punkt, ich glaube, wir haben in den letzten zwei Jahren oft genug darüber nachgedacht, ob das der richtige Weg war oder wo uns das noch auf die Füße fallen kann, aber du hörst auf der anderen Seite auch von so vielen gestandenen Unternehmen, die sich dann im Endeffekt komplett ins Abseits schießen mit dem Lizenzwechsel, dass, glaube ich, der Respekt, die Lizenz zu ändern, groß genug ist, um das Thema jetzt nicht anzugehen.
Deswegen super spannend. Ich glaube, du musst da tiefer drauf eingehen.
Hans, du wolltest auch noch gerade was sagen? Ja, genau. Ich wollte das ähnlich wie du jetzt nochmal nachfragen.
Was ist denn eventuell für ein Unternehmen problematisch an der MIT und wo will man denn wechseln und warum?

[41:03] Ja, also grundsätzlich vielleicht gar nicht an der MIT, aber an freizügigen Lizenzen.
Die MIT ist sicherlich die bekannteste, aber dann hast du ja auch noch sowas wie die, Apache 2.0 Lizenz, die ist ja auch noch eine sehr permissive.
Und ich glaube, die Vorteile, die liegen ja auf der Hand. Die Lizenzen sind einfach zu verstehen und zu implementieren.
Du hast als Anwenderin oder Anwender eine super große Flexibilität in der Lizenz.
Einschließlich der kommerziellen Nutzung. Du musst dir also keine Gedanken machen, wenn du Open Source Software unter MIT Lizenz nutzt, ob das jetzt erlaubt ist oder nicht.
Und mit der fehlenden Copy Left Anforderungen, die es sonst bei Copy Left Lizenzen gibt, hast du aber im Endeffekt auch keine Verpflichtung, dein abgeleitetes Produkt oder Werk eben unter derselben Lizenz zu veröffentlichen.
Und daraus ergeben sich dann eigentlich auch schon die größten Nachteile.
Du hast...

[41:56] Kein Code-Zurückfluss, also Entwicklerinnen und Entwickler können ihre Änderungen, die sie an deinem Produkt gemacht haben, privat halten, weil die Lizenz verbietet das ja nicht.
Du kannst dir morgen Tipp-Tap forken und im Endeffekt damit tun und lassen, privat, was du möchtest.
Du hast dann dadurch eben dieses Risiko der Aneignung, also das heißt, größere Unternehmen könnten zum Beispiel dein Code nehmen und in Property ihre Produkte einbauen, und damit Geld verdienen, ohne der Community was zurückzugeben.
Und das ist ja zum Beispiel in der Vergangenheit auch schon passiert, mit großen Open-Source-Projekten, wo dann plötzlich ein großer Cloud-Anbieter kam und auf dem Open-Source-Produkt eben eine SaaS-Lösung angeboten hat.

[42:34] Du hast eben fehlende Garantien, das wäre wieder ein Nachteil auf der User-Seite, dass du eben keine Gewährleistung oder Haftungseiten des Uebers hast.
Und du hast teilweise, wenn es jetzt nicht die Apache-License ist, zum Beispiel auch ungeklärte Patentfragen.
Das sind so, glaube ich, grob, wenn ich es richtig zusammengefasst habe, die Vor- und Nachteile von offenen oder freien Lizenzen. Disclaimer, ich bin kein Patentrechts- oder Lizenzrechtsanwalt, aber es ist auf jeden Fall ein super komplexes Feld. Und auf der anderen Seite hast du dann eben die Copyleft-Lizenzen. Das sind eben die, die zum Beispiel diesen Code-Zurückfluss erzwingen können. Also du hast dann sowas wie die GPL-License oder die AGPL-License oder die Mozilla Public License, die eben dich dazu zwingen können, Änderungen, die du an der Software selber vornimmst, wieder zurückfließen zu lassen ins Originalprodukt. Oder die dich dazu zwingen können, dass wenn du Code oder Software entwickelst auf dem Open Source-Produkt oder mit dem Open Source-Produkt, dass es dieselbe Lizenz haben muss. Also dein Werk kann dann nicht mehr proprietär werden und so weiter und so fort. Also das sind so die Vor- und Nachteile. Beziehungsweise Nachteil wäre bei den Copyleft-Lizenzen noch, dass sie eben teilweise schwer zu verstehen und zu implementieren sind, weil du dir als Developer Gedanken darüber machen musst, ob du gerade gegen die Lizenz verstößt, wenn du das zum Beispiel in deine Proprietärer-Software einbaust.

[43:59] Das wäre auch genau so der erste Gedanke, den ich jetzt hätte, wenn da halt so eine nicht so bekannte Lizenz dabei steht und ich nicht genau weiß, was ich da tun muss. Also sofern ich mich dafür interessiere und ich sag mal, die meisten, gerade Unternehmen interessieren sich ja schon dafür, wie sie die Software einsetzen und welche Lizenzen die Software haben, die sie nutzen, auch Open Source, dann ist es ja.

[44:25] Eher hinderlich für das Produkt auch, dass es eingesetzt wird, weil man dann vielleicht lieber sagt, lass ich lieber mal die Finger von, nehme ich diese andere Alternative, das da verstehe ich MIT oder Apache oder GPL V2 oder what do I know.
Ja, ist vollkommen richtig. Also natürlich, je leichter die Lizenz ist, desto größer ist die Wahrscheinlichkeit, dass dein Produkt populärer wird, weil sich einfach niemand Gedanken darum machen muss, ob er da gerade gegen die Lizenz verstößt oder was er tun und lassen darf.
Aber auf der anderen Seite eben die Gefahr, dass auch andere Unternehmen oder Developer plötzlich darum was bauen, womit sie Geld verdienen.
Und die Frage musst du dir im Endeffekt... Oh, es gibt so viele Fragen, die du dir stellen kannst.
Du kannst dir zum Beispiel die Frage stellen, was möchtest du mit deinem Produkt eigentlich erreichen, oder mit deinem Projekt, mit deinem Open-Source-Projekt?
Also soll es ein Hobbyprojekt sein, oder möchtest du es als Side-Project betreiben?
Möchtest du es irgendwann hauptberuflich machen? Wie wirst du damit Geld verdienen, wenn du es hauptberuflich machst?
Ist das GitHub-Sponsoring? Sind das Spenden über Open Collective?
Möchtest du Consulting anbieten, oder möchtest du ein Unternehmen aufbauen um das Produkt herum?
Ist es okay, wenn andere Personen mit diesem Produkt Geld verdienen oder mit dem Projekt Geld verdienen oder vielleicht sogar forken und in Konkurrenz zu dir treten?
Und das sind alles so Fragen, die können am Ende schon auch dich zu der richtigen Lizenzfrage leiten.

[45:51] Kann aber auch sein, dass du es vielleicht im Laufe deines Projekts noch mal änderst, weil sich vielleicht auch deine Anforderungen an deine eigenen Ideen noch mal anpassen.
Und ich glaube, der einzige wichtige Punkt ist, dass du die Community dann eben in dieser Entscheidung, wenn du jetzt für dich sagst, okay, da kommt jetzt zum Beispiel jemand, der forgt dein Produkt und baut da plötzlich eine SaaS-Lösung mit, was du eigentlich auch machen wolltest, oder aus anderen Gründen entscheidest du dich jetzt, dass eine andere Lizenz besser passt zu dem, was du vorhast, Das ist, glaube ich, der einzige Punkt, den du nicht verkacken solltest, dass du die Community rechtzeitig mit reinnimmst in diese Diskussion und offen und transparent deine Gedanken dazu mit genügend Vorlauf äußerst, warum du glaubst, dass ein Lizenzwechsel jetzt angebracht ist.
Weil wenn du das nicht tust, dann, ja, dann stößt du im Endeffekt ziemlich vielen Leuten, die vorher darauf vertraut haben, vor den Kopf.
Und dann ist Vertrauen futsch.

[46:46] Ja, klar. Also ich meine gerade, wenn man aus dem Open-Source-Bereich kommt und eigentlich daran wächst und dann halt irgendwie die Community bei so was Wichtigem, außenvoll ist. Also eigentlich für alle wichtigen Fragen, ne, muss man wahrscheinlich gucken, wie bindet man die Community gut ein.
Immer. Du hast eben gesagt so, je nachdem, was man vorhat mit seinem Projekt, kommt's halt dann drauf an, was du auch für eine Lizenz verwendest. Also möchtest du eine Firma haben, die vielleicht irgendwann mal sich selbst finanziert.
Jetzt hatst du vorhin aber auch gesagt, einer eurer Investoren hat euch da die Möglichkeit gebracht, auf Hacker News zu sein. Das heißt, ihr habt euch ja dann auch entschieden, Venture Capital anzunehmen, bzw. ihr habt euch damit auseinandergesetzt.
Kannst du dazu ein bisschen was erzählen? Wie kam es dazu, als ehemaliges Open Source allein, oder also einzelnes Open Source Projekt, jetzt natürlich als größere Firma.

[47:45] Ja, TippTap ist ja als Zeitprojekt gestartet von der Agentur und irgendwann haben wir die Entscheidung getroffen im Laufe der letzten Jahre, wir wollen eben ein Produkt und dann fiel eben später die Entscheidung, es soll TippTap werden, weil wir da das größte Potenzial gesehen haben und im Endeffekt haben wir uns im letzten Jahr dafür entschieden, dass wir jetzt wirklich diesen Shift hinkriegen wollen, also stärker von der Agentur zum Produkt hin und das war Bootstrapped einfach ein superschwerer Weg, weil wir im Endeffekt, in der Theorie uns einen Finanzplan aufgestellt hatten, wie wir diesen Shifting kriegen von der Agentur zum Produkt.
Und das las sich in den Excel-Tabellen so sehr smooth, wie so dieser Übergang stattfindet.
Und in der Praxis haben wir einfach festgestellt, dass es drei Jahre an allen Ecken und Enden geknallt hat, weil du eigentlich zwei Unternehmen parallel versucht hast zu führen.
Das eine war die Agentur und das andere war eben das Open Source-Produkt.
Und das Open Source-Produkt eben noch mit der Herausforderung, dass es zwar schon super viel Zeit in Anspruch genommen hat für Community Support, für Entwicklung, aber eben nicht genug Geld.

[48:48] Und ja, mit dieser Situation standen wir dann im Endeffekt irgendwann vor der Entscheidung, was machen wir jetzt?
Versuchen wir es weiter oder gehen wir all in und setzen alles auf eine Karte?
Und das haben wir dann dieses Jahr gemacht und gesagt, mit Venture Capital, mit jemandem, der uns finanziell unterstützt, haben wir die Möglichkeit, eben das Momentum, was wir im Team haben und die Motivation, nochmal auf ein ganz anderes Level zu heben und eben unseren Traum aus TipTap Unternehmen zu bauen, viel, viel schneller zu verwirklichen.

[49:23] Kannst du da auch sagen, wie seid ihr da dran gekommen? Also ich sag mal, man kriegt ja immer wieder mit, es ist gar nicht so einfach im Moment und die letzten Jahre und Krise hier, Krise da.
Trotzdem gibt's immer wieder Unternehmen, die auch größere Investments bekommen.
Kannst du irgendwas zu eurer Größe sagen und wie ihr da drangekommen seid?
Also wir sind bei Y Combinator. Vielleicht sagt euch das auch was.
Das ist somit der populärste Startup Accelerator aus dem Silicon Valley.
Hacker News Betreiber. Genau, die Hacker News Betreiber, richtig.
Und was wir gemacht haben und das war eigentlich, ich würde jetzt gerne sagen, das hat alles einen Plan gefolgt, aber das Gegenteil war der Fall. Wir haben uns dort eben auf den Batch beworben, online. Das macht es vielleicht ganz charmant. Du bewirbst dich dort eben auf das Programm online und wirst eben geführt und ich habe das Gefühl gehabt, für uns passt das besser, weil wir uns schon noch mit der Frage auseinandergesetzt haben, wollen wir jetzt sofort diesen Venture-Capital-Weg gehen und uns eben ins Fundraising begeben und bei verschiedenen Investoren pitchen oder gehen wir eben diesen Weg des Startup-Accelerator, der eigentlich auch sehr vereinfacht ausgedrückt wie eine Art Bootcamp ist, der dich so ein bisschen schult und drillt.

[50:44] Und wir haben uns eben für den zweiten Weg entschieden. Und ich glaube, gute Ideen werden auch in schwierigen Phasen gefandet.
Aber es ist halt deutlich anspruchsvoller, jetzt im Endeffekt, Investorinnen und Investoren zu erklären, wo bei dir sozusagen ja, wo du die große Chance siehst im Unternehmen und wie du vorhast, profitabel zu werden und wie du vorhast, wirklich auch, zu wachsen und zu skalieren, sowohl das Produkt als dann natürlich am Ende auch den Umsatz, weil darum, Darum dreht sich dieses Spiel nun mal.
Und wir haben uns online beworben.
Das, glaub ich, war für uns ein guter Weg, weil wir eben vom Fundraising gar keine Ahnung hatten und nicht wussten, wie das funktioniert.
Und diese Anmeldemaske im Endeffekt dich guidet so ein bisschen und der Prozess dann auch super schlank ist.
Du wirst zum Interview eingeladen oder eben auch nicht.
Nach dem Interview kriegst du sofort Bescheid, ob sie dich nehmen oder nicht.
Also, das ist eigentlich super lean.
Wenn du dann liest, dass sich dort eben auch 20.000 bis 24.000 Startups pro Batch bewerben, dann verstehst du auch, warum sie das so schlank und schnell halten und da jetzt keinen großen Prozess draus machen.

[51:51] Ja. Das klingt ja aber schon so ein bisschen wie so ein kleiner Traum, so Silicon Valley und Investments und ich sehe dich jetzt auch schon gerade grinsen.
Hast du dir das jemals auch so vorgestellt? War das dein Plan, mal sowas zu machen oder ist das wirklich eher so aus Versehen passiert?
Ihr hattet halt die Idee zu TippTap und dann muss man halt überlegen, was macht man jetzt eigentlich damit und hat sich da jetzt für dich persönlich was auch geändert?

[52:19] Also den, also den Wunsch aus TipTap oder mit dem Team zusammen und TipTap ein Unternehmen zu bauen, den hatte ich schon sehr lange und Venture Capital am Ende zu begreifen als, ja als Energiequelle, mit der du im Endeffekt dein Unternehmen schneller bewegen kannst, der war mir auch sehr bewusst.
Es gab natürlich schon, wir mussten das erst mal für uns im Team auch evaluieren, wollen wir das?
Weil im Endeffekt, es gibt ja immer, und ich glaube da gibt es zuhauf auch Artikel online, Bootstrapped versus Venture Capital.
Am Ende, jetzt wo ich beide Seiten kenne, drei, vier Jahre Bootstrapped und nun jetzt seit kurzem Venture Backed, würde ich sagen, hat beides seine Vor- und Nachteile. Ich sehe es aber nicht mehr so schwarz und weiß, wie es vielleicht vorher tat.
Die Entscheidung, sich dort zu bewerben, die war natürlich sehr bewusst gewählt, aber damit gerechnet, dass wir da angenommen haben, haben wir halt im Leben nicht.
Also die Chance, bei Y Combinator angenommen zu werden, liegt bei unter einem Prozent.
Und ich glaube, mit dem Mindset haben wir uns am Ende auch beworben.
Also wirklich so, okay, pass auf, die werden uns dann absagen und zumindest wussten wir, so wie du es halt online häufig gelesen hast, dass sie dir wirklich auch fair absagen und auch warum.

[53:34] Ja, und für uns war dann klar, dann lernen wir wenigstens daraus, was wir nächstes Mal besser machen müssen oder was vielleicht an unserem Modell oder an dem, wie wir es aufbauen wollen, das Unternehmen nicht passt. Und plötzlich kam halt die Einladung zum Interview und das Erste, was wir dachten, ist so, okay, fuck, damit haben wir jetzt irgendwie nicht gerechnet.
Und ja, der Rest ging dann eigentlich superschnell. Also, das hat sich für mich persönlich geändert. Wir waren jetzt gerade für drei Monate im Silicon Valley. Wir haben Wir haben dort das gesamte Mindset, die gesamte Stimmung, Atmosphäre, im Endeffekt per Druckbetankung reinbekommen.
Einmal komplett die andere Seite des Spielfelds gesehen.
Sehr viele interessante Persönlichkeiten kennengelernt, mit den erfolgreichsten Gründerinnen und Gründern der gesamten Tech-Szene sprechen dürfen.
Und ... Da gehen da jetzt eigentlich mit so vielen Erfahrungen und neuen Erkenntnissen raus.
Das fühlt sich ein bisschen so an wie ...
Wie wenn du früher das Cheatheft von einem Computerspiel in der Hand gehalten hattest und jetzt irgendwie das Gefühl hast, jetzt weißt du, wie du schneller zum Ende kommst.
So ist es dann am Ende natürlich nicht.
Aber er hat doch super viele Erfahrungen gesammelt, so viele nette, liebe, engagierte Menschen kennengelernt.

[54:45] Und schon auch verstanden, wie da drüben am Ende das gesamte Ökosystem funktioniert und was du vielleicht auch für dich mitnehmen kannst, dann als Open-Source-Projekt.
Und dieser Batch hatte tatsächlich auch sehr viele Open-Source-Developer-Tools und AI-Companies.
Und dann mit diesen Leuten sich zu unterhalten, dass sie im Endeffekt gleichgesinnt sind, und auch mit den gemeinsamen und den Group-Partnern zu evaluieren, wie du eben Open-Source- und Dev-Tools vorantreiben kannst, ist schon super spannend.

[55:15] Ja, gerade auch die ganzen Infos da abzugreifen, denke ich mir. Also ich habe vor, keine Ahnung, zehn Jahren oder so auch mal mit, was ist noch länger her, mit Freunden irgendwie, das war so ein kleines Accelerator-Programm.
Es war irgendwie zwei Monate waren die Freunde da in Indien und ich war da auch mal zu Besuch und das ist halt so nice, einfach was man einfach für Infos da reinbekommt und so Dinge, über die man sich halt vielleicht, obwohl man sich viele Gedanken gemacht hat, nicht so Gedanken gemacht hat, also die man vorher nicht auf dem Schirm hatte und grad, glaube ich, Y-Combinator, da sind ja schon die krassesten Startups auch in der Vergangenheit mit am Start gewesen.
Von daher stelle ich mir das auch sehr, sehr interessant vor und cool, dass ihr das so als Sprungbrett dann jetzt auch habt, um da noch ein bisschen höher zu springen.
GitLab ist zum Beispiel eine Y-Kombinator-Kompanie. Ah, ist auch.
Ja, genau. Muss man sich mal auf die Alumni-Liste, muss man sich mal anschauen, was da für Companies rausgefallen sind, so.
Ja, eigentlich alle großen, die du so kennst. GitLab, Stripe, Airbnb. Und das sind dann tatsächlich auch teilweise die Gründerinnen und Gründer, mit denen du dort sozusagen, denen du zuhören darfst, eine Stunde, zwei Stunden und die dir eben all die guten und schlechten Erfahrungen und Erlebnisse, die du so als Gründerin oder Gründer haben kannst, auch ziemlich offen und eindrücklich mitgeben.

[56:41] Also ich freu mich auf jeden Fall dann auch schon in ein paar Jahren auf den Netflix-Film.
Und das soll auf keinen Fall so ausgehen wie bei Tetris oder sowas, wie das die Gründer da, naja, was auch immer da bei Beispielspielern passiert ist.
Ich lass mich überraschen. Auf jeden Fall ist es eine wilde und verrückte Reise, ja.

[56:59] Hattet ihr eigentlich dann auch mal tatsächlich Kontakt zu Notion selber oder haben die sich auch mal bei euch gemeldet?
Weil ich überleg gerade, ob da nicht auch Notion mal sagen könnte, ach, wieso entwickeln wir das eigentlich alles noch selber, könnten ja auch selber TipTap nehmen.
Also ich glaube, das wäre natürlich der Ritterschlag, wenn Notion sich jetzt dafür entscheiden würde, auf TipTap zu setzen.
Aber nein, also haben sie nicht.
Und das wäre auch wild, weil bei denen ist das ja tatsächlich die Core-Value-Proposition von dem gesamten Produkt, ist ja der Editor.
Und die haben ja auch viel früher als wir schon angefangen. Die gibt es ja auch schon ein bisschen länger.
Ich wüsste auch gar nicht, wie das noch funktionieren sollte jetzt in dem Stadium, wo sie sind, all das, was sie haben, auszubauen und einzubauen.
Das ist ja so ein bisschen Vor- und Nachteil zugleich von Open-Source-Software.
Du hast sie halt relativ schnell eingebaut. Oder, ja ...
Die Einstiegshürde ist gering, aber es dann wieder auszubauen, dauert eben superlange.
Ja, das ist natürlich nicht zu unterschätzen.
Heißt aber auch, da kam jetzt auch nichts Negatives im Sinne davon, dass sie doch mal anklopfen und sagen, nicht, dass da jetzt was kopiert wird oder Ähnliches?
Ähm, also da wir ja kein Notion-Wettbewerber sind eigentlich, Wir bieten ja die drunterliegende Technologie an, damit andere Unternehmen eben Applikationen wie Notion bauen.
Aber wir selber haben ja gar nicht die Ambition, einen Notion-Konkurrenten hinzustellen.
Aber alle anderen dürfen es gerne machen.

[58:23] Mit TipTap und den Cloud-Services. Dann können sich ja die anderen drum streiten.
Ich wechsle noch mal ganz kurz das Thema auf die Lizenzen.
Ihr habt jetzt die MIT-Lizenz, und wir haben schon gehört, es gibt noch ganz viele andere.
Gibt es jetzt für eure Endnutzer, also quasi im Endeffekt die Developer, irgendwas zu beachten, wenn's Open Source-Dinge gibt mit Lizenzen und muss ich bei meinem NPM-Install da irgendwie auf etwas drauf achten?
Theoretisch ja. Ja, also ich kenne niemanden, der das macht in meinem nahen Umfeld, aber eigentlich musst du sicherstellen, wenn du mit Open Source Software arbeitest oder grundsätzlich mit Software, ob du gegen die Lizenz verstößt.
Aber jetzt sind wir ja Developer und keine Lizenzrechtsanwälte.
Du hast aber zum Beispiel bei MPM wiederum Packages, die dir eine Liste aller Lizenzen ausspucken aus dem Node-Modules-Ordner.
Und was du zumindest machen kannst, ist einmal dort rüberhuschen und gucken, ist dort zum Beispiel eine Copy Left Lizenz drin.
Und Copy Left Lizenzen, die Liste kriegst du eigentlich sehr schnell von Chat.GPT oder auf Wikipedia.
Und wenn du feststellst, und das ist super selten, aber wenn du jetzt feststellst, dass da zum Beispiel Lizenz drin ist, die nicht Apache oder MIT oder ähnlich frei ist, dann musst du schon einmal kurz gucken, ob du dagegen verstößt oder nicht.

[59:44] Ich sag mal, natürlich sehr unwahrscheinlich, dass das am Ende, Wenn du jetzt selber damit proprietäre Software entwickelst, irgendwie leicht nachvollziehbar ist, aber wenn du dich an die Lizenzen halten möchtest, musst du das machen.

[59:57] Gegen was könnte man da denn verstoßen? Also wenn du zum Beispiel die BSD-Lizenz nutzt, dann bist du dazu verpflichtet, diese Person als Urheberin oder Urheber zum Beispiel zu nennen und die Lizenz auch drin zu zu lassen.

[1:00:16] Genau. Beziehungsweise nein, die bist du nicht verpflichtet. Das war falsch.
Aber, ähm, doch, du musst den Urhebervermerk, genau, du musst den Urhebervermerk in deiner eigenen Software weiter beibehalten.
Ich bin mir relativ sicher, dass das viele noch nie geguckt haben, ob sie ein Package mit einer BSD-Lizenz benutzen.
Deswegen ist es ja so schön, die MIT-Lizenz zu nehmen.
Dann weißt du einfach, da ist alles erlaubt und mach, was immer du willst mit meiner Software, ich hafte für nichts.
Dass man Sachen aus Versehen unschuldig falsch macht.
Weil ich denke jetzt, dass niemand ein großartiges ...
Ich hoffe jetzt mal, dass niemand ein großartiges Problem hat, irgendwo Lizenzen und Urheber und Urheberinnen zu vermerken.
Das sind nur eher so Hups, ich hab da nie dran gedacht. Ich glaub, das ist auch immer so eine deutsche Angst für unsere Steuererklärung, dass wir aus Versehen irgendwie Steuern hinterziehen.
Ja, auf der anderen Seite könnte man sich natürlich auch fragen, Es ist eine schlaue Idee, wenn du, also, weiß ich nicht, ich hab dazu keine Meinung, aber wenn du jetzt dein Node-Package unter einer starken Copy-Left-Lizenz wie RGPL zur Verfügung stellst, musst du dich natürlich auch fragen, wie viel Nutzen hat das dann für die Mehrheit der Developer, die sich mit dem Lizenzthema nicht auskennt und beschäftigt.

[1:01:31] Das könnte wahrscheinlich schon fast ins Philosophische abdriften, die Frage.
Deswegen versuch ich jetzt aufzuhören, bevor ich mich hier aufs lizenztechnische Glatteis bewege.
Ich habe da tatsächlich keine Meinung zu, was besser oder schlechter ist.
Aber vielleicht haben das ja die Hörerinnen und Hörer und die können wir hier mal mit einbinden, die können uns mal ein bisschen erzählen über Lizenzen oder vielleicht sagt ihr ja auch, ihr wollt mal eine gesonderte Sendung zu Lizenzen haben im Open Source Bereich, dann sagt uns mal Bescheid, vielleicht können wir da mal was arrangieren.
Ich glaube, sowas hatten wir noch gar nicht in der vergangenen, in den vergangenen 13 Jahren.
Klingt super spannend. Also, falls sich da irgendjemand auskennt, gerne sofort melden.

[1:02:17] Ich würde jetzt noch mal kurz auf diesen Traum, das Silicon Valley und et cetera, zurückkommen.
Ihr seid ein Team von zehn Personen. Ich könnte mir vorstellen, dass das alles so megaspannend klingt, dass die ein oder der andere Hörer, Hörerin grade überlegt, euch zu erreichen, ob's bei euch nicht vielleicht tatsächlich auch eine Jobposition gibt.
Ist das geplant in Zukunft?
Ja, in Zukunft auf jeden Fall. Also wir werden sicherlich personell wachsen müssen, um die Menge an Aufgaben zu erledigen.
Allein die Cloud-Services und dann nebendran eben noch die Open-Source-Projekte fressen sehr viel Zeit, Energie und Liebe.
Jetzt für diesen Moment tatsächlich noch nicht. Wir werden uns jetzt in den nächsten Wochen erstmal sortieren und dann hoffentlich mit einem guten Plan auch ins Hiring starten.

[1:03:08] Also wenn die Sendung rauskommt, habt ihr vielleicht schon 10 Passagen, ansonsten kann man ja mal gucken.
Aber was natürlich immer geht und das ist ja das Schöne an einem Open Source Projekt, jeder kann contributen und damit sind natürlich nicht nur Code Contributions gemeint, sondern eben auch und das haben wir zum Glück auch ganz, ganz viel engagierte Community Member, die dann in die Dokumentation rein contributen.
Zum Beispiel.
Das vergisst man immer ganz schnell, dass Contributions nicht nur auf Code Ebene stattfinden müssen.

[1:03:38] Wir haben gerade schon mit der lieben Hörerschaft Kontakt aufgenommen.
Philipp, du hast uns auch schon mal angeboten, dass wir noch eine zweite Episode vielleicht mal aufnehmen könnten, wo wir tatsächlich auch technisch auf das Produkt eingehen könnten.
Wir haben jetzt nur ganz, ganz, ganz am Rande irgendwie angemerkt, es gibt Extensions-Format und es gibt so generellen Blog-Ansatz, aber wir sind ja heute gar nicht tief eingestiegen.
Daher auch an alle Personen, die gerade zuhören, probiert es gerne mal aus.
Wie habt ihr heute auch gehört, generell frei zu verwenden, einfach einen MPM-Install oder einen PNP-Install oder einen JAN-Install.
Und dann sammeln wir super gerne mal Fragen und nehmen natürlich auch gerne das Angebot wahr, dann vielleicht nochmal eine zweite Revision aufzunehmen.
Weil ich könnte mir vorstellen, dass man sonst vielleicht dann doch diesen 99 Dollar oder den Enterprise Contact me CTA-Button drücken muss für so einen krassen Insider-Support.
Also da gerne Fragen sammeln und an uns weiterschicken.
Wir haben jetzt generell schon einige Punkte durchgegangen. Philipp, gibt es von deiner Seite noch irgendwas, worüber du sprechen möchtest, nochmal anmerken möchtest?

[1:04:51] Ich glaube am Ende, weil wir selber als Developer jeden Tag mit Open Source Software zu arbeiten, alle Hörerinnen und Hörer da draußen zu ermutigen, selber Open Source Software zu entwickeln, damit Erfahrung zu sammeln und wenn es nur ein ganz kleines eigenes Produkt auf GitHub ist, uns zu kontributen, weil das am Ende das ist, was uns und das Internet ja groß gemacht hat und worauf eigentlich alles fußt.
Und ich glaube, das Privileg haben zu dürfen, nicht nur Open-Source-Software zu konsumieren, sondern auch eben was zurückzugeben, das sollten wir schon alle nutzen.

[1:05:28] Mega gut gesagt. Also Einladung ist da. Jeder kann mitmachen, der möchte.
Danke, dass du uns ein bisschen erzählt hast, wie der Werdegang für euch als Company war und natürlich auch viel Erfolg jetzt für das Sortieren, wie du gesagt hast.
Wir versuchen es relativ transparent und so oft wie es geht, zwischen unseren Tasks auf LinkedIn, Twitter und unserem Blog zu schreiben, damit ihr alle teilhaben könnt.
Super, dann denke ich, können wir hier an der Stelle den Deckel drauf machen.
Es hat mich wahnsinnig gefreut, Philipp, dich hier bei uns begrüßen zu dürfen.
Es klingt super, was ihr macht.
Ich schließe mich Hans an und ich wünsche sehr viel Erfolg. Und unabhängig davon, ob es jetzt wirklich eine technische Deep-Dive-Folge noch mal geben sollte oder nicht, wir hoffen natürlich auf viele Fragen, wenn nicht, dann komme ich einfach mit allen Fragen auf.
Aber ansonsten hoffe ich dennoch sehr, dass wir uns vielleicht in ein, in zwei, in fünf Jahren hier beim Working Draft wiederhören, um dich dann mit deinem Netflix-Film und Wohnort in San Francisco vielleicht begrüßen zu dürfen.
Wie gesagt, hat mich sehr gefreut. Vielen Dank an alle Hörer und Hörerinnen draußen.
Und dann hören wir uns nächste Woche wieder. Macht's gut. Ciao, ciao.
Vielen Dank. Bis dahin.

[1:06:46] Music.

[1:07:09] Tschüss.