#76 Mit Open Source 100.000$ verdienen, Sponsorware und Plattform-Risiken bei GitHub mit Martin Donath

Kann man von einem Open-Source-Projekt seinen Lebensunterhalt verdienen?

Martin Donath ist einer der wenigen Menschen im deutschsprachigen Raum, der über 100.000 USD mit Open Source Sponsorengeldern verdient. Mit seinem Projekt Material for MkDocs hat er das Sponsorware-Model erfolgreich implementiert und dies somit zu seinem Vollzeitjob gemacht.

In dieser Episode stellt sich Martin unseren Fragen und wir sprechen über Open Source und wann die Maintenance eines Projektes wirkliche Arbeit wird, was Sponsorware ist, über den Churn von Sponsoren, Pricing-Strategien, Release-Zyklen, den Umgang mit internen Prozessen in Unternehmen, Platform-Risiken bei GitHub Sponsors und viele weitere Themen, die Open Source alles andere als eine schöne Grüne Wiese erscheinen lassen.

Bonus: Was Material for MkDocs mit Stripe gemeinsam hat.

Das schnelle Feedback zur Episode:

👍 (top) 👎 (geht so)

Sprungmarken

(00:00:00) Intro

(00:01:16) Das Problem der Finanzierung von Open Source mit Martin Donath

(00:02:36) Vorstellung Martin Donath und 100.000 USD mit Open Source verdienen

(00:05:42) Das Projekt Material for MkDocs: Documentation that simply works

(00:08:22) Die ursprüngliche Motivation ein neues Theme zu erstellen

(00:12:07) Ab wann ist das Open Source-Projekt richtige Arbeit geworden?

(00:14:58) Wie hast du die Motivation über die Zeit hochgehalten?

(00:17:13) Wie war der Schritt zur Monetarisierung des Themes?

(00:20:09) Wie funktioniert Sponsorware

(00:22:33) Sponsoren-Churn

(00:23:48) Entwicklung der Features, Release-Strategie und Kunden-Feedback

(00:32:36) Konkurrenz-Produkte und Zielgruppen

(00:34:07) Informationen über die GitHub Sponsoren, Kontakt und Paypal

(00:36:02) Was ist GitHub Sponsors und Source Code Leaks

(00:38:35) Pricing-Strategien, Unternehmen und Self-Service bei GitHub Sponsors

(00:48:38) Sponsorbot, Software as a Service und Platform-Risiko

(01:01:16) Warum hat GitHub Paypal abgeschaltet und Enterprise-Ausrichtung von GitHub

(01:08:24) GitHub Sponsor-Geld als Gehalt, Steuern und Total Compensation

(01:11:37) Sponsern von anderen Projekten und Contributor-Fund

(01:13:16) Tips zur Anwendung von Sponsorware

Hosts

Wolfgang Gassler (https://mastodon.social/@woolf)
Andy Grunwald (https://twitter.com/andygrunwald)

Feedback (gerne auch als Voice Message)

EngKiosk Community: https://engineeringkiosk.dev/join-discord
Email: stehtisch@engineeringkiosk.dev
Mastodon: https://podcasts.social/@engkiosk
Twitter: https://twitter.com/EngKiosk
WhatsApp +49 15678 136776

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Martin Donath (00:00:03 - 00:00:33)

Github hat im Januar angekündigt, dass Paypal abgeschaltet wird. Das hatte zur Folge, dass alle Sponsorings, die über Paypal bezahlt werden, automatisch gekündigt werden. Ich habe Github währenddessen gecrawlt und habe hochgerechnet, dass das wahrscheinlich 240.000 Dollar pro Monat an Sponsorings vernichtet hat. woanders gesehen, dass jemand eine Amazon-Wishlist hatte. Und da dachte ich mir, weißt du was, dann mache ich einfach das. Ich mache einfach eine Amazon-Wishlist, ich probiere das mal aus. Und da kamen tatsächlich Sachen. Und das war so absurd, weil da war ein Whisky drauf, der kostet 120 Euro und der kam.

Wolfi Gassler (00:00:38 - 00:01:11)

Willkommen zu einer neuen Episode des Engineering Kiosks. Von Open Source leben zu können ist ein Traum vieler EntwicklerInnen. Martin Donat hat diesen Traum in die Realität umgesetzt und das mit einem Theme für Dokumentation. In dieser Episode sprechen wir mit Martin über den mehrjährigen Weg zu 100.000 Dollar in einem Jahr mit Open Source Sponsorware, die Herausforderungen von Open Source Maintenance, die Akquise von Sponsoren, die Vor- und Nachteile von GitHub Sponsors und sein allerneuerstes Projekt, mit dem man auch anderen Open Source EntwicklerInnen mit dem SponsorWare Approach helfen will. Und los geht's!

Andy Grunwald (00:01:15 - 00:02:15)

Heute geht es mal wieder um eins meiner Herzensthemen, Open Source. Und ich würde sagen, jeder Software-Ingenieur hat irgendwie einen Beruhigungspunkt mit Open Source. Und immer wenn man auf Open Source schaut, dann sieht man ganz viele Repositories bei GitHub und das sieht immer so aus, als wäre da alles toll und immer die tolle grüne Wiese mit ganz vielen Bienchen. Doch wenn man da mal ein bisschen mehr in dem Thema drin ist, dann merkt man relativ schnell, dass es eine ganze Menge riesiger Probleme gibt. Ein riesen Problem ist zum Beispiel die Finanzierung von Open Source bzw. von den Leuten, die an Open Source arbeiten. Denn die meiste Open Source Arbeit findet wirklich in der Freizeit statt. Und das ist nämlich auch der Grund, warum eure Pull-Requests manchmal monatelang rumliegen, weil diese Menschen halt auch noch ein Leben drumherum haben. Ob das Finanzierungsproblemen schon im Allgemeinen gelöst wurde, darüber streiten sich eine ganze Menge Leute, aber heute haben wir uns auf jeden Fall einen Gast in den Podcast geholt, der dieses Problem zumindestens für sich ganz stark gelöst hat.

Wolfi Gassler (00:02:15 - 00:02:21)

Jemand, der eine Ahnung davon hat, weil Andi, wie viel hast du schon bekommen an Sponsorgeld? Ist es schon zweistellig in deinem ganzen Leben?

Andy Grunwald (00:02:22 - 00:02:31)

Also ich glaube 100 Euro oder so habe ich über GitHub Sponsors schon verdient über die letzten 14 Jahre. Also mein Stundensatz ist da relativ mies, glaube ich.

Wolfi Gassler (00:02:31 - 00:02:36)

Und darum haben wir uns jemanden geholt, der auch davon leben kann, von Open Source Sponsoring.

Andy Grunwald (00:02:36 - 00:02:38)

Ich begrüße Martin. Hallo.

Martin Donath (00:02:38 - 00:02:38)

Hi.

Andy Grunwald (00:02:38 - 00:02:43)

Stell dich doch mal bitte ganz kurz vor. Wer bist du und wie und warum verdienst du Geld mit der Open Source?

Martin Donath (00:02:44 - 00:03:47)

Ja, also erstmal vielen Dank für die Einladung in den Podcast. Freut mich sehr, dabei sein zu dürfen. Mein Name ist Martin Donat und ich bin so ein Typ, ich liebe es einfach, Produkte zu bauen. Also digitale Produkte. Und zwar von vorne bis hinten. In dem Sinne, dass ich Fullstack-Engineer bin. Das heißt, ich baue den Unterbau, aber auch das ganze Frontend und kümmere mich um den Betrieb und so weiter. Und das Ganze mache ich seit insgesamt 18 Jahren, also nicht als Full-Stack-Engineer. Ich habe natürlich erst mal angefangen mit schön irgendwie Webseiten bauen, irgendwie Frontend und Pixel hin- und herschieben. Aber über die Zeit habe ich dann quasi meine Expertise ein bisschen ausgebaut und bin seit zwölf Jahren insgesamt im Open-Source-Bereich unterwegs. Mein Stack besteht hauptsächlich aus TypeScript aktuell, relativ viel CSS, beziehungsweise SCSS, HTML. Ich habe aber in meiner Laufbahn auch schon C und C++ geschrieben, Erlang, Ruby, mache viel Terraform auch, um eben Infrastruktur auf AWS zu deployen. Und im Netz bin ich bekannt als SquidFunk. Darunter findet man mich auf GitHub und auf Twitter.

Andy Grunwald (00:03:48 - 00:04:08)

Ich habe dich aber leider nicht über Twitter oder GitHub gefunden, sondern ich habe dich als Sprecher auf dem lokalen Webworker NRW Meetup in Düsseldorf, für dich die feindliche Stadt, getroffen. Dort hast du einen Talk mit dem provokanten Titel mit Open Source von 0 auf 100.000 Dollar pro Jahr gehalten. Hast du wirklich 100.000 Dollar mit Open Source verdient?

Martin Donath (00:04:08 - 00:04:50)

Also erstmal muss ich sagen, ja, ich bin Wahlkölner, aber ich habe keine Abneigung gegen Düsseldorf. Das liegt mir irgendwie nicht im Blut. Mir ist das relativ egal, genau. Aber der Chef vom Working Draft Podcast, in dem ich schon zweimal zu Gast war, hatte mich letztes Jahr gefragt, ob ich Lust habe, einen Vortrag zum Sponsorware-Thema zu halten, weil der das auch mitbekommen hat. Wir haben in einem Podcast darüber gesprochen. Zu der Zeit, zu dem ich den Talk gehalten habe, wir waren bei 89.000 Dollar pro Jahr, also wir waren noch nicht bei den 100.000, deswegen hieß der Vortrag auch auf dem Weg zu 100.000. Mittlerweile habe ich das erreicht. Das ist halt so eine, ich finde das ist so eine psychologische Grenze, wenn man, also 100.000 ist einfach so für Normalverbraucher quasi damit, dann hat man es quasi geschafft, wenn man das Also es ist einfach so eine psychologisch wichtige Zahl.

Wolfi Gassler (00:04:50 - 00:05:17)

Wie der Andi mir das erzählt hat, als er bei diesem Talk war, hat er natürlich auch erzählt, da gibt es jemanden, der die 100.000-Marke geknackt hat oder der 100.000 Dollar verdient mit dem Projekt. Also es scheint schon irgendwie dieses Geld sehr im Vordergrund zu stehen. Ist das, weil im Open-Source-Bereich das einfach sehr selten ist, dass man Geld damit verdient oder wollen Leute einfach viel Geld verdienen? Wirst du oft auf dieses Thema angesprochen, dass du jetzt im Open-Source-Bereich wirklich über 100.000 Dollar verdient hast?

Martin Donath (00:05:17 - 00:05:41)

Das ist nicht so ein primäres Thema. Es gibt immer Hater, die einem das quasi nicht gönnen. Es ist natürlich einfach, jetzt einfach nur diese Zahl zu sehen und zu sagen, naja, der verdient jetzt 100.000 damit, das ist ja total unfair, weil Open Source sollte doch umsonst sein. Aber man muss auch die harte Arbeit dahinter sehen. Es ist so, dass ich die ersten vier Jahre, die ich dieses Projekt gemacht habe, und ich mache es jetzt seit sieben Jahren, überhaupt nichts damit verdient habe.

Wolfi Gassler (00:05:41 - 00:05:51)

Bevor du da einsteigst, um was für ein Projekt geht es denn eigentlich? Also was für ein Projekt hast du da aufgestellt, mit dem man wirklich so viel Geld verdienen kann? Jetzt reduziere ich das auch schon wieder alles nur auf das Geld.

Martin Donath (00:05:51 - 00:07:30)

Also mein erfolgreichstes Open Source Projekt nennt sich Material for MKDocs. Ich werde das jetzt im weiteren Verlauf einfach nur Material nennen. MK-Docs ist ein Static Site Generator, der ist quasi eine Dependency von meinem Projekt, also das Material für MK-Docs versteht sich als, mittlerweile würde ich es als Dokumentationsframework bezeichnen. Es hat angefangen als Veeam, also es ist einfach nur ein Veeam, so gesehen. was mit der Hilfe von mkdocs eben eine statische Seite generiert. Und die Zielgruppe bzw. der Use Case ist technische Dokumentation. Die Tagline ist Documentation that simply works. Das heißt, die Idee ist, du schreibst deine Dokumentation in Markdown, hast einen Ordner mit mehreren Dateien und erteilst die, sodass es Sinn macht. schmeißt das auf Material4MKDocs drauf und hinten raus putzelt eine fertige Seite. Die ist durchsuchbar, die ist responsive, die Suche ist komplett kleinzeitig. Das heißt, die ganze Seite kann einfach in Static Site Hosting gehostet werden und zwar kostenlos auf GitHub Pages. Es ist kein unmittelbares Wissen notwendig aus dem Web-Bereich. Das heißt, wenn du keine Ahnung von Webentwicklung hast, kannst du trotzdem eine super professionell aussehende Seite generieren. Das Projekt wird mittlerweile von mehreren zehntausend Projekten benutzt auf GitHub. Also auf GitHub kann man das direkt nachvollziehen und zu den unter anderem auch von vielen Organisationen und zu den berühmtesten oder zu den bekanntesten Organisationen zählen unter anderem AWS, Google, Microsoft, Netflix, Apple, Mozilla und viele mehr. Einige davon sponsern auch, aber nicht alle.

Andy Grunwald (00:07:30 - 00:07:39)

Nur, damit ich das richtig verstehe. Du verdienst aktuell deinen Lebensunterhalt mit der Open-Source-Maintenance von einem SIEM für technische Dokumentation.

Martin Donath (00:07:40 - 00:08:22)

Ich kann es selbst kaum glauben, weil als ich das Projekt angefangen habe, hätte ich niemals gedacht, dass das überhaupt möglich ist, weil man kennt ja so diese Seiten wie, ich glaube, Veeam Forest oder so. Also normalerweise bezahlt man für ein Veeam, für ein WordPress-Veeam zum Beispiel irgendwie 79 Dollar oder so einmalig und dann war es das. Mit dem Projekt habe ich es irgendwie geschafft und auf dieses irgendwie werden wir jetzt gleich noch eingehen, weil man stolpert so ein bisschen vor sich her, also man probiert halt verschiedene Sachen einfach aus, weil Das heißt, alles was ich jetzt erzähle, das ist meine Erfahrung, das ist jetzt keine Blaupause dafür, dass man das genauso nochmal machen kann, aber ich glaube, ich bin der festen Überzeugung, dass es auf jeden Fall auf andere Projekte übertragbar ist.

Wolfi Gassler (00:08:22 - 00:08:38)

Was war denn die ursprüngliche Motivation, eigentlich da ein Theme zu erstellen, weil ich schätze mal, es gibt, verwendt mkdocs auch irgendwo, ich habe ehrlich gesagt keine Ahnung mit was für einem Theme, hätte jetzt nachschauen sollen natürlich. Aber es gibt ja massig Themes, also warum hast du überhaupt begonnen, dann ein eigenes zu entwickeln?

Martin Donath (00:08:38 - 00:10:01)

Das ist eine sehr gute Frage. Zu der Zeit, zu der ich mit dem Projekt gestartet bin, wollte ich ein anderes Open-Source-Projekt veröffentlichen. Das ist auch noch Open-Source, Protobluff heißt das. Das ist eine Protocol-Buffers-Implementierung für C mit einer etwas anderen Art der Implementierung als die Standard-Google-Implementierung. Und ich habe relativ schnell gemerkt, dass dieses Projekt so komplex ist, dass es eine Dokumentation benötigt. Meine vorherigen Open-Source-Projekte waren alle eher so kleinere Projekte. Da hat einfach eine README gereicht. Aber man kennt das ja, dann findet man ein Open-Source-Projekt und scrollt die README durch und denkt sich, boah, das müsste man mal auf ein paar Seiten aufteilen, weil das einfach viel zu viel ist auf einer Seite und man findet nichts mehr. Und das war bei diesem Projekt auch so. Und dann hab ich mich umgeschaut, was es für Generatoren gibt, um technische Dokumentation zu generieren, und hab dann relativ schnell Sphinx und Hugo gefunden, und MK-Docs, und hab mir die Vims angeschaut, und die sahen alle irgendwie so ein bisschen dated aus. Und ich bin ein sehr visueller Mensch, Hab 2005 angefangen, auch erstmal überhaupt Frontend zu programmieren. Webdesign habe ich schon noch länger gemacht. Also habe ich eigentlich so mit 14, 15 habe ich so meine ersten Webseiten zusammengebaut mit Frontpage. Ich glaube, da kommen wir irgendwie alle her wahrscheinlich fast. Und ja, habe dann irgendwie angefangen. Dann dachte ich mir, okay, dann baue ich halt eine vernünftige Webseite, weil ich will auch, dass es irgendwie gut aussieht. Und habe dann aber relativ schnell festgestellt, warum mache ich nicht einfach ein Open-Source-Projekt daraus? Also habe dann ein Open-Source-Projekt für mein Open-Source-Projekt gebaut.

Wolfi Gassler (00:10:01 - 00:10:19)

Und wie schnell hat es dann funktioniert, dass das andere Leute verwendet haben? Weil man macht ja so ein Open-Source-Projekt, stellt das mal online, aber man hat da ja auch Konkurrenz. Es gibt eben andere Themes. War das einfach so gut, dass sofort alle Leute aufgesprungen sind und du hattest innerhalb kürzester Zeit dann ganz viele User? Oder wie lange hat das ungefähr gedauert?

Martin Donath (00:10:19 - 00:11:30)

Nee, also überhaupt nicht. Ich hab das, wenn man sich die Kurve anschaut zu den Stars, die das Projekt hat, dann sieht man ein sehr, sehr natürliches Wachstum. Es war relativ wenig am Anfang. Ich glaube, im ganzen ersten Jahr gab es vielleicht irgendwie 300 Stars oder so. Und das machen wir jetzt, also auch wenn Stars jetzt nicht die beste Metrik ist, aber so ein bisschen, um die Popularität einzuschätzen, das machen wir jetzt halt im Monat, also sogar mehr. Deswegen, das Projekt, ich hab, was ich gemacht habe, ist, ich hab die, den Maintainern von mkdocs geschrieben, die haben das dann auch so ein bisschen promotet, die fanden das richtig cool, weil die selber keine Frontendler sind und hab das dann, ich hatte auch ein super kleines Twitter-Following, also ich hab wirklich von null angefangen, hab das dann auch so ein bisschen auf Twitter eben rausgehauen und so, und dann ist das halt nach und nach und nach einfach natürlich gewachsen, lustigerweise. Und ein Trick, den ich gemacht habe und bis heute mache, ist, im Footer der Seite ist ein kleiner Hinweis, also der generierten Seite, wenn du jetzt deine Dokumentation damit generierst, ist ein kleiner Hinweis, der sagt, made with material for mkdocs. Und das ist ein Backlink auf die eigene Dokumentation von dem Projekt. Und das hat, glaube ich, massiv zum Wachstum beigetragen, weil ich sehr, sehr, auch nach wie vor, sehr viele Referrals sehe von ganz, ganz, ganz verschiedenen Seiten.

Andy Grunwald (00:11:30 - 00:11:49)

Nur nochmal, um das zusammenzufassen. Das Ding ist als Nebenprodukt rausgefallen, weil du ein anderes Projekt machen wolltest und hast dir gedacht, dein originales Projekt, was mit Protobuff zu tun hatte, hatte keine Dokumentation und dann hast du Yakshafing betrieben, bist aus Rabbit Hole runtergegangen und jetzt verdienst du deinen Lebensunterhalt mit einem Thiem. Ist das richtig?

Martin Donath (00:11:49 - 00:11:50)

Ja, das ist genau richtig.

Andy Grunwald (00:11:50 - 00:11:52)

Und mein Kopf grad so.

Martin Donath (00:11:54 - 00:12:06)

Ja, also, wie gesagt, hier hätte er das auch nicht gedacht. Und das Protobluff-Projekt, das hat vielleicht insgesamt 75 Stars oder so, oder keine Ahnung. Also, das nutzt keiner. Und das andere Projekt ist durch die Decke gegangen, wenn man so möchte.

Wolfi Gassler (00:12:06 - 00:12:33)

Ab wann war denn der Zeitpunkt, dass es irgendwie Arbeit geworden ist, wo du gesagt hast, oh, das ist irgendwie diese ganze Maintenance und so weiter, jetzt wird's irgendwie ... Ja, Arbeit und weniger Spaß, weil ich schätze mal zu Beginn war es ja mal cool auch Sterne zu bekommen. Man hat diese erste Phase, wo man sich freut, dass andere Leute das verwenden und man bekommt vielleicht auch gutes Feedback. Also wie viel, wie viel Zeit hast du da vielleicht auch investiert am Anfang oder wann wurde es dann zu viel Zeit auch?

Martin Donath (00:12:33 - 00:12:46)

Ja, ich habe auch am Anfang, als ich in den, in Open Source eingestiegen bin, definitiv versucht, diese Stars-Metrik so ein bisschen zu optimieren, beziehungsweise hat mich natürlich gefreut, wenn das Projekt dann bekannt geworden ist.

Wolfi Gassler (00:12:46 - 00:12:52)

Also du hast schon wirklich Marketing auch gemacht, also bewusst jetzt irgendwie auf Twitter oder so, also schon bewusst Tweets abgesendet.

Martin Donath (00:12:52 - 00:14:13)

Ja, definitiv, klar, von Anfang an, aber ich hatte eine super kleine Audience. Also ich hatte bis 2020, also 2020, als ich quasi mit Sponsorware angefangen habe, hatte ich 250 Follower auf Twitter, also das ist gar nichts. Genau, die Frage war, wann es sich nach Arbeit angefühlt hat. Die ersten Jahre war es so, dass natürlich relativ ... Also, es waren nicht so viele Nutzer, aber es waren Nutzer da. Und Feature-Requests und Bugs wollte ich relativ schnell beheben. Klar, weil Bugs beziehen sich auf Funktionalität, die schon da ist. Aber dann kamen nach und nach mehr Feature-Requests in die Richtung, die haben Sachen gefragt, die ich persönlich nicht gebraucht habe. Zum Beispiel eine komplette Übersetzung. Also quasi eine Translation-Engine sozusagen. So ein Unterbau, mit dem man Translations machen kann. Und da ist dann die Frage, machst du das? Möchtest du das maintainen? Weil für dich reicht es natürlich, wenn es auf Englisch funktioniert, aber du möchtest natürlich auch die Zielgruppe erweitern. Also ist es ökonomisch, das Ganze zu erweitern? Möchtest du es maintainen, ja oder nein? Weil du deine Zielgruppe erweiterst. So genau. Das ist so ein bisschen die Frage, die man sich halt stellen muss. Und in den ersten Jahren ging es hauptsächlich um Features, die ich sowieso gebaut hätte. Das heißt, das waren Sachen, wo ich sage, macht total Sinn, machen wir, mache ich, will ich selber haben, finde ich eine coole Idee. Ja, so nach und nach ist das dann halt mehr und mehr geworden und dann hat es sich quasi so nach drei, vier Jahren fing es dann langsam an, wirklich sich nach Arbeit anzufühlen, weil das Community-Management dann natürlich auch relativ viel Zeit in Anspruch nimmt.

Wolfi Gassler (00:14:13 - 00:14:20)

Und du hattest einen Fulltime-Job nebenbei. Also du hattest das nebenbei wirklich alles gemacht oder warst du irgendwie flexibler?

Martin Donath (00:14:20 - 00:14:57)

Also ich bin seit 18 Jahren Freelancer. Ich war noch nie angestellt und konnte mir das ganz gut ein bisschen einteilen. Hab aber natürlich relativ viel nebenbei dran gearbeitet. Ich weiß ehrlich gesagt gar nicht mehr, wie das funktioniert hat alles. Aber hab dann halt irgendwie abends ein bisschen was dran gemacht oder am Wochenende. Aber insgesamt in den ersten vier Jahren war der Progress so langsam, aber halt stetig. Ich habe immer versucht, quasi die Community auch aufzubauen, am Laufen zu halten und so weiter und das Projekt interessant zu halten, weil ich natürlich auch wollte, dass es weiter wächst, aber ich wusste nicht, wohin. Also ich hatte kein Ziel, dass ich gesagt habe, ich möchte das irgendwann monetarisieren. Das war überhaupt nicht das Ziel. Das war einfach nur mal gucken, wie weit es geht. Keine Ahnung.

Andy Grunwald (00:14:57 - 00:15:59)

Du hattest gerade von der Frage gesprochen, ist das sinnvoll, dass du jetzt die Bugs von anderen Leuten fixt oder Features implementierst, die du gar nicht brauchst. Und so geht es mir eigentlich auch. Du hast ein Projekt, du bist glücklich, dass Leute das nutzen, du kriegst irgendwie Bug-Tickets rein und Features, die du jetzt gar nicht brauchst. Und dann fängst du das an, irgendwie zu entwickeln, weil du hast dann noch ein bisschen Passion und vielleicht auch gerade so ein bisschen Zeit und irgendwann wird es mehr, mehr, mehr. Dann kriegst du vielleicht so ein bisschen Stress, weil du halt deine GitHub-E-Mails nicht mehr beantworten kannst und so weiter. Und irgendwann kommt dann bei mir der Punkt, ja Moment mal, Warum soll ich denn jetzt komplett meine Freizeit hier reinstecken, um Features und Bugs für andere Leute zu fixen, die mich gar nicht betreffen und die machen dann gegebenenfalls noch irgendwie Geld damit? Ich glaube, das ist schon so die Vorstufe von diesem Open-Source-Burnout, was ziemlich viele Leute irgendwie auf den Blogs lesen und posten. was war denn deine intention da überhaupt so weiterzumachen weil ich meine so ein ding vier jahre lang zu betreiben und auch community management und so weiter ohne wirkliche absichten und ohne plan zur monetarisierung wo du jetzt zum beispiel bist hast du dir die frage nie selbst gestellt so warum mache ich das jetzt alles für andere leute damit die erfolgreich sind.

Martin Donath (00:15:59 - 00:17:12)

Und so weiter Also das ist mit dem Open-Source-Gedanken an sich, der hat, glaube ich, in der ersten Zeit noch ein bisschen mehr dominiert. Also das ist ja wirklich mein erfolgreichstes Projekt. Ich hatte das vorher nicht. Ich war vorher nicht in dieser Situation. Und ich war dann zum ersten Mal so langsam, das schleicht sich ja so ein, so langsam kommt man dann in diese Situation, weil dann kommen mehr Feature-Requests oder zum Beispiel auch, dann kommen extrem seltsame Bugs, die du, zum Beispiel gab es das Problem, dass Material auf chinesischen Systemen nicht richtig ausgesehen hat. Und das war so schwierig für mich nachzuvollziehen. Und am Ende haben wir rausgefunden, woran's lag. Aber das ist jetzt was, na ja, es betrifft mich jetzt nicht direkt, aber es, ja, fühlt sich dann halt ... Also, man will es ja trotzdem schon lösen. Und wie gesagt, das ist so ein schleichender Prozess. Und ich glaube, dass das bei mir so war, dass ... Also, ich hatte diese Gedanken ... Nicht insgesamt. Es war für mich halt wirklich ein Side-Project und ich hab das wirklich auch eher so als, naja, es ist halt ein Veeam, das kann man nicht monetarisieren. Das war halt auch schon, dieser ganze Gedanke war die ganze Zeit so, das ist ein gelöstes Problem. Also ich hab halt, ich hab jetzt ein gutes Veeam gebaut, definitiv, was auch viele Leute benutzen und viele Leute gut finden, aber in meinem Kopf war es abgehackt, als kann man kein Geld mitverdienen, ist gelöst.

Wolfi Gassler (00:17:12 - 00:17:31)

Und wie ist dann der Schritt zur Monetarisierung gekommen überhaupt? Weil ist dann jemand auf dich zugekommen und hat gesagt, ich zahle dir für dieses Feature irgendwas? Oder bist du selber auf die Idee gekommen? Also was hat denn den Klick gemacht, wo du gesagt hast, okay, es ist zwar ein Theme, aber ich muss es trotzdem irgendwie monetarisieren oder ich will zumindest.

Martin Donath (00:17:31 - 00:22:32)

Ja, also ich habe Ende 2019 angefangen, eine neue Technologie zu lernen, RXJS, und dachte, wow, das ist ja ein perfekter, also Material ist ein perfekter Use Case dafür, das mal auszuprobieren, weil ich einfach mich mit Functional Reactive Programming auseinandersetzen wollte, jetzt mittlerweile, also nach wie vor Riesenfan davon bin. Und hab dann angefangen es umzubauen, hab das alles dokumentiert und das war dann quasi der Sprung von Version 4 auf Version 5. Also das Projekt ist gewachsen über die Zeit und es war einfach ein Refactoring notwendig. Ich musste eine neue Grundlage schaffen, um neue Features bauen zu können. Das vorherige Eventsystem war mehr oder minder selbst geschrieben. Es hat einfach Sinn gemacht, diesen Unterbau auszutauschen. Ich habe das als Testbed gesehen. Also einfach nur als, ich möchte das jetzt lernen. Das habe ich dann alles dokumentiert und dann hat irgendein Nutzer, beziehungsweise ich weiß genau welcher Nutzer, hat geschrieben, als weiteren Punkt, als weiteres To-Do, füge einen Donation-Button hinzu, damit SquidFunk sich Pizza bestellen kann. Und ich dann so, okay, das ist ja total süß, aber der funktioniert einfach nicht. Und ich habe vorher einen Podcast gehört zu dem Thema, in dem ein anderer ziemlich bekannter Entwickler, also der hat auch ein sehr großes Twitter-Following, aus seinem Open-Source-Projekt ein Produkt gebaut hat. Das heißt, er hat das Open-Source-Projekt archived und hat es komplett kommerziell gemacht. Und er hat gesagt, er hatte einen Donation-Button auf seiner Seite und er hat in drei Jahren 90 Dollar damit verdient. Deswegen war in meinem Kopf, funktioniert nicht das habe ich dann auch drunter geschrieben also das funktioniert nicht dann hat jemand anders drunter geschrieben so ja aber eine pizza ist ja besser als keine pizza ok gut und dann habe ich woanders gesehen dass jemand eine amazon wishlist hatte und da dachte ich mir weißt du was dann mache ich einfach das ich mache einfach eine amazon wishlist ich probiere das mal aus. Dann hab ich auf diese Wishlist so ein paar Bücher, die ich mir noch holen wollte, bestellt. Und ich bin ein Riesenfan von schottischem Whisky. Ein paar schottische Whiskys draufgepackt. Und da kamen tatsächlich Sachen. Und das war so absurd, weil da war ein Whisky drauf. Der kostet 120 Euro. Und der kam. Und da hab ich irgendwie langsam verstanden, krass, ich glaube, ich hab wirklich Nutzer, die sind echt super happy mit dem Projekt und die möchten das wirklich gerne unterstützen. Und die sehen da auch einen, ja, die sehen da so den Sinn drin einfach, dass sie bereit sind, dafür Geld zu bezahlen. Und dann habe ich kurz später darauf von Sponsorware gelesen. Das ist ja im Endeffekt einfach nur ein Konzept. Und der Begriff Sponsorware, der ist von Caleb Porcio. Der hat auch einen Blogartikel geschrieben, der geht auch so ein bisschen in die Richtung. Der heißt auch irgendwie 100.000, also I just hit 100.000 Dollars on GitHub Sponsors. Und dann hat er eben gesagt, was er gemacht hat. Der hat ein riesen Twitter-Following. Dann habe ich über dieses Konzept gelesen und habe dann gedacht, okay, wie kann ich das anwenden? Und am besten, ich erzähle erstmal kurz, wie Sponsorware an sich funktioniert. Sponsorware, wie ich gerade schon gesagt habe, ist eigentlich nur ein Konzept. Das heißt einfach nur, dass du deinen Sponsoren, also andere Nutzer können dich sponsoren, können dir Geld bezahlen. Und sie unterstützen damit deine Open-Source-Arbeit. Ob du ihnen etwas gibst, ist erst mal dir überlassen. Du kannst auch einfach nur sagen, ihr könnt euer Logo platzieren, für Unternehmen zum Beispiel, in unserer Readme, um zu zeigen, ihr unterstützt das Projekt. Oder du gibst ihnen zum Beispiel Early Access zu neuen Features, die du entwickelst, oder zu einem Projekt, was komplett private ist. Und Caleb Porizio hat das mit einem komplett neuen Projekt gemacht. Ich meine, er hatte 30.000 Follower auf Twitter zu dem Zeitpunkt. Und das ist natürlich ein bisschen einfacher, so den Stein ins Rollen zu kriegen. Man macht einen schönen Screencast, sagt so, hey, wie cool wäre es, wenn man das und das machen könnte. Und ich glaube, er kommt aus der Livewire, also Laravel-Community, und hatte dann ein privates Repo und jeder, der ihn gesponsert hat mit einem bestimmten Betrag, Ich glaube, 14 Dollar waren das, hat Zugriff zu diesem Repository bekommen. Jetzt hatte ich ja schon ein Projekt, was relativ erfolgreich war. Material hatte zu dem Zeitpunkt circa, ich glaube, dreieinhalbtausend Stars. Aktuell sind wir bei 14.000. 2020 war das. Und hab überlegt, wie kann ich das eventuell auf mein Projekt übersetzen? Und meine Idee war, dass ich neue Features, die ich entwickle, in ein privates Repository, also quasi in einem privaten Fork erstrelease, Und jeder, der mich sponsert, bekommt Zugriff zu diesem privaten Fork und kann dann die Features direkt nutzen. Und dieses Sponsor-Web-Prinzip funktioniert so, dass die Sponsoren sozusagen die Entwicklung subventionieren, also bezahlen, und dass ab einem bestimmten Funding-Goal dann bestimmte Features released werden. Also das heißt, Konkretes Beispiel. Das erste Goal waren 500 Dollar pro Monat. Recurring Revenue. Also wirklich nicht nur einmalig, sondern jeden Monat 500 Dollar. Subscriptions. Sponsoren konnten das direkt nutzen. Und alle neuen User mussten warten, bis das 500er-Goal erreicht war. Und dann konnten es alle nutzen. Dann kam das 1000er-Goal, das 1500er, 2000er und so weiter und so fort. Und aktuell laufen wir aufs 12.000er-Goal zu. Also 12.000 Dollar pro Monat. Und da sind dann auch noch mal einige Sachen drin, die sehr, sehr interessant sind und wo ich mich wirklich freue, in die Community Version released werden, weil die nochmal sehr zum Wachstum des Projektes beitragen könnten, da sie eine neue Zielgruppe potenziell erschließen können.

Andy Grunwald (00:22:32 - 00:23:01)

Das bedeutet aber auch, wenn ich jetzt einfach nur ein Feature haben möchte, dann ist deine Theorie, dass ich, obwohl das Feature dann in der Open-Source-Version später released worden wäre, dass ich dann weiter sponsore, richtig? Weil wenn ich das jetzt richtig verstanden habe, du hast mit 500 Euro pro Monat angefangen und jetzt gehst du auf das 12.000 Dollar pro Monat Ziel zu. Also du hoffst eigentlich, dass die Leute, die früher mal gesponsert haben, immer noch sponsoren, obwohl sie das Feature, was sie gesponsert haben, bereits, ich sag mal, auch.

Martin Donath (00:23:01 - 00:23:47)

For free haben können ich will das nicht sugarcoaten bei der größe oder bei der anzahl an sponsoren hat man eine beträchtliche anzahl an schönen usern also es ist so dass einige die wenn wenn bestimmte goals erreicht wurden zum beispiel der dark mode toggle ist so ein sehr gutes beispiel als das goal erreicht wurde hatte ich beträchtlichen Churn, weil dann die Nutzer, die explizit für dieses Feature gesponsert haben, nicht mehr sponsern mussten, weil das alles war, was sie haben wollten. Deswegen kommt es sehr, sehr darauf an, wie man seine Release-Strategie strukturiert und wie man allgemein die Features, die man veröffentlicht, schneidet und in welcher Reihenfolge man die Sachen auch released. Und man muss schon schauen, dass man die Sponsoren bei der Stange hält, definitiv.

Wolfi Gassler (00:23:48 - 00:24:03)

Und programmierst du im Vorfeld diese Features und dann startest du so ein Ziel, das man erreichen muss, um es dann eben public zu machen? Oder machst du das dann währenddessen, dass die Leute einsteigen und du beginnst dann mit der Feature-Entwicklung?

Martin Donath (00:24:03 - 00:24:26)

Ich mach das so, dass die Feature im Endeffekt fertig sind. Also aktuell, wenn du sponserst, bekommst du 27 Features, die nicht in der Community Edition sind, kannst du sofort benutzen. Ich glaube, dass das auch maßgeblich für den Erfolg ist, Die hürde sehr sehr gering ist du musst nicht warten du hast sofort einen benefit davon also sponsors das projekt zum einen du gibst was zurück aber du kriegst auch sofort was.

Wolfi Gassler (00:24:26 - 00:24:33)

Aber solange ich mit dabei bleibe habe ich dann auch zugriff auf die neuen features für das nächste goal und das nächste goal solange ich dabei bleibe.

Martin Donath (00:24:33 - 00:24:34)

Ganz genau richtig.

Andy Grunwald (00:24:34 - 00:24:42)

Und diese 27 Features, die du jetzt gerade erwähnt hast, sind das die 27 Features, die du alle im 12.000er-Goal hast?

Martin Donath (00:24:42 - 00:24:55)

Nee, also ich habe mit den Goals angefangen in 500er-Schritten, dann bin ich irgendwann auf 1.000er-Schritte gegangen, weil das eben sehr schnell gewachsen ist, dann auf 2.000 und jetzt sind wir mittlerweile bei 4.000er-Schritten, also quasi in Abständen von den Defunding-Goals.

Wolfi Gassler (00:24:55 - 00:25:04)

Also Schritten heißt Recurrent Revenue, dass du 4.000 Dollar mehr Sponsoring pro Monat machst, dann wird das jeweilige Set public gemacht.

Martin Donath (00:25:04 - 00:25:42)

Genau, und bis zu dem, ich glaube, 8.000er-Goal hatten wir pro Goal ungefähr drei Features. Also, man kann das alles nachgucken, das ist alles transparent dokumentiert auf der Insiders-Seite in der Dokumentation von Material for MCA Docs. Bis zum 8.000er waren das so drei Features pro Goal, und als dann die ... die Abstände größer wurden, seitdem sind das sechs Features pro Funding Goal ungefähr. Es werden nicht alle 27 released, sondern es tröpfeln quasi immer so welche durch in die Community Edition. Man muss natürlich auch dranbleiben, neue Sachen entwickeln, verstehen, was sind Sachen, die die gewünscht werden, die auch einen großen Impact haben, die potenziell neue Sponsoren anziehen.

Wolfi Gassler (00:25:43 - 00:25:58)

Wie wählst du denn die Features aus? Also wie kommst du auf neue Features? Und idealerweise, wie du ja sagst, sind es Features, die dann irgendwie große Firmen anziehen oder irgendwie große Sponsoren. Also wie wählst du die Features aus? Kommen die rein von der Community als Requests oder denkst du dir die aus?

Martin Donath (00:25:59 - 00:27:44)

Das ist ein bisschen so ein mix da gibt es ja dieses zitat von henry ford wenn man leute gefragt hätte was sie haben wollen dann wären das zehn prozent schnellere pferde aber nicht das automobil da kommt keiner drauf. Das heißt es ist ein es ist eine mischung es sind natürlich viele sachen aus der community die wo dann quasi die neuen features. Probleme lösen also ich versuche insgesamt ist es auch schwierig jetzt mal ganz kurz ganz kurz mal in seitenschlagrichtung maintenance so ein projekt aufzubauen und mehr und mehr und mehr und mehr features hinzuzufügen du musst es extrem gut schneiden also du musst schauen dass du dass du das ding unter kontrolle hältst und eine gute architektur haben Und bei der Auswahl von neuen Features achte ich eigentlich immer darauf, dass ich Mechanismen schaffe, die quasi komplementär sind. Also zum Beispiel, es gibt ein Privacy-Plugin für Material für mkdocs, das ist im 14.000er-Goal. Dieses Plugin erlaubt dir einfach externe Ressourcen zu nutzen, wie Google Fonts, wie Content Delivery Networks. Du kannst auch deine ganzen Screenshots zum Beispiel extern hosten. Und das Plugin lädt die externen Ressourcen zur Zeit des Builds runter, also wenn du mkdocs.build machst und deine Seite generierst, und inlined die komplett. Weil es gab ja dieses Urteil, DSGVO, Google Fonts in München, ich glaube letztes Jahr, dass das schwierig ist zu benutzen und so weiter. Jetzt gibt es ein neues Plugin, das Optimize-Plugin. Das optimiert alle möglichen Ressourcen, zum Beispiel dann Screenshots, rechnet das runter mit PNG-Quant, damit die eben optimal sind für die Darstellung im Web. Und diese beiden Plugins, die arbeiten zusammen, aber die sind in verschiedenen Funding Goals. Und das heißt, ich versuche eben neue Sachen immer so zu bauen, dass wenn ich ein neues Feature entwickle oder ein neues Plugin entwickle für mkdocs, dass das möglichst viele von den Problemen, die meine Nutzer haben, erschlägt.

Wolfi Gassler (00:27:44 - 00:27:56)

Aber bist du da mit Kunden auch in Kontakt? Bekommst du da viel Input von denen, dass du merkst, okay, das scheint jetzt mit Google Fonts ein großes Problem zu sein, weil da 100 Requests reinkommen, dieses Feature wäre cool?

Martin Donath (00:27:57 - 00:28:52)

So viele sind es nicht, also nicht 100 Requests, aber sehr viel kommt über GitHub-Issues rein, definitiv. Also Google Fonts war genau so ein Thema und du konntest von Anfang an bei Material Google Fonts deaktivieren über die Konfiguration. Das heißt, dann hat er einfach System Fonts genommen und das war den nutzern aber nicht genug so dass die gesagt haben ja das müsste man doch irgendwie anders lösen und so bandeln ist halt keine keine option also die einfache lösung wäre gewesen wir bandeln einfach alle von uns oder oder nur robot oder sowas kann man das nicht machen das ist ja klar kann man das machen aber dann ist der download ein gigabyte und nicht mehr 5 mb und Das Projekt wird in sehr vielen CI-Jobs benutzt, das heißt, alle CI-Jobs würden langsamer werden. Und deswegen versuche ich dann eben darüber nachzudenken, wie kann man das clever lösen, sodass die Developer-Experience nach wie vor richtig Sahne ist, aber das Problem gelöst ist. Und dieses Privacy-Plugin war dann eben genau diese Art, also meiner Meinung nach eine sehr gute Art und Weise, dieses Problem zu lösen.

Wolfi Gassler (00:28:52 - 00:29:15)

Jetzt hast du Henry Ford schon erwähnt. Wie schaffst du das, auf das Auto zu kommen und nicht am Pferd zu hängen? Weil die Issues sind ja dann nur pferdebezogen und du willst ja eigentlich das Auto herausbringen. Also machst du dann auch irgendwie konkrete Interviews mit deinen Sponsoren oder Kunden, um da mehr Input zu bekommen und herauszufinden, was die wirklich brauchen? Weil sonst bekommst du ja nur immer die Pferdeanfragen.

Martin Donath (00:29:16 - 00:31:32)

Also ich habe, bevor ich mit dem Sponsorware-Programm angefangen habe, 2020 eine Nutzerumfrage gemacht. Da habe ich wirklich extrem viel gelernt. Da habe ich unter anderem auch gelernt, dass Techwriter eine sehr große Zielgruppe sind. Und das war mir gar nicht bewusst. Ich hatte dieses Berufsfeld gar nicht so auf dem Schirm. Und in dieser Umfrage habe ich auch zu bestimmten Sachen gefragt. Womit seid ihr zufrieden? Was könnte verbessert werden? Und so weiter. Also aus dieser Umfrage kann man sich eigentlich immer noch bedienen. Es ist nämlich wirklich so, dass man denkt, das Projekt ist fertig, aber, oh mein Gott, diese Liste, die ist mittlerweile so lang an Sachen, die man da noch machen kann. Ich gehe jetzt nicht großartig in one-on-, also quasi so in one-to-one-Interviews mit Kunden. Das ist eigentlich relativ selten. Ich versuche auch eigentlich so ziemlich jegliche Kommunikation über GitHub zu machen, weil E-Mail-Kommunikation, ich kriege natürlich auch Anfragen via E-Mail, E-Mail-Kommunikation wirklich one-on-one ist, und das heißt, wenn ich jemandem über E-Mail helfe, dann helfe ich nur demjenigen. Wenn derjenige aber eine GitHub-Discussion erstellt mit einer Frage, dann helfe ich potenziell allen, weil dann ist dieser Verlauf eben nach wie vor auffindbar. Also ich sage immer, hey, mach einen Change-Request. Wir haben einen extrem detaillierten Prozess, wie man einen Change-Request erstellt, was dafür alles erfüllt sein muss und so weiter. Das heißt, dass die wirklich eine hohe Qualität haben und machen Change Request und dann sitzt er da für eine Weile, dann siehst du die Upvotes, dann kommen andere Leute, die sagen, hey, wir brauchen das auch, weil wir haben das und das Problem. Und dann kann man schon relativ gut einschätzen, in welche Richtung das Ganze gehen sollte. Und zum Beispiel aktuell, sind sehr viele Change-Requests zum Thema Suche offen. Und ich hab jetzt erst im 10.000er-Goal war eine neue Suche drin, die schon viele Probleme löst, aber noch nicht alle. Und deswegen werde ich mich jetzt auch wieder an die Suche wenden, also quasi dem Thema zu wenden und versuchen eben, die möglichst viele von diesen offenen Change-Requests, die da sind, und da kommen wir zum Auto, mit zu lösen, also das ist quasi der Input, den ich nehme, und ich schaue, dass alle Probleme, die offen sind, gelöst werden, aber das Ding natürlich noch mehr kann letztlich, weil ich hab natürlich auch noch Ideen, wie man das Ganze noch weiterspinnen kann letztlich. Das ist eigentlich so der Ansatz, den ich fahre. Also ich nehme den Input aus den Issues und Discussions definitiv, aber ich versuche das eigentlich immer so ein bisschen größer zu denken und dann eben auch gut zu schneiden und so weiter, dass man halt Möglichkeiten hat, die man sonst halt nicht hätte, wenn man jetzt quasi nur das Ganze so implementiert, wie es gefragt wurde.

Wolfi Gassler (00:31:33 - 00:31:37)

Hast du irgendwie Angst, dass dir die Features ausgehen irgendwann?

Martin Donath (00:31:38 - 00:32:36)

Nein, gar nicht. Dass das Modell nicht funktioniert, ist eine andere Frage. Aber dass ich keine Ideen mehr habe für neue Features, absolut nein. Ich hab so eine lange Liste an Ideen, die man noch machen kann, die cool sind. Du kriegst ja auch immer wieder neuen Input von anderen Projekten, die zum Beispiel DocuSaurus ist ja so ein quasi direkter Competitor, wenn man das so sehen möchte, von Material, vor allem Kiddox, weil es auch ein Static-Site-Generator ist, der spezifisch für Dokumentation gedacht ist. Und wenn die dann natürlich jetzt ein neues Feature rausbringen, wo dann Nutzer kommen und sagen, hey, das ist cool, DocuSaurus kann das, wie wär's, kann man das auch hier mit Material lösen? Das heißt, du kriegst ja allein darüber Input. Community-Management bekommst du so viele Ideen, die wir auch alle aufgeschrieben haben. Wir haben bisher kein Public-Backlog oder keine Roadmap in dem Sinne. Das steht jetzt auch bald an, dass das Projekt das mal bekommt, damit man mal so ein bisschen reingucken kann in die Sachen, die noch kommen und die geplant sind und so weiter.

Andy Grunwald (00:32:36 - 00:32:50)

Heißt das, du beobachtest deine Konkurrenz auch aktiv und hast sogar so Battle-Cards, warum Material vor allem Card-Ocs jetzt besser ist, DocuSaurus, also wirklich so wie ein Software-as-a-Service, warum du dann eher Google Jam nutzen solltest anstatt Miro?

Martin Donath (00:32:50 - 00:34:06)

Ich bashe meine Competition nicht, weil ich denke, dass es für jeden Use Case einfach so den Best-Fit gibt. Und die Zielgruppe ... Ich glaube, dass DocuSaurus und Material verschiedene Zielgruppen haben. Da DocuSaurus ist wesentlich mehr an Frontend-Entwickler gerichtet, an Unternehmen oder Projekte, die Expertise mit React haben. weil das ja zum Beispiel auch MDX einsetzt, das heißt, du kannst React-Komponenten innerhalb von Markdown benutzen. Das geht mit Material nicht, weil Material ist darauf, und MakeDocs im Allgemeinen, ist darauf ausgerichtet, dass du quasi möglichst ohne Wissen, ohne Wissen von Web-Entwicklungen, trotzdem eine Seite generieren kannst, die super aussieht, die funktioniert, mobile, responsive und so weiter und so fort. Das heißt, die Zielgruppe von Material, und das habe ich auch aus der Umfrage gelernt 2020, ist, Frontend-Entwickler haben wir, glaube ich, sieben Prozent oder so. Und ich würde sagen, dass bei DocuSaurus die Anzahl der Frontend-Entwickler, also die quasi als Hauptprofession Frontend-Entwicklungen angeben, wesentlich höher ist. Und die Zielgruppe von Material ist eben wesentlich mehr Richtung auch System Engineers oder so für interne Dokumentation oder für Teams, die halt jetzt nicht nochmal extra ein Softwareentwicklungsteam abstellen können, um quasi um eine Webseite für Dokumentation zu warten und zu generieren.

Wolfi Gassler (00:34:07 - 00:34:27)

Wenn wir schon bei deinen Usern sind, sind deine User dann auch Sponsoren oder sind es dann eher die Firmen dahinter? Gehen die Leute zu ihren Chefinnen und sagen, okay, ich brauche jetzt da irgendwie dieses Sponsoring, weil ich hätte gern dieses Feature bei uns in der Dokumentation oder sind es dann private Leute, die halt sagen, okay, diese Pizza 15 Dollar ist es mir wert oder sowas?

Martin Donath (00:34:27 - 00:34:49)

Also es ist schwierig zu sagen, weil du über GitHub nur eingeschränkte Informationen bekommst. Du kannst dir bei GitHub einfach einen anonymen Account anlegen, als Firma, als Privatperson, was auch immer, und kannst das Projekt sponsern. Wir haben einige Accounts, die sponsern das Projekt auch teilweise seit Monaten. Wir wissen nicht, zu wem dieser Account gehört. Also es kann auch sein, dass da irgendeine Riesenfirma dahinter ist oder halt eine Privatperson, keine Ahnung.

Wolfi Gassler (00:34:50 - 00:35:01)

Das heißt du schreibst aber auch keine Rechnungen oder sowas in der Richtung. Es läuft komplett 100 Prozent über GitHub und du hast also wenig direkten Kontakt über diese Schiene mit den Leuten.

Martin Donath (00:35:01 - 00:36:01)

Genau und das ist auch wirklich ein Problem, weil du die Leute gar nicht richtig erreichen kannst teilweise. Wenn du entscheidest mich über GitHub Sponsors zu sponsern, dann gibt es dort ein Häkchen, das kannst du setzen, das sagt, ja, ich möchte gerne über Newsletter, also ich möchte quasi gerne die Newsletter abonnieren, also möchte gerne kontaktiert werden. Das heißt, es gibt keine Möglichkeit, Leute, die das nicht angehakt haben, überhaupt zu kontaktieren, was jetzt gerade bei, GitHub hat ja im Februar PayPal abgeschaltet, und das war wirklich ein Riesenproblem, weil wir gerade noch versucht haben, alle Sponsoren zu kontaktieren, aber nur bei uns sind es zwei Drittel der Sponsoren dieses Häkchen aktiviert haben. Das heißt, das ist auf jeden Fall auch ein großes Problem. weil du hast ja teilweise transaktionale Thematiken, so was wie zum Beispiel, hey, das eine Repository wird deprecated, wir ziehen jetzt auf ein anderes Repository um, du hast keine Möglichkeit, die Leute zu erreichen. Deswegen GitHub Sponsors ist echt eine super Idee. Ich finde, GitHub hat sich krass entwickelt, auch seitdem Microsoft es übernommen hat. Aber da ist noch echt jede Menge zu tun, meiner Meinung nach. Und ich bin jetzt seit drei Jahren GitHub Sponsors Nutzer.

Wolfi Gassler (00:36:01 - 00:36:07)

Kannst du vielleicht ganz kurz erklären, was GitHub Sponsors ist und was es dir abnimmt oder auch nicht abnimmt unter Umständen?

Martin Donath (00:36:07 - 00:37:05)

Klar, GitHub Sponsors ist quasi ein Projekt von GitHub, das dir ermöglicht, Entwickler direkt finanziell zu unterstützen. Und als Entwickler kannst du ein Profil, du hast quasi ein separates Profil auf GitHub Sponsors erstellen, dann kannst du kurz über dich schreiben und kannst verschiedene Sponsortiers einrichten. Als Beispiel, also ein Sponsortier ist sozusagen ein Trag, den dir jemand bezahlt und dann kannst du für diese Sponsortiers nochmal dedizierte Beschreibungen anlegen. Zum Beispiel, die Sponsortiers bei mir sind so 15-Dollar-Tier, das ist für Non-Commercial-Individuen. 35, das ist für Organisations, aber auch Non-Commercial. 125, das ist für Commercial, aber für Companies. Und dann gibt's noch zwei weitere Tiers, die dann quasi noch darauf aufbauen. Und mit diesem Profil ermöglichst du eben Leuten mit zwei Klicks Tier auswählen und auf Checkout drücken, wenn du deine Kreditkarte hinterlegt hast, dich finanziell zu unterstützen. Und das Ganze geht eben monthly, recurring, also als Subscription, oder auch one-time.

Wolfi Gassler (00:37:05 - 00:37:16)

Aber du bist natürlich angewiesen auf die Ehrlichkeit von den Usern, weil wenn die einen privaten Account verwenden, privaten Tier, die bekommen Zugriff und wo das dann verwendet wird, siehst du ja in dem Sinne nicht, oder?

Martin Donath (00:37:16 - 00:37:23)

Ganz genau, ja. Also das ist alles so ein bisschen auf den Goodwill der User auch, das muss man auch ganz klar sagen, ausgelegt.

Wolfi Gassler (00:37:24 - 00:37:29)

Also du vergibst keine Lizenz-Keys oder sonstigen Dinge, die bekommen einfach Zugriff dann auf den Code.

Martin Donath (00:37:29 - 00:38:16)

Ich hatte auch eine längere Diskussion auf Hacker-News zu dem Thema. Es wurde irgendein Blog-Post verlinkt und dann habe ich da auch geschrieben, hey, ich bin hier Squidfang und ich mache das auch und habe jetzt aktuell so und so viele Sponsoren und so weiter und ich fahre das und das Modell. Einfach, weil ich mal wissen wollte, wie die Leute das sehen. Und ein Thema war die Frage, Lizenzen, unter welcher Lizenz stellst du den privaten Fork, also das, was bei uns bei Material Insiders heißt. Und ich habe mich entschieden, es unter die gleiche Lizenz zu stellen, nämlich unter die MIT-Lizenz, womit du keine legale Handhabe hast. Derjenige kann alles machen mit dem privaten Code, auch wenn er privat ist. Ihr könnt ihn theoretisch auch veröffentlichen, weil er eben unter MIT steht. Aber wir haben dann noch eine Fair-Use-Policy, die sagt, hey, bitte mach das nicht, weil du kannibalisierst das Projekt. Das heißt, am Ende, wenn das veröffentlicht wird, dann leiden alle darunter, weil dann springen alle Sponsoren ab und wir können nicht mehr weiter an dem Projekt arbeiten.

Wolfi Gassler (00:38:16 - 00:38:21)

Und funktioniert das oder tauchen dann hin und wieder irgendwo Repositories auf, die den Code einfach kopiert haben?

Martin Donath (00:38:21 - 00:38:35)

Das funktioniert sehr gut. Also es gab irgendwie ein, zwei Leaks, die wurden beseitigt. Das war nicht böswillig, sondern das waren aus quasi technischer Unwissenheit wurde das aus Versehen gemacht. Insofern bin ich da echt zufrieden und auch sehr begeistert, dass es funktioniert.

Andy Grunwald (00:38:35 - 00:39:36)

Kommen wir noch mal ganz kurz zu den Unternehmen. Du hast gerade gesagt, du hast relativ wenig Einsicht in die Leute, die dir Geld geben, die dich sponsoren. Jetzt ist es natürlich auch so, dass, ich lehne mich mal aus dem Fenster und sage, GitHub oder einen Account zu haben bei GitHub als Firma, ist jetzt nicht die einfachste Barriere. Gegebenenfalls wäre ein Contact-Sales-Button auf der Webseite vielleicht sogar eine niedrigere Barriere. Das ist die eine Baustelle, also hast du dir sowas mal überlegt. Und die zweite Baustelle ist, ich habe mir deine Sponsorship-Pläne gerade mal angesehen, das geht ja wirklich von 15 Dollar oder sogar einen freien Tag bis maximal 500 Dollar im Monat. Und im Endeffekt ist das ja eine Softwarelizenz. Und wenn ich da jetzt mal dagegen die Preise von Oracle stelle, frage ich mich, lohnt es sich für Firmen mit einer vierstelligen Anzahl an Mitarbeitern, also für Enterprises, für 500 Dollar im Monat irgendwie durch den Einkauf zu gehen? Also, du kennst dieses SARS-Du-bist-zu-billig-Argument. Und meine Frage ist, trifft das hier zu?

Martin Donath (00:39:36 - 00:39:50)

Das trifft voll zu. Wo fang ich an? Also deutsche Firmen sind vor allem sehr anfällig dafür. Also zumindest die Firmen, mit denen ich mit den Einkaufsabteilungen dann teilweise telefonieren musste, weil die dann eben noch eine Rechnung haben wollten und so weiter.

Wolfi Gassler (00:39:50 - 00:39:56)

Läuft das dann direkt oder auch über GitHub Sponsors? Also machst du dann so einen direkten Vertrag mit denen oder eine Rechnung?

Martin Donath (00:39:56 - 00:42:54)

Das läuft dann auch über GitHub Sponsors. Also die meisten Unternehmen, denen reicht der GitHub Receipt einfach. Die Sache ist, ich glaube, dass es definitiv möglich wäre, einen Contact-Sales-Button zu platzieren. Und ich würde lügen, wenn ich nicht darüber schon auch nachgedacht hätte. Aber das ist halt so ein bisschen eine andere Richtung als diese Sponsorware-Geschichte letztlich. Und es ist so, dass diese Sponsorthematik, diese Open-Source-Funding-Thematik im Allgemeinen, wenn man das mal ein bisschen größer denkt, in den letzten Jahren massiv Zulauf bekommen hat, auch wegen verschiedenen Geschichten, unter anderem Lock4J, was ja ein Riesenproblem war. und wo einfach seit Monaten die Möglichkeit bestand, in bestimmte Systeme einzudringen und so weiter. Und das ist einfach eine Open-Source-Library, die ja niemand dann, also diese Stelle hat sich einfach niemand drum gekümmert, weil es ist einfach kein Geld da. Es wird einfach in der Freizeit verwaltet und maintained, aber Unternehmen nutzen das und verlassen sich darauf. Und ich glaube, dass momentan bei den Unternehmen wirklich so ein Shift stattfindet. Die verstehen auch, Hey, wir können nicht die ganze Zeit uns ja nur nehmen, nehmen, nehmen und Projekte nicht unterstützen und nicht dafür sorgen, dass die maintained werden. Und deswegen glaube ich, dass das auf jeden Fall in der Zukunft Sponsorware auf jeden Fall eine Möglichkeit ist, Geld zu verdienen. Eine andere ist, und das ist dann eher so diese Contact-Sales-Geschichte, Das ist ja dann eher OpenCore. Das heißt, man hat eine Software, die man open-sourced und quasi Basisfunktionalität bereitstellt. Es gibt mehrere Datenbanken, die das machen. Da stecken dann VC-gebackte Startups dahinter. Und das ist dann oft so, dass die Datenbank, quasi die Community Edition, die funktioniert dann auf einem Node. Und dann wird man erstmal quasi angefüttert, fängt an, das zu benutzen. Zum Beispiel InfluxDB ist ja so eine Software. Und wenn du dann aber eben so ein Multinode Deployment hast und das Ganze skalieren möchtest, das heißt, wenn dein Startup oder dein Projekt, in dem du das benutzt, dann erwachsen wird, dann musst du halt dafür bezahlen letztlich. Und das ist natürlich eine andere Form der Monetarisierung. Ich glaube, dass diese Form aktuell noch einfacher bei Unternehmen durchzukriegen ist. Aber dann natürlich auch eher ein High-Touch-Sales-Markt ist quasi. Also High-Touch heißt, du hast dann einen Sales Call, du hast dann Onboarding. Das heißt, du kannst die Software nicht einfach downloaden und es läuft. Du bezahlst einmal und fertig. Weil das ist nämlich, das heißt Low-Touch. Und mein Ansatz bei Sponsorware ist, ich möchte das so Low-Touch wie möglich halten. Das heißt, so wenig Maintenance, so wenig Overhead für mich wie möglich, damit ich mich eben auf das Projekt, auf das Produkt fokussieren kann, weil ansonsten müsste ich natürlich die Preise auch wesentlich höher anheben. Das heißt, aktuell war das bisher noch kein Fokus, aber es sind natürlich auch Möglichkeiten, also eine Richtung, in die man gehen kann. Man muss nur gucken, dass sich das nicht kannibalisiert, dass man nicht sagt, naja, jetzt machen wir doch nicht mehr Sponsorware oder wir releasen jetzt Features nur in dem Enterprise-Sektor oder so. Das müsste man dann halt schauen, dass man das halt gut schneidet. Um Enterprises zu targeten, ist das definitiv eine Möglichkeit und wahrscheinlich sogar aktuell noch die bessere Möglichkeit.

Wolfi Gassler (00:42:54 - 00:43:18)

Ich habe mich ja immer gefragt, wo der Unterschied zu einem SaaS mit OpenCore zum Beispiel liegt. Und mir ist auch auf deiner Webseite aufgefallen, dass es, wenn man auf die Startseite geht, dass es nirgends irgendwo so ein Kauf-Button, Sponsor-Button, mehr Informationen bezüglich Sponsoring, Also es gibt null Werbung bezüglich dem Sponsoring auf der Webseite. Ist das bewusst oder Absicht?

Martin Donath (00:43:18 - 00:44:41)

Ja, ich habe das so als Strategie für mich über die über die Jahre entwickelt. Bei Material ist es so, dass ich die gesamte Dokumentation als Funnel sehe. Das heißt, du fängst erst mal an, das Projekt zu benutzen. Und das ist vielleicht jetzt auch so ein bisschen, geht auch ein bisschen in die Richtung Open Core. Das heißt, du kannst erst mal anfangen und kannst erst mal deine Dokumentation damit bauen und so weiter. Und du siehst dann, Bei bestimmten Features, die momentan nur für Sponsoren sind, die sind alle in der gleichen Dokumentation beschrieben, steht da ein Sponsors Only. Und wenn du darauf klickst, kommst du auf die Insiders-Seite. Also auf die Seite, die erklärt, hey, das ist das Insiders-Programm. Wenn du sponsorst, bist du Teil des Programms. Warum machen wir das? Was hat uns das schon geholfen? Die und die Features wurden schon mit Hilfe von Sponsoren entwickelt. Das heißt, du nutzt wahrscheinlich auch schon Insiders-Features. Darum solltest du das tun, wenn du das möchtest. Ich habe die besten Erfahrungen damit gemacht, wenn man das so macht, wirklich die ganze Dokumentation, also nicht so in your face, hey, sponsor das Projekt und unterstützt das, weil das kann halt auch abtörend wirken, beziehungsweise das kann dann auch zu kommerziell aussehen, finde ich. Und wenn man das halt so dann auch nochmal erklärt, warum ist das mit den Sponsorings so, warum machen wir das, und dann quasi so in der Dokumentation so ein bisschen von allen möglichen Seiten als Funnel zu dieser Insider-Seite, die ein Funnel ist zu meinem Sponsor, GitHub-Sponsors-Profil, Und dann kannst du mit drei oder vier Klicks, kannst du quasi Teil des Programms werden. Und dann hast du innerhalb von fünf Minuten, hast du den Access zu den Features.

Wolfi Gassler (00:44:41 - 00:45:01)

Und wenn wir jetzt zurückkommen, also die Firma bezahlt das Geld oder Private bezahlen das Geld über GitHub Sponsors. Dieses Geld wird dann an dich gesendet. Und was passiert dann? Wie kommen die Firmen dann in dieses Insiders hinein? Machst du das dann manuell? Hilft dir da GitHub Sponsors irgendwie? Oder ist das komplett unabhängig von GitHub Sponsors und das ist eigentlich nur eine Payment Plattform?

Martin Donath (00:45:01 - 00:46:22)

Ich war nicht von Anfang an dabei. Ich glaube, GitHub Sponsors hat ein Jahr existiert und dann bin ich eingestiegen. Aber es gibt diese Funktionalität, dass ein Sponsor in ein privates Repository eingeladen wird und das kannst du pro Tier festlegen. Das heißt, du kannst sagen, du musst mir mindestens 15 Dollar zahlen. Dann kriegst du direkt Zugriff auf das private Repository. Da ist aber ein ganz, ganz großer Stern dran, weil das funktioniert nur bei Individuen. Das heißt, bei einem GitHub-Account, der an einen User geknüpft ist. Sollte dich eine Organisation sponsern, und das ist seit Ende 2020 möglich, ist das nicht gegeben. Das steht auch in der Maske, in der du das Repository auswählen kannst, steht da drunter, das gilt nicht für Organizations. Und das ist ein Riesenproblem, weil du hast keine Kontrolle darüber, ob dich ein User oder eine Organization sponsert. Das heißt, da dieses Feature auch erst Anfang 2022 rauskam und wir seit Mai 2020 dieses Programm fahren, ich habe das Ganze erst manuell gemacht. Ich habe mir gesagt, wenn ich auf 100 Sponsoren komme, dann fange ich an, es zu automatisieren. Und das habe ich auch genauso gemacht. Ist ganz schöner manueller Overhead, weil der Workflow war, dich sponsert jemand und du fügst ihn in den privaten Repositorien zu. Du musst aber auch beobachten, wenn derjenige dich nicht mehr sponsert, dass du ihn auch wieder entfernst.

Wolfi Gassler (00:46:22 - 00:46:26)

Funktioniert das auch bei den Individualsponsors so oder fliegen die automatisch raus?

Martin Donath (00:46:26 - 00:48:04)

Wenn du die Funktionalität von GitHub nutzt, dann ist das direkt gegeben. Und ich habe das, wie gesagt, erst manuell gemacht und GitHub hat Webhook-Events. Ich habe am Ende dann mir einen Webhook-Händler geschrieben, der die Events bekommt von GitHub-Sponsors und das dann automatisch macht. für Individuen, nicht für Organisations. Weil das Problem ist, welcher Account soll bei einer Organisation als Collaborator hinzugefügt werden? Du kannst nicht einer gesamten Organisation den Zugriff geben, sondern es müssen explizite Nutzeraccounts sein. Es gibt Organisations, die haben überhaupt keine Public-Nutzeraccounts. Das heißt, der Workflow ist bis heute, dass wenn eine Organisation das Sponsoring abschließt, diese Organisation sich über E-Mail bei uns, also Sponsors at SquidFunk, ich sage die ganze Zeit wir und uns, ich habe mittlerweile Unterstützung, Cati macht Sponsor-Management, super, dass ich das abtreten konnte, weil das auch ein Thema ist, was wirklich aufwendig ist. Jedenfalls schickst du eine E-Mail. und sagst, der und der Account soll hinzugefügt werden und wenn du das 125er Tier auf dem Tier sponserst, was für Organisation das Tier ist, was du auswählen solltest, dann kannst du noch dein Logo mitschicken und sagen, hey, platziert bitte auch das Logo. Wir brauchen natürlich eine kurze Nachricht, dass das in Ordnung ist, dass wir das Logo platzieren dürfen und dann machen wir das. Da ist dann auch wieder das Problem, du musst monitoren, wenn die Organisation kündigt, dass du die Individual Collaborator auch wieder rausschmeißt. Jetzt kann es sein, dass Ansprechpartner wechseln, dass Entwickler das Team verlassen, dass wir haben schon Mails bekommen, in denen steht, ich habe gar keine Ahnung, was das hier ist. Wir bezahlen dafür. Wer hat hier Zugriff oder was ist das? Und deswegen, das ist halt total, total intransparent.

Wolfi Gassler (00:48:04 - 00:48:09)

Wie viele Sponsoren habt ihr denn insgesamt eigentlich?

Martin Donath (00:48:09 - 00:48:37)

Aktuell 485 oder so, glaube ich. Das fluktuiert immer so ein bisschen. Aber wir hatten, bevor GitHub Paypal im Februar abgeschaltet hat, über 500. Und ja, haben insgesamt 1.300 Dollar pro Monat verloren an Subscriptions. Das sind, glaube ich, über 15.000 Dollar pro Jahr. Und von denen sind jetzt aber ungefähr 250 Dollar oder so wieder zurückgekommen. Das ist halt ein bisschen das Problem gerade in Deutschland. Kreditkarte ist jetzt nicht so verbreitet oder ich weiß nicht wie das, wobei in der Rest der EU sieht das besser aus.

Wolfi Gassler (00:48:37 - 00:48:42)

Und wie viele Stunden investiert ihr nur in dieses Management oder ist das schon komplett automatisiert jetzt?

Martin Donath (00:48:42 - 00:50:02)

Nee, also das ist auch ein bisschen das Problem. Ich habe jetzt witzigerweise im November mit einigen anderen Entwicklern, die mehr im Sponsoring machen wollen und sich mit diesem Sponsorware-Thema auseinandersetzen wollen, geredet. Und ich habe jetzt auch für mich gesagt, ich muss einfach diesen Prozess automatisieren. Ich habe vorher die ganze Zeit gesagt, ich baue da kein neues Projekt raus. Ich mache da kein neues Projekt, weil das ist wieder wie bei Material, von wegen, okay, ich baue ein Projekt für ein Projekt. Aber ich habe jetzt für mich festgestellt, ich muss das machen, weil ich jetzt einfach auch schon so viel gesehen habe oder wir schon so viel gesehen haben an verschiedenen Use Cases, wo es Unterorganisationen gibt, die die sponsern und dann ist das gar nicht klar, wie die Parent-Organisation ist und weiß ich nicht was. Und deswegen habe ich jetzt im November angefangen nebenbei an einem neuen Side-Project zu bauen. Das heißt SponsorBot. Man kann sich schon auf die Waitlist setzen unter sponsorbot.io. Und die Idee dahinter ist, diesen ganzen Prozess einmal vernünftig zu automatisieren. Das heißt zum einen natürlich das Handling von diesen ganzen Individual-Collaboratoren, zum anderen aber auch von den Organisations, das Onboarding zu vereinfachen, im Endeffekt eine Art, ja, Self-Service für das ganze Sponsoren-Management zu bauen, sodass Organisations selber managen können, wer Zugriff bekommt und wenn Teams wechseln, wenn wenn wenn mitarbeiter gehen oder so dann eben das ein quasi automatisch oder selbst eben zu managen ohne dass wir also ohne dass eine e-mail geschrieben werden muss sozusagen das.

Andy Grunwald (00:50:02 - 00:51:30)

Ist ja jetzt gerade so schon ein teil unlösbares problem. Du hast jemand eine organisation die schiebt dir geld drüber. Defaultmäßig ist das bei GitHub, wenn du einer Organisation joinst, dass dein Profil nicht public angezeigt wird. Im Endeffekt heißt das ja eigentlich, du musst dich durch die Bürokratie der Organisation wühlen und dann versuchen herauszufinden, wer da jetzt die Kreditkarte eingegeben hat oder ähnliches oder wer Material für MK-Docs intern nutzen möchte, bis du dann mal irgendwie ein GitHub-Account hast. So, und jetzt ist es ja so. Also, wie viele Stunden hast du, du beziehungsweise jetzt Kati, damit verbracht, dich durch diese Hürden zu kämpfen? Weil all das, was du gerade erzählt hast, das haben wir bei Trivago auch mitgemacht. Wir haben auch Open Source gesponsert und allem Drum und Dran. Und natürlich liest man dann später die Success-Story, toll, und da sponsert eine Firma wieder noch ein Open-Source-Projekt. Aber all das, was du gerade beschrieben hast, jemand vom Einkauf, der mit Open Source nix am Hut hat, hat seine Kreditkarte gezückt, hat die da eingegeben. Dann, auf welches Budget buchen wir das denn? Dann wechselt der Entwickler, der die ganze Sache intern gepusht hat, der der interne Sponsor war, dann die Firma. Flux ist schon wieder dein interner Sponsor verloren gegangen, aber Material für MK-Docs wird irgendwo als Dependency irgendwo noch eingebunden. Und irgendwann kommt halt wieder so eine schwierige ökonomische Phase wie jetzt gerade, wo man mal drauf guckt, wo geben wir eigentlich Geld aus? Und so weiter und so fort. Jetzt bin ich mal gespannt, wie du das alles automatisieren möchtest.

Martin Donath (00:51:30 - 00:51:54)

Natürlich weiß ich nicht, ob man jetzt alles komplett automatisiert bekommt, aber uns sowieso erstmal vernünftige Tools hinzustellen, mit denen wir dieses Sponsoring oder dieses Sponsor-Management besser machen können, um auch besser nachzuvollziehen. Alleine solche Sachen wie, wie lange sponsert jemand, wie viel hat mir der Sponsor insgesamt bezahlt, wie oft hat er gekündigt oder wer sind meine wichtigsten Sponsoren und sowas. Diese Statistiken stellt die GitHub alles nicht zur Verfügung.

Wolfi Gassler (00:51:54 - 00:51:57)

Oder einfach nur die E-Mail Adresse würde ja auch schon viel helfen oder?

Martin Donath (00:51:58 - 00:52:03)

Absolut oder einfach nur die E-Mail Adresse für Transactional E-Mails. Das muss gegeben sein meiner Meinung nach.

Andy Grunwald (00:52:03 - 00:52:23)

Ich meine das was du da jetzt gerade machst sind klassische SARS Analysen. Das eine was du gerade beschrieben hast, wie viel Geld hat dir schon ein Kunde, ein Kunde sag ich schon. Du merkst schon wohin ich gehe. einen Sponsor gegeben. Ich meine, so was nennt man Customer Lifetime Value und so weiter und so fort. Also eigentlich brauchst du ja komplett da wirklich ein reales Produktbusiness gerade.

Martin Donath (00:52:23 - 00:55:13)

Genau, und das möchte ich jedem ermöglichen, das auch zu tun, um sein Open-Source-Projekt drumherum. Weil ich glaube, dass in Zukunft ein gangbarer Weg wird. Also wie cool ist das? Du kannst an deinem Projekt arbeiten, du wirst gut bezahlt, wenn du deinen Job gut machst. Ja, es ist wirklich wie ein eigenes Start-up letztlich. Aber es gibt halt in diesem Sponsorware-Raum beziehungsweise allgemein Software auf GitHub gegen Bezahlung bereitzustellen, da sind die Prozesse einfach noch nicht da. Und das ist halt genau die Idee von SponsorBot. Und deine Frage vorher war, wie geht das alles? Also die Grundidee ist, dass du als derjenige, der gesponsert wird, aber auch als der Sponsor, dich quasi einfach über eine GitHub-App authentifizierst und Dann weiß SponsorBot, ah du bist in der und der Organisation, die hat gesponsert oder der User hat gesponsert und so weiter und dann kannst du eben, du bist auf dem Sponsortier und dann kannst du das selbst managen. Also die Idee ist überhaupt erstmal, es muss noch nicht mal, der Automatisierungsgrad muss noch nicht mal extrem hoch sein, aber überhaupt diese Möglichkeit, das für die Organisation selbst zu managen, sodass in dieser Welcome-E-Mail einfach nur steht, Hey, danke, dass du gesponsert hast. Wir machen unser gesamtes Management über SponsorBot. Das ermöglicht uns ABC. Und der bezahlt, also der sponsert, ist nämlich nicht notwendigerweise derjenige, der den Collaborator-Status bekommen soll. Ganz oft der Fall. Auch das ist bei GitHub nicht möglich. Also du kannst nicht sagen, ja, ich sponsor, aber weil ich bin... Also wir kommen aus dem Marketing und wir haben auch ein GitHub-Account. Aber der Developer soll den Zugang bekommen. Und das alles möchten wir, dass das über Sponsorbot eben quasi selbst gemanagt werden kann zum einen. Und das kann man auch weiterdenken. Zum Beispiel Unternehmen, die mit external Contributern arbeiten. Also sagen wir mal Elasticsearch zum Beispiel. Die haben ja ein riesiges Open-Source-Projekt und auch ein Offering, also quasi eine Pro-Version, also halt quasi Enterprise-Support und so weiter. In dieser Open-Source-Version, wenn die jetzt ihre Dokumentation mit Insiders bauen, du musst natürlich als Collaborator Zugriff darauf haben. Das heißt, wenn jetzt ein externer Contributor kommt, dann hat er keinen Zugriff darauf. Bei SponsorBot ist dann mittelfristig die Idee, dass du das an Teams knüpfen kannst. Das heißt, du hast ein Dokumentationsteam, und du kannst dann externe Leute in dieses Team mit reinnehmen und die werden automatisch auch, kriegen die Zugriff auf das Repository und wenn du die wieder rausschmeißt, fliegen die dort auch wieder raus, sodass du quasi eine feste Anzahl an Seats dann quasi hast, wie auch jetzt kommen wir wirklich wieder in diese SaaS-Welt, in diese SaaS-Worlding und dann kannst du zum Beispiel sagen, wenn du mich mit 125$ sponsorst, bekommst du 5 Seats, also du kriegst 5 Zugänge, die kannst du verteilen Und die kannst du eben manuell managen oder dann mittelfristig, das wird jetzt nicht in der ersten Version der Fall sein, auch an Teams knüpfen zum Beispiel. Und das sind so diese Enterprise-Prozesse letztlich, die wir letztlich automatisieren wollen.

Andy Grunwald (00:55:13 - 00:55:19)

Kennst du die originale Message, mit der Stripe angetreten ist? nee. Aber Stripe, die Payment-Plattform, sagt dir was?

Martin Donath (00:55:19 - 00:55:25)

Ja, ich krieg mein Geld von Stripe, weil Stripe, der Payment-Anbieter ist, den GitHub-Sponsors für die Transaktionen benutzt.

Andy Grunwald (00:55:26 - 00:56:23)

Der Originalgedanke von Stripe war eigentlich, der Baukasten für das Gründen von Startups zu sein. Und sie dachten sich, okay, Payment ist ein schwieriges Feld, und dann haben die so ein bisschen Jagdshaving gemacht, also eigentlich genauso wie du, ja, mit dem Material von MKDocs. Und deswegen denkt jeder, Stripe wäre eine Payment-Plattform. Ist es auch, weil damit machen die das meiste Geld. Aber deren Mission ist immer noch, die wollen das Gründen von Startups irgendwie einfach machen. Die haben ja zum Beispiel auch dieses Atlas, womit du einfach dann eine Firma in Amerika und dann in verschiedenen Bundesstaaten gründen kannst. Und die haben noch ganz viel anderes Zeug drumherum, all das, was du brauchst, um ein Startup zu gründen. Und ich fand das gerade so schön, als du das gesagt hast, ich will all das, diesen Pain, den ich jetzt hier gerade hatte, den möchte ich wegschieben und allen Leuten irgendwie auch die Möglichkeit geben, ein Open-Source-Projekt durch Sponsorengelder zu finanzieren. Da kamst du mit Sponsorwort und hab ich gedacht, okay, du bist also irgendwie das Stripe für GitHub-Sponsors.

Martin Donath (00:56:23 - 00:57:09)

Vielen, vielen Dank auf jeden Fall. Das ist ein fantastischer Vergleich. Ich denke, das wird erstmal wesentlich kleiner als Stripe, weil Sponsoring gerade ein aufstrebender Markt ist. Ich glaube aber, dass es in Zukunft wichtiger wird und dass mehr und mehr Unternehmen mehr Geld in Sponsorware stecken werden. Wie gesagt, Sponsorware ist nur eine Möglichkeit, das Fundingproblem zu lösen. Und ich bin ein riesen Fan davon, an meinen eigenen Problemen zu arbeiten und die so zu abstrahieren, dass ich es anderen Leuten auch bereitstelle. Also ich bin auch Freelancer, das heißt, ich habe für viele verschiedene Kunden gearbeitet, aber seine eigenen Probleme zu lösen und das dann nochmal in ein Produkt zu bündeln und das ist einfach was, was hundertmal mehr Spaß macht, als einen Online-Shop aufzusetzen oder sowas. Also für mich zumindest.

Wolfi Gassler (00:57:09 - 00:57:37)

Dieses Problem, was du jetzt gerade auch beschrieben hast, existiert auf jeden Fall, weil wir haben auch mit einem guten Freund, mit Matthias gesprochen, der in dem Feld unterwegs ist und der hat auch sofort gefragt, ja, wie funktioniert denn das mit dem Insider Repository, wie macht er die Anbindung und wie funktioniert das alles? Also dieser Pain ist definitiv da. Meine Frage wäre jetzt natürlich auch, glaubst du, dass GitHub Sponsors vielleicht in dem Bereich mehr machen würde? Weil wenn die natürlich diese Features dazu bauen, dann wäre dein Sponsor-Bot nicht mehr nötig.

Martin Donath (00:57:38 - 00:59:58)

Da bin ich sehr gespannt, weil an GitHub Sponsors an sich passiert in den letzten Jahren sehr, sehr wenig. Ich bin selbst ein bisschen erstaunt, dass die so wenig daran arbeiten. Deswegen klar, es kann immer passieren, dass dann Features obsolet werden von einer eigenen Lösung, die man außerhalb von GitHub baut oder von der Plattform, die man versucht zu verbessern oder zu erweitern. Da habe ich aber gar nicht so die Angst vor, ehrlich gesagt, weil das Ding ist, GitHub Sponsors ist eine Möglichkeit, Sponsorings anzunehmen. Open Collective ist zum Beispiel eine andere Plattform und ich fange an mit GitHub Sponsors, aber der Plan ist, das auszuweiten auf weitere Anbieter, weil ich jetzt gerade Ich hatte vorhin schon zweimal erwähnt, dass GitHub im Februar Paypal abgeschaltet hat. Vielleicht erzähle ich das nochmal ganz kurz für diejenigen, die das nicht mitbekommen haben. Man konnte über GitHub Sponsors via Kreditkarte und via Paypal bezahlen. Und GitHub hat im Januar angekündigt, dass Paypal abgeschaltet wird. Das hatte zur Folge, dass alle Sponsorings, die über Paypal bezahlt werden, automatisch gekündigt werden. Und insgesamt, ich hatte das, ich habe GitHub währenddessen gecrawled und habe, um den Schaden mal so ein bisschen einzuschätzen, und habe hochgerechnet, dass das wahrscheinlich, in einer gewissen Unsicherheit natürlich, aber wahrscheinlich 240.000 Dollar pro Monat an Sponsorings vernichtet hat. Und ich hatte vorhin schon erwähnt, dass es bei Material 1.300 Dollar waren, insgesamt 240.000. Und man hat natürlich dieses Plattform-Risiko bei GitHub-Sponsors, weil du ja, wenn du dein gesamtes Geld über GitHub-Sponsors beziehst und GitHub sagt, wir sperren dein Account, weil du vielleicht aus irgendeinem anderen Grund die Terms of Service quasi violated hast, dann hast du ein Riesenproblem, wenn da dein gesamtes Einkommen dran hängt. Deswegen, was wir jetzt noch angefangen haben, ist auf Kofi ein Profil zu erstellen, weil Kofi keine Fee nimmt. Du bezahlst nur die PayPal-Fee. Jetzt kommen aber über Kofi auch weitere Sponsoren, die dann über PayPal wieder bezahlen können. Das ist außerhalb von GitHub. Also das heißt, man muss mittelfristig auch, oder was heißt man muss, aber das Ziel ist mittelfristig andere Plattformen anzubinden. Und Open Collective und Kofi sind eben zwei Möglichkeiten. wie auch, ja, wie man auch bezahlt werden kann, wo man Profile machen kann und die sollen auch in SponsorBot letztlich integriert werden. Du brauchst am Ende trotzdem ein GitHub-Account, also die Bindung an GitHub zur Bereitstellung des Repositories ist notwendig, aber die Bezahlung kann natürlich auf einem anderen Weg stattfinden letztlich.

Wolfi Gassler (00:59:59 - 01:00:06)

Also wenn man SponsorBot verwendet, dann ist GitHub Sponsors eigentlich nur mehr eine Payment-Plattform. Man braucht dann eigentlich gar keine Features mehr von denen.

Martin Donath (01:00:06 - 01:00:20)

Momentan ist die Source of Truth definitiv getappt, aber das wird dann in Zukunft sehr wahrscheinlich aufgeweicht. Sehr wahrscheinlich, weil ich werde dann auch erstmal lernen, wie andere Nutzer das Ganze einsetzen, was dann noch für andere Use Cases sieht.

Wolfi Gassler (01:00:20 - 01:00:27)

Und jetzt die Gretchenfrage, wird SponsorBot dann Open Source werden oder machst du das kommerziell oder was hast du für ein Businessmodell im Kopf?

Martin Donath (01:00:27 - 01:01:16)

Das kann ich noch nicht 100% beantworten. Also es sieht so aus, dass SponsorBot Betriebskosten auf jeden Fall haben wird, weil SponsorBot im Endeffekt die Webhook-Events, also das läuft am Ende über Webhooks, verarbeitet. Und das heißt, wenn du es so nutzen möchtest, so wie es ist, dann entstehen auf unserer Seite Kosten. Es wird definitiv, das weiß ich jetzt auf jeden Fall, es wird definitiv ein Free-Tier geben. Das heißt, wenn du eine gewisse Anzahl von, also bis zu einer gewissen Anzahl von Sponsoren, wird es auf jeden Fall umsonst sein. Einfach, weil du es ausprobieren kannst und möchtest und so weiter. Und du hast den richtigen Benefit davon am Ende, wenn du mehr Sponsoren hast. Das heißt, es wird ein Free-Tier geben, aber wahrscheinlich wird die Nutzung Geld kosten. Aber es wird fair sein, weil ich möchte quasi Open Source letztlich unterstützen, diese Strategie zu fahren und damit Geld zu verdienen.

Andy Grunwald (01:01:16 - 01:01:20)

Wissen wir eigentlich, warum GitHub Paypal abgeschaltet hat?

Martin Donath (01:01:20 - 01:03:12)

Es gibt dazu kein offizielles Statement. Der Blogartikel, in dem GitHub das announced hat, ist zwei Sätze lang. Also einfach nur, wir schalten PayPal ab. Ab dann und dann gibt's es nicht mehr. Es gibt Mutmaßungen, also auf Twitter wurde gemutmaßt, dass es eventuell daran liegt, dass GitHub die Terms of Service von PayPal violated hat, weil GitHub-Sponsors selbst keine Fees nimmt. Ich weiß nicht, was die für Deals haben intern. Mit Stripe haben die, weil Stripe ja, ich meine, Stripe wickelt, glaube ich, das komplette Transaction-Handling von GitHub ab, also quasi alles, was du bezahlst, also auch dein Pro-Account und so. Das heißt, mit Stripe haben die wahrscheinlich einen relativ guten Deal. oder microsoft subventioniert das aber bei paypal glaube ich dass das daran lag dass sie so diese funktion genutzt haben sende geld an freunde um den gebühren zu entgehen und da jetzt einige leute wie ich sponsorprogramme auf sponsorware programme aufgesetzt haben die Ja einen kommerziellen charakter haben nämlich du du kaufst also du sponsorst mich und du bekommst ja auch eine gegenleistung damit ist es ja eine transaktion kann es sein dass diese art von von von transaktionen dazu führt dass das ist eine eine terms of service violation bei paypal ist ja genau also dass. Das hat für sehr, sehr viel Ärger gesorgt. Es gibt einige sehr wütende User in der GitHub-Community, in den Discussions. Da gibt es mehrere Threads zum Thema, warum schaltet GitHub Paypal ab. Und ich finde, die haben auch echt keinen guten Job da gemacht. Ich war auch wirklich sehr sauer, weil du konntest einfach jeden Tag, sonst sind Sponsoren weggeflogen. Caleb Porcio hat getwittert, er hat 4.000 Dollar pro Monat verloren. Das sind 48.000 Dollar pro Jahr. In einem Monat. das ist ein jahresgehalt also das ist schon echt krass was da einfach durchgeht.

Andy Grunwald (01:03:12 - 01:03:26)

Das klingt brutal das das verstehe ich auch das tut mir auch alles total leid aber eigentlich ist es das was jeder weiß wovon jeder redet und zwar ist es diese plattform abhängigkeit von der du gesprochen hast und jetzt ist sie einmal ich sag mal eingetreten.

Wolfi Gassler (01:03:26 - 01:04:34)

Aber man muss natürlich auch dazu sagen, und darum war ja GitHub Sponsors auch so beliebt oder ist es immer noch, weil GitHub die gesamten Fees übernimmt. Und du kannst heutzutage keine Kreditkarte, keine Transaktionen ohne Fees durchführen und GitHub zahlt einfach alle Transaktionen. Also ich kann mir schwer vorstellen, dass Stripe einfach sagt, wir verzichten auf alle Fees und können sie auch gar nicht, weil die Kreditkarten-Fees sind auf jeden Fall da. Die muss irgendwer zahlen und das übernimmt wahrscheinlich GitHub. Und wir hatten ja früher auch Andi und ich mal so ein paar Überlegungen bezüglich einem Open Source Sponsoring Projekt und wie man Geld verteilt. Und diese Nebenkosten machen einen natürlich kaputt, weil wenn du sonst schaust, was Open Collective und so weiter nimmst, da bist du ja gleich mal bei 5 bis 10 Prozent, was da einfach wegfließen. Und das hat man natürlich bei GitHub Sponsors nicht. Und ich vermute auch, die werden halt intern irgendwelche Probleme gehabt haben und wenn die natürlich plötzlich irgendwo 5% Fees zahlen müssten, weil PayPal ist ja nicht gerade billig mit den richtigen Fees bei einem Pro-Account, bei einem Business-Account. Aber das heißt ja trotzdem nicht, dass man nicht sauber kommunizieren kann. Also das eine schließt das andere ja nicht aus.

Martin Donath (01:04:34 - 01:05:05)

Die Kommunikation war wirklich das Hauptproblem. Es wäre gar kein Problem gewesen, zu sagen, der Sponsor bezahlt die PayPal-Fees. Also, dass du zustimmst, dass, wenn du über PayPal sponserst, dann noch mal 2,5 Prozent plus 30 Cent, je nach Land, wo du herkommst, quasi noch mal anfallen. Das wäre gar kein Problem gewesen, meiner Meinung nach. Aber so haben sie es jetzt gemacht. Lustigerweise führt Stripe jetzt PayPal als Zahlungsmittel ein, hab ich gesehen. Ich weiß gar nicht, ob man am Ende doch wieder PayPal bezahlen kann. Der Schaden ist da.

Andy Grunwald (01:05:05 - 01:06:03)

Bin mir gar nicht sicher, ob GitHub selbst so der große Konkurrent für SponsorBot wäre, so wie Wolfgang das gerade beschrieben hat, weil seit Microsoft GitHub gekauft hat, und wenn du dir das Changelog mal ein bisschen ansiehst, ist die Fokussierung eigentlich auf Enterprise-Kunden. Die machen sehr viel im Audit-Log. Du kannst jetzt auch das Audit-Log nach S3 streamen und so weiter und so fort. Welcher normale kleine Open-Source-Maintainer braucht das? Also du merkst schon, wenn du aufs Change.org mal durchguckst, der Fokus ist wirklich auf Geld verdienen, aufs Profitabel machen. Ja, natürlich auch Microsoft so ein bisschen als Open Source Company dann vielleicht darzustellen. Ich meine, das ist ja deren Strategie seit Ewigkeiten. Also früher war das ja so, ich möchte niemals für Microsoft arbeiten, die machen Windows. Heutzutage, wow, die machen leider richtig coolen Scheiß inzwischen. Und deswegen bin ich mir gar nicht so sicher, ob GitHub wirklich dich so hart aus dem Markt brennen möchte oder wird. Besonders wenn du sagst, oder wenn du jetzt schon die Vision hast, mehrere Plattformen anzubinden.

Martin Donath (01:06:03 - 01:06:56)

Das ist ja immer das Risiko, das man hat, wenn man sich an irgendeine Plattform dranflanscht. Wenn ich jetzt ein Plugin für Google Mail schreibe, was es schöner macht oder was irgendeine Integration bereitstellt, dann kann es sein, dass Google damit irgendwann selber um die Ecke kommt und das macht. Und zum Thema Microsoft, ich bin so überrascht, dass ... Also klar, wir haben alle gesagt, Windows geht gar nicht, Microsoft, schlimmstes Unternehmen ever. Ich schreibe in einer Microsoft-Sprache TypeScript, in einem Microsoft-Editor, Falschcode. Es fehlt nur noch, dass ich auf einem Microsoft-Notebook arbeite. Ich hab noch einen MacBook, aber wahrscheinlich dauert's nicht mehr lange. Es ist echt krass, wie sich dieses Unternehmen gewandelt hat. Und GitHub zu kaufen war, glaub ich, eine krass, krass gute Entscheidung für Microsoft und ich glaube GitHub hat es auch nicht, hat es auch keinen Abbruch getan. Es gibt andere, die sagen, seitdem Microsoft das übernommen hat, wollen sie nicht mehr da sein, aber ich sehe das nicht so, ich sehe das nicht so kritisch.

Wolfi Gassler (01:06:56 - 01:07:29)

Sicherst du dich jetzt eigentlich irgendwie ab gegen dieses Problem, also mit den E-Mail-Adressen zum Beispiel? Ich weiß es vom Vom Beta-Levels zum Beispiel, Levels.io kennt man vielleicht dieser, der da sehr im Build-in-Public-Space unterwegs ist, der sich zum Beispiel eine Newsletter angelegt hat, nur um E-Mails zu sammeln, falls er mal von Twitter oder so gebannt wird, weil er hat halt ein paar hunderttausend Follower auf Twitter, aber wenn er auf Twitter aus irgendeinem Grund kickt, ist er weg und hat den gesamten Kontakt zu seiner Community verloren und hat darum diesen Newsletter angelegt. Hast du auch irgendwie so ein Backup, das du dir jetzt eingerichtet hast?

Martin Donath (01:07:30 - 01:07:44)

Aktuell nicht, aber bei SponsorBot wird es dann so sein, wenn du die GitHub-App installierst, beziehungsweise du musst nicht mal die GitHub-App installieren, du musst sie nur autorisieren. Das heißt, dass die App Zugriff auf deine E-Mail-Adresse bekommt, dass wir dich kontaktieren können. Das wäre damit gewährleistet.

Wolfi Gassler (01:07:44 - 01:07:48)

Bei was für einem Sponsor-Goal bist du eigentlich aktuell dran oder ihr?

Martin Donath (01:07:48 - 01:08:12)

Also aktuell erreicht haben wir das Zehntausender und jetzt sind wir kurz vor dem Zwölftausender. Das zieht sich jetzt leider ein bisschen wegen der PayPal-Geschichte und auch, was wir auch merken, ist so ein bisschen die Rezession. Ich habe auch gelesen auf Twitter, dass es sehr vielen Startups auch so geht, dass der Mai wirklich ein sehr, sehr schwieriger Monat war. Also gerade wächst es langsam, aber es wächst noch. Und ich bin aber der festen Überzeugung, dass es sich auch wieder erholen wird.

Wolfi Gassler (01:08:12 - 01:08:31)

Ja, siehst du ja auch bei großen Firmen an der Börse und so, die public sind, dass das SaaS-Business durchaus zurückgeht aktuell meistens oder halt weniger Wachstum zumindest ist. Jetzt meine Frage, was mich natürlich noch interessieren würde, okay, ihr macht jetzt über 100.000 über diese Sponsorschiene. Was machst du denn mit dem Geld?

Martin Donath (01:08:31 - 01:09:30)

Natürlich selber davon leben erstmal. Das erste, was ich auch gemacht habe, ist, jemanden dafür zu bezahlen, das Sponsor-Management zu machen. Die Cati, die macht das wirklich super gut. Das ist natürlich auch so ein Open-Source-Projekt, ist natürlich auch eine ganz andere Welt. Das heißt, da muss man auch erstmal reinkommen, jemanden einarbeiten und so weiter. Also ich nutze das Geld aktuell, um, ich fange an, das ganze Projekt zu professionalisieren. Da ich mich selbst auch mehr auf die Entwicklung wieder fokussieren möchte und natürlich muss ich auch sehr viel Maintenance machen, das heißt Issues, also Community Management meine ich, Issues beantworten, Feature, also Leuten helfen, die bestimmte Sachen erreichen wollen und so weiter. Einfach User, die die Happiness der User auch gewährleisten. Das erfordert teilweise ein sehr technisches Verständnis, aber ich versuche jetzt die ersten Sachen, wie gesagt, Sponsor-Management, aber auch, wir haben jetzt neulich den Bug-Reporting-Prozess komplett auf links gedreht und nochmal umgestellt und extrem professionalisiert. Das hat auch komplett die Cati gemacht.

Wolfi Gassler (01:09:30 - 01:09:33)

Und der Betrag ist auch brutto, oder? Schätze ich mal.

Martin Donath (01:09:33 - 01:09:34)

Das ist brutto, ja genau, richtig.

Wolfi Gassler (01:09:35 - 01:09:39)

Das heißt, da gehen noch ganz viele Steuern und teilweise auch Umsatzsteuer und solche Dinge auch noch weg, oder?

Martin Donath (01:09:39 - 01:09:42)

Umsatzsteuer, das ist ein richtig schönes Thema, ja. Genau, da gehen noch Steuern weg, ja.

Wolfi Gassler (01:09:43 - 01:09:46)

Das heißt, da schaut nicht mal ein Entwicklergehalt am Ende eigentlich raus.

Martin Donath (01:09:46 - 01:10:23)

Ich war neulich in einem Twitter-Space. Der Space-Host hat vorher den Link zum Space geshared. Dann hat jemand retweetet und meinte, ich weiß nicht, ob ich so einen Pay-Cut hinnehmen würde. Also quasi auf 100.000. Okay, krass, du verdienst wahrscheinlich 250.000 oder 300.000. Ist auch klar in Silicon Valley, aber da sind die Kosten eben auch andere. Es ist ja auch bekannt, dass Unternehmen wie Google und Microsoft eigentlich eher den Standard bezahlen von dort, wo du wohnst. Du hast ja auch wesentlich höhere Ausgaben. Ich würde schon sagen, dass die 100 oder 120k, das ist ein sehr, sehr kompetitives Entwicklergehalt ist.

Wolfi Gassler (01:10:23 - 01:10:30)

Na ja, aber wenn du jetzt dann noch Umsatzsteuer wegrechnest und dann sogar noch eine Person bezahlen musst, ist es dann kein Entwicklergehalt mehr.

Martin Donath (01:10:30 - 01:10:35)

Das stimmt genau. Aber es ist auf jeden Fall so, dass ich aktuell gut davon leben kann.

Andy Grunwald (01:10:35 - 01:11:19)

Ich glaube, man darf Silicon Valley-Gehälter jetzt natürlich nicht mit deutschen Gehältern vergleichen, Begriffe wie Total Compensation und Equity gilt. Wir haben ja gerade ganz kurz die Börse erwähnt. Das ist ja eine Achterbahn, ein Up, ein Down. Und da geht natürlich dann das auch Equity mit. Und in der Regel, wenn man von diesen 300.000, 400.000 Gehältern spricht, dann spricht man natürlich von der Total Compensation, wo das Equity mit drin ist, bla bla bla. Also ich glaube schon, ich bin da schon bei Martin, wenn man jetzt hier mal im Dachbereich ist, gut, Schweiz ist vielleicht noch mal ein bisschen was anderes. Entschuldigung an alle Schweizerinnen und Schweizer. Aber wenn man jetzt mal hier in Deutschland unterwegs ist und vielleicht jetzt nicht gerade in München City wohnt, dann kommt man mit einem sechsstelligen Betrag schon sehr gut über die Runden, denke ich.

Wolfi Gassler (01:11:19 - 01:11:49)

Du kommst gut über die Runden, aber du musst natürlich auch einen Steuerberater zum Beispiel bezahlen und andere Dinge. Ich bin da immer sehr, sehr vorsichtig als Selbstständiger, weil wenn man da so Stundengehälter und so weiter oft liest, dann rechnen sich Leute dann so aus, was das im Jahr bedeutet. Und das entspricht halt selten der Realität, wenn man auch noch Ausgaben hat. Aber was mich auch noch interessieren würde, bezahlst du sonst irgendwie Leute, die Sourcecode contributen oder andere Leute, die irgendwie bei dem Projekt mitarbeiten, noch aktiver? Oder hast du das auch geplant, vielleicht in die Richtung irgendwas zu machen?

Martin Donath (01:11:49 - 01:13:09)

Ich upstreame einiges der Funds, die wir bekommen, zu den Dependencies, die wir haben. Es gibt einige sehr kritische Abhängigkeiten von Material, die ohne die Material, also ohne die das Projekt nicht das wäre oder nicht das leisten könnte, was es tut. Und jeder, der ein Sponsorsprofil hat, nicht alle haben das. Manche können das nicht aufgrund von Verträgen, die sie mit ihren Unternehmen haben. Jeder, der so ein Profil hat, der wird quasi gesponsert, also der eine direkte Abhängigkeit hat. Und unter anderem gibt es aber auch dieses Plugin-System im mkdocs-Universum. Das wird immer größer und alle Plugins, die Material nativ supportet, den Sponsoren upstreamig auch Geld. In dem Maße so, dass ich davon noch leben kann und möchte jetzt aber auch in Zukunft so eine Art Contributor-Programm aufsetzen, weil einige Individuen, die viel in der Community helfen, also die anderen Nutzer, Fragen beantworten oder helfen, Probleme zu lösen, denen würde ich quasi auch gerne Insiders-Access geben, einfach weil sie der Community helfen sozusagen. Das wurde auch mehrfach angefragt. Bisher habe ich das abgelehnt. Aber so jetzt so nach und nach glaube ich, dass das gerade im Zuge der Professionalisierung des Projektes, also der Reduzierung meines persönlichen Overheads sozusagen, würde es glaube ich sehr sehr gut tun und da gehen gerade auf jeden fall überlegungen in.

Andy Grunwald (01:13:09 - 01:13:31)

Diese richtung so ich beende jetzt mal eure steuerdiskussion hier denn ich bin ganz normaler arbeitnehmer aber beenden wir den ganzen podcast doch mal mit etwas praktischem was würdest du mir als tipps an die hand geben wenn ich meine inzwischen 100 repositories wenn ich da ein projekt raus packe und die gleiche reise beginnen möchte.

Martin Donath (01:13:32 - 01:15:46)

Also prinzipiell würde ich erst mal fragen was ist das beliebteste projekt weil es natürlich einfacher ist ein projekt das schon benutzt wird auf dem aufzusetzen als was komplett neues zu entwickeln bei dem du nicht weißt ob du quasi einen markt hast so gesehen. Ich hatte das vorhin auch schon erwähnt, dass sehr viel von dem Knowledge, was ich anwende und worüber wir auch geredet haben, aus dem Startup-Bereich kommt. Und das Product Strategy ist so ein Stichwort, das ich extrem wichtig finde. Das heißt, der Tipp wäre, versuch zu verstehen, ob du schon etwas hast, was gut benutzt wird, bei dem am besten die Leute happy sind. Und worauf du aufbauen kannst. Wenn du jetzt, wie gesagt, wenn du from scratch startest, ist es immer schwierig. Dann musst du einfach, dann hast du ja noch keine Validierung. So und im Startup-Kontext, da geht es ja immer darum, möglichst schnell ein Problem zu validieren. Also möglichst schnell zu verstehen, ist es wirklich ein Problem, was Leute haben. Wenn du ein Projekt hast, was ein Problem löst, super. Dann solltest du vielleicht verstehen, wie setzt sich die Zielgruppe zusammen. Das war für mich wirklich sehr, sehr erhellend zu verstehen, dass ich einfach auch wenig Frontend-Entwickler habe, viel Backend und dann eben Techwriter, viel auch aus dem Research-Bereich und so. Und das hat maßgeblich die Entscheidung, bestimmte Features zu entwickeln oder nicht zu entwickeln, geformt. Das heißt, C-Gruppe verstehen, die Probleme deiner Nutzer zu verstehen, auch zu verstehen für was sind sie eventuell bereit zu bezahlen zu verstehen habe ich enterprise nutzer haben enterprise nutzer andere probleme als nutzer also als private nutzer oder quasi der entwickler der das für sein hobby also dein projekt für sein hobbyprojekt einsetzt und dann spezifisch diese enterprise nutzer zu taget also Ich lerne auch wirklich jeden Tag wieder mehr, versuche besser zu verstehen, wie komme ich an die Enterprises dran? Weil die haben natürlich mehr Geld, um Probleme zu lösen. Und wenn du die Probleme von Unternehmen löst, das heißt, Zeit sparst, Geld sparst, durch was auch immer, dadurch, dass deine Lösung eingesetzt wird und nicht eine andere, dann lässt sich das auf jeden Fall in Geld umsetzen.

Wolfi Gassler (01:15:47 - 01:15:58)

Okay, also einfach mal losstarten mit irgendeinem Goal, die Leute gut verstehen, die Kunden gut verstehen, da was zusammenschnüren und dann einfach mal losstarten, wenn ich dich richtig verstehe.

Martin Donath (01:15:58 - 01:16:07)

Ja, definitiv. Also Kunden verstehen, Probleme verstehen und zu verstehen, bin ich da an etwas dran, habe ich etwas, was ich gut monetarisieren kann.

Andy Grunwald (01:16:07 - 01:16:58)

Vielen lieben Dank für diese lange Session. Ich habe höchsten Respekt vor dir und deiner Arbeit und das, was du mit einem Theme für einen Dokumentationsgenerator angestellt hast. Wow, hätte ich nie gedacht, dass sowas wirklich möglich ist, aber vielleicht ist es einfach so, dass du ein sehr, sehr hartes Problem löst. Das muss man vielleicht einfach so sagen. Du hast auf jeden Fall mir sehr viel Lust gemacht, mal tiefer in meine OMSource-Projekte reinzuschauen und zu schauen, wer benutzt denn eigentlich was. Ich glaube, da gibt es auch so Dependency-Analysen von GitHub, dass man mal gucken kann, okay, vielleicht wird ja mein Projekt irgendwo von Google verwendet. Boah, ich bin schon ganz nervös. Auf jeden Fall wünsche ich dir viel, viel Erfolg für den Launch von Spongebob und ich werde da auch mal vorbeischauen. Und vielen lieben Dank, dass du dir die Zeit genommen hast, hier bei uns und die Welt zu erklären in Bezug auf GitHub und Sponsoring.

Wolfi Gassler (01:16:58 - 01:17:15)

Vielen, vielen Dank. Ja, wir werden natürlich alle deine Accounts und Links unten in den Show Notes verlinken. Und wer natürlich Interesse hat oder noch irgendwie Fragen stellen will bei uns in der Community, immer willkommen. Wir werden dich natürlich auch gerne weiterleiten oder vielleicht schaffen wir es, dich noch zu überreden, kurz in die Community zu kommen.

Martin Donath (01:17:16 - 01:17:54)

Ja, vielen, vielen Dank auch, dass ich hier Gast sein durfte. Ich bin sehr froh, dass ich Möglichkeiten bekomme, meine Learnings zu teilen, weil ich glaube, dass das einfach ein Thema ist, was vielen Leuten auch im Kopf herumschwirrt. Kann ich nicht irgendwie mit meinen Open-Source-Projekten Geld verdienen? Kann ich nicht einfach an was arbeiten, wo ich auch richtig Bock drauf habe? Das wird auch ein Ziel sein von SponsorBot. Ich werde sehr viel in der Dokumentation über Strategien schreiben, wie man anfangen kann, seine Projekte zu monetarisieren, was ist für verschiedene, was man so bei Sponsortiers beachten sollte, bei Funding Goals oder was so Learnings sind. Bin immer happy, wenn ich meine Learnings teilen kann insofern. Vielen, vielen Dank.

Andy Grunwald (01:17:54 - 01:17:55)

Vielen Dank.

Wolfi Gassler (01:17:55 - 01:17:55)

Bis bald.

Martin Donath (01:17:55 - 01:17:55)

Tschüss.