Das Code-Gewächshaus: BASIC thinking-Gespräch mit GitHub-Managerin Kakul Srivastava

Die OpenSource-Kultur hat sich selbst zu Branchen-Riesen wie Microsoft und Apple ihren Weg gebahnt. Stark ausschlaggebend dafür ist GitHub. Die Plattform, die mehr als 15 Millionen Software-Entwicklern und über 38 Millionen Projekten ein digitales Zuhause gibt. Die Plattform, die Entwickler wie Menschen behandelt und nicht wie eine Produktionseinheit. Wir haben Vice President of Product Management von GitHub, Kakul Srivastava, in München zum Gespräch getroffen. Ein Gespräch über das neue Preismodell, warum alle ATOM.io kennen sollten und warum jedes Unternehmen heute ein Software-Unternehmen ist.

Tech-Affin. Introvertiert. Science Fiction-Fan. Vorher bei Adobe Systems, Slack, Yahoo. Eigenes Start-up Tomfoolery verkauft an Yahoo. Heute ist Kakul Srivastava bei GitHub und als Vice President für das Product Management zuständig. Ich treffe sie auf einen Tee im verregneten München. Sie ist gerade aus Amsterdam gekommen und hat starke News im Gepäck.

 Please find the English version here.

München, Mai 2016

Sie waren in Amsterdam und haben auf der GitHub Satelite Conference auf dem Podium gestanden. Sie haben ein Panel moderiert, das „Jedes Unternehmen ist ein Software-Unternehmen“ hieß. Gewähren Sie uns einen kleinen Einblick in die Idee des Panels?

Wir hatten unser erste internationale User-Konferenz in Amsterdam. Auf der GitHub Satelite hatten wir eine Keynote unseres CEOs Chris Wanstrath, gefolgt von zwei Tracks: Discover und Develop. Es war die Idee, dass man in einem Track wirklich entdecken und lernen konnte und im anderen ging es darum, wie man Software-Entwicklung im Kern des Unternehmens verwendet. Da ging es dann mehr um Tipps und Techniken, wie man das tatsächlich umsetzt.

Und das Thema „Jedes Unternehmen ist ein Software-Unternehmen“ kam nicht von GitHub. Es ist in der Welt da draußen und wir sind Teilnehmer und Zuseher zugleich. Aber es ist eine grundlegende Veränderung in dieser Welt. Wir haben gerade immer mehr Unternehmen aus traditionellen Industrien, die feststellen, dass ihr Wettbewerbsvorteil aus der Software kommt. In der Automobil-Industrie haben wir einige sehr große Kunden. Niemand konkurriert dort heute noch um Reifen, Achsen oder Motorentechnologie. Sie konkurrieren im Bereich Software. Kann man die Geschwindigkeit und die Textur des Bodens analysieren, um das Fahrzeug auf eine bestimmte Art zu bremsen? Können wir selbstfahrende Algorithmen schreiben und ein Auto sicher fahren lassen? Wie können wir den Videofeed von der Rückkamera nutzen um den Fahrer zu unterstützen und ihn davor zu schützen, etwas zu überfahren? Wie senden wir dem Fahrer dann ein Geräusch oder einen visuellen Alarm? All das ist Software. Und in den letzten 10 Jahren hat sich die Automobilindustrie auf dem Gebiet der Software gemessen. Um also mit den Elon Musks dieser Welt mithalten zu können, müssen sie Software zur obersten Priorität machen.

Wir haben auch große Einzelhandels-Kunden. Selbst dort wird nicht mehr auf dem Gebiet der Logistik konkurriert, sondern in der Software. Es geht um Inventur-Management, User Experience, Nutzer-Präferenzen und Nutzer-Verhalten, um die Wünsche des Kunden zu befriedigen. Und wieder steht Software an erster Stelle.

Heute können wir praktisch mit Smartphones Software entwickeln.

Und das beobachten wir über alle Industrien hinweg. Es ist ein tiefliegender Trend, der übrigens noch faszinierender wird, wenn man sich vorstellt, dass Software-Entwicklung in Zukunft noch viel zugänglicher sein wird. Wenn man an den Beginn der Software denkt, dann musste man nahe an einem Großrechner wohnen, um dort Lochkarten einstanzen zu können. Und heute können wir praktisch mit Smartphones Software entwickeln.

Wir haben jetzt Electron 1.0 in Amsterdam vorgestellt. Es erlaubt unseren NutzerInnen, sehr anspruchsvolle Software zu schreiben mit Basis-Technologien wie HTML, CSS und JavaScript. Das macht Software nochmal einen großen Schritt zugänglicher und kann so auch in allen anderen Berufen genutzt werden. Ich könnte Mikrobiologin sein und Code dazu nutzen, um meinen Job zu erledigen. Oder ich könnte Architektin sein und könnte mit Code meine Pläne erstellen. Oder ich könnte Künstlerin sein, um meine Werke zu erschaffen.

Software-Entwicklung sollte keine Spezial-Disziplin mehr sein.

Meine Nichte ist 11 Jahre alt und besucht eine Schule mit künstlerischem Schwerpunkt in San Francisco. Sie möchte zum Film und dort Figuren animieren. Und natürlich lernt sie Code, um das zu tun. Nie im Leben würde sie sich als Developer bezeichnen. Sie wollte es auch nie. Es wäre auch viel zu uncool und zu geeky für sie. Aber sie schreibt Code, um ihre Kunst in Zukunft zu machen. Software-Entwicklung sollte keine Spezial-Disziplin mehr sein, die nur Menschen mit Spezial-Fähigkeiten beherrschen. Wir alle sollten diese Fähigkeiten nutzen können, um die Welt zu verändern.

Auf dem Event sprach SAP über Social Coding. Facebook war da, um über Sicherheit zu sprechen und Spotify gab Einblicke in kontinuierliche Datenauslieferung und Feedback-Loops. Also ein etwas unerwarteter Mix für diese Unternehmen. Heute sehen wir, dass große Unternehmen mit GitHub arbeiten und beeindruckende Projekte hervorbringen. Ist das Ihr neuer Weg, um eine stabilere Einnahmequelle zu erschließen?

Es ist auf jeden Fall ein großer Teil unseres Business, ganz sicher. Unsere Einnahmen sind auf drei verschiedene Sparten aufgeteilt: Eine ist unsere User-Base aus individuellen Entwicklern. Dort können sich einzelne Developer einen persönlichen Account anlegen. Möchten Sie nichtöffentlich mit anderen Developern zusammen arbeiten, bezahlen sie uns dafür. Alle öffentlichen OpenSource-Projekte sind immer kostenfrei. Die zweite Gruppe, ist unser Organisations-Produkt. Es ist für kleine Unternehmen und Teams ausgelegt. Und das dritte Produkt haben wir GitHub Enterprise genannt. Dann kann man die gesamte Power von GitHub auf seinen eigenen Servern, innerhalb der eigenen Firewall laufen lassen. Das gibt die Sicherheit und die Kontrolle, die Unternehmen brauchen zusammen mit all die Offenheit und Zusammenarbeitsmöglichkeiten, die die Open Source Welt mit bringt.

Lassen Sie uns den SAP Fall kurz ansehen. Es ist ja eine deutsche Firma und der größte Verkäufer von Business Software weltweit. Dort scheint man sehr glücklich mit der Nutzung von GitHub zu sein und hat herausgestellt, wie sehr sie die „kolaborative Natur“ mögen. Was war die geheime Zutat um GitHub in den letzten Monaten so attraktiv zu machen?

Die Geheimzutat ist, dass man Software-Entwickler wie Menschen behandeln muss. Manche Leute denken ja, wir sollten sogar solche T-Shirts machen: „Entwickler sind auch Menschen.“

Wir sprechen über Software-Entwicklung. Es ist diese ganze Industrie daraus geworden mit Software Entwicklung, Lebenszyklen, wie man Prozesse managt. Da hängt ein ROI dran. Und daher behandelt man Software Entwickler oft wie eine Produktionseinheit in der Industrie. Man muss nur genug von denen zusammenstecken, damit es läuft und jeder produziert x. Wer aber an die Industrielle Revolution denkt, der weiß, das Softwareentwicklung eine fundamental kreative Arbeit ist. Und man kann kreative Menschen nicht behandeln wie eine Produktionseinheit. GitHub erkennt das an und unsere Software erkennt das an.

Entwickler sind auch Menschen.

Unser Motto in den frühesten Tagen war „social Coding“. Wir hatten einfach bemerkt, dass es für Entwickler, die es gewohnt sind mit Facebook, Twitter und Instagram umzugehen, eine soziale Art und Weise miteinander zu kommunizieren wichtig ist. Und wie bringt man jetzt dieses „Social Element“ in die Welt des Coding? Wenn man heute einGitHub Profil ansieht, dann fühlt es sich an wie ein Facebook-Profil. Man hat Kommentare, man hat Menschen, die Spaß machen. Man findest Emojis und animated GIFs. Man spricht dort über Code, aber man ist immer noch ein Mensch, der interagiert mit anderen Menschen.
Und Unternehmen wie SAP realisieren, dass Entwickler, die einfacher zusammen arbeiten können, auch Entwickler sind, die sie selbst sind. Sie sind glücklicher. Und wenn sie glücklicher sind, dann kommen sie auch gerne zur Arbeit und sind produktiv. Und das ist die geheime Zutat: Freude.

Wir haben große Veränderungen im Preismodell bei GitHub gesehen: Die Zahl der Repositories ist jetzt frei. Die Accounts sind gesplittet zwischen persönlichen Accounts und Unternehmensaccounts. Gibt es unterschiedliche Funktionalitäten, wenn man Software entwickelt? Und: Warum kamen die Änderungen?

Das Modell für Personen ist wirklich für einzelne Entwickler entworfen und man kann dann einige Leute einladen, um gemeinsam zu arbeiten. Aber ist es rund um eine Person gestrickt, die Repositories, also Einzelprojekte managt. Repositories ist einfach nur der Ausdruck für den Ort, an dem man den Code speichert.

Das Organisations-Produkt ist da schon viel teamorientierter. Es ist für ein Team designt, die gemeinsam arbeiten möchten. Man kann also Rechte ganz anders managen, es gib @mentions innerhalb des Teams und all diese Fähigkeiten machen es ein starkes Team-Tool in der Zusammenarbeit. Und das Unternehmens-Produkt ist sehr ähnlich wie das Organisations-Produkt, das .com Aber man kann damit GitHub eben in der eigenen Umgebung installieren. Das ist es auch schon mit dem Unterschied der Funktionalitäten. Es passt eben auf unterschiedliche Kundenschichten, die es unterschiedlich einsetzen.

Der Grund für unser Preisänderungen kommt von unserer Philosophie. Als wir gestartet sind, war immer klar, dass Open Source auch immer kostenfrei sein sollte. Öffentliche Zusammenarbeit an Software und auch das Teilen von Software sollte gratis sein. Aber wenn man privat an einem Projekt zusammenarbeitet, bezahlt man uns dafür. Repos in denen man Inhalte öffentlich zugänglich macht, sind kostenfrei. Repos, bei dem die Inhalte privat bleiben, sind kostenpflichtig. Also kaufte man ein Repo. Das hat wirklich lang für uns funktioniert. Aber wir haben von unseren Kunden und unserer Community erfahren, dass diese Vorgehensweise die Menschen dazu zwingt, kreative Entscheidungen zu treffen über die Art und Weise, wie sie Ihre Projekte organisieren. Und die Kreativität von Entwicklern zu begrenzen ist das Letzte was wir wollen könnten.

Okay, ich gebe Dir 10 Repos für nächstes Jahr.

Ich habe da eine hypothetische Konversation im Kopf, wo der Finanzplaner zum Entwickler kommt und fragt: Wie viele Repos brauchst Du nächstes Jahr?“ Und der Entwickler sagt, „Ich weiß es nicht. Es kommt auf die Projekte an.“ Und der Finanztyp sagt „Nein, ich muss nur budgetieren, wie viele Du brauchen wirst nächstes Jahr.“ Und diese Konversation ist so lächerlich. Es ist so als würde man sagen „Wie viele Dokumente wirst Du kommendes Jahr schreiben?“ Es hängt schlicht von dem ab, was ich tue. Und der Finanzplaner sagt dann „Okay, ich gebe Dir 10 für das kommende Jahr“. Der Entwickler ist damit aber gefangen.

Unternehmen sind bereit per Nutzer zu bezahlen. Wenn ich 10 Software-Developer habe, dann brauche ich 10 GitHub Accounts. Wenn ich 20 habe, dann nehme ich 20. So kaufen wir Computer und Software und daher haben wir uns verändert.

GitHub hält eine sehr enge Verbindung mit der Community. Ihr seid eines der ersten Unternehmen, dass sich offen bei seiner Community entschuldigt hat, und sich an deren Rat hielt. Ich nehme also an, dass die Community die letzten Änderungen mochte. Gibt es da schon Feedbacks und was sind die favorisierten Rückkanäle zu Eurer Community? Immer noch offene Briefe?

So hart es für uns war, diesen offenen Brief zu bekommen, so sehr halte ich es auch für einen unglaubliche Ehre. Weil es zeigt, dass es den Menschen wichtig ist. Es zeigt, dass man hohe Erwartungen an uns hat und das wir uns diesen Respekt weiter verdienen müssen.

Wir haben einen Menge unterschiedlicher Rückkanäle. Zum Einen sehen wir uns unsere Metriken sehr genau an. Wir analysieren, wie unsere Software genutzt wird. Wo treffen Menschen auf die immer gleichen Probleme? Wo sind die schwierigen Dinge? Wir forschen viel und fragen, laden dazu ein neue Features auszuprobieren. Wir machen sehr viele Nutzer-Umfragen um herauszufinden, wer unsere Community ist, was sie brauchen und wie wir Support leisten können. Wir tracken viele Daten rund um diese Aktivitäten. Wir achten auf Ausreißer in unseren Support-Requests. Woher kommen die Fragen? War dieser Bug schon da, als es eingeführt wurde? Oder haben wir eine neue Nutzergruppe, die jetzt erst auf das Problem stößt? Wir versuche hier einfach am Ball zu bleiben.

So hart es war für uns, diesen offenen Brief zu bekommen, so sehr halte ich es auch für eine unglaubliche Ehre.

Aber auch mit all diesen Mitteln muss man sagen, wir haben eine sehr breite Nutzerbasis. Und manchmal fallen wir zurück. Und dann bekommen wir einen offenen Brief der uns aufweckt. Ich muss sagen: Es war eine großartige Erfahrung.

GitHub hat eine riesige Community in Deutschland. Ich habe gehört, es sei die aktivste Community in Europa mit einer faszinierenden Traffic-Wachstum von über +21% im letzen Quartal. Das macht es aktiver als Nord- und Südamerika zusammen. Was ist Ihre Erklärung für diese Zahlen?

Es gibt zwei Dinge, die sehr spannend sind in Deutschland. Zum einen ist Open Source hier eine große Sache. Und zum zweiten, es ist einfach sehr weit fortgeschrittenes Technologiezentrum. Ich meine, SAP, der weltgrößte Business-Software-Hersteller ist hier. Die Automobilindustrie transformiert sich in eine komplett neue Industrie. Und wir sehen einige sehr interessante Technologien und Technologien hier stark wachsen in Deutschland.

Es gibt Märkte, in den wir schneller wachsen. China und Indien etwa. Aber wenn wir auf das Nutzer-Engagement schauen, dann ist Deutschland sehr nah an der Spitze. Und das ist wirklich interessant.

Lassen Sie uns über Software-Lizenzen sprechen. Patente wirken irgendwie altmodisch inzwischen. Die offneren Ansätze werde im Moment viel populärer. Wie sehen Sie die Zukunft von Open Source?

Open Source kommt ja historisch aus einer Lizenz-Welt. Es gibt Lizenzen, die Open Source sind und die den Menschen erlauben, den Code wiederzuverwenden in der einen oder anderen Form und ich denke, das ist nach wie vor sehr wichtig. Was sich aber verändert, ist die Halbwertszeit von Code. Code verfällt sehr schnell. Und er wird sehr schnell obsolet.

Man könnte sagen, dieser Code ist perfekt. Ich patentiere ihn, schütze ihn und mache Stacheldraht rundherum. Aber es ist nich wichtig, denn in 6 Monaten ist er komplett irrelevant.

Viel spannender ist es, wie schnell man Code entwickeln kann. Also sieht man Unternehmen wie Microsoft die .NET opensourcen. Ein Projekt in das sie schon Hunderte Millionen an Entwicklungskosten investiert haben. Und jetzt ist es plötzlich Open Source. Jeder kann es nutzen. Jeder kann darauf aufbauen.

Was wir wirklich sehen ist, dass Code nicht wichtig ist. Es ist wichtig, wie schnell der Code wachsen und sich entwickeln kann.

Oder man sieht Google mit TensorFlow Machine Learning oder Apple mit Swift und alle machen es auf GitHub. Was wir wirklich sehen ist, dass Code nicht wichtig ist. Es ist wichtig, wie schnell der Code wachsen  und sich entwickeln kann. Und der Fakt, dass wir schon 2.000 Pull Requests hatten, das heißt über 2.000 Veränderungen auf Apples Swift Programmiersprache, seit sie es geopensourct haben, ist wirklich phänomenal. Es gibt jede Menge Software-Developer bei Apple. Aber wir haben Millionen Software Developer. Und es geht nicht mehr darum, den Code zu beschützen, sondern ihn wachsen und leben zu lassen. Das ist es ja, was Open Source tut.

Also ist Open Source eine Art Gewächshaus?

Ja, das ist eine gute Analogie. Es ist genau richtig.

GitHub ist der Ort, um über das Thema Open Source Code Management zu sprechen. Jetzt offeriert ihr auch den kostenlosen IDE (Atom) für Software-Entwicklung. Wie sieht sich GitHub selbst im Software-Entwicklungsprozess? Gibt es noch Tools, die fehlen oder die in Zukunft geplant sind?

Ich bin froh, dass Sie ATOM ansprechen. Es ist etwas, über das die Menschen noch viel zu wenig wissen, auch weil wir unser Marketing noch nicht darauf fokussiert haben. Es steht ja nicht unter der GitHub-Marke. Aber ATOM ist eine sehr strategische Initiative für uns. Wir sprechen ja davon, dass es ein „hackbarer text editor“ ist. Und der Grund ist, dass man an diesen Text Editor Packages hinzufügen kann, um ihn anzupassen. Das kann vom angepassten Hintergrund bis zu speziellen Funktionen gehen.

Wir haben schon Unternehmens gesehen, die ATOM nehmen und anpassen auf Ihre Entwicklungsumgebung. Wenn also ein neuer Developer dazu kommt und mit ATOM startet, sind schon alle angepassten Workflows und speziellen Tools da, ab Tag Eins. Man muss keine Zeit mehr mit der Integration von irgendwelchen Sachen zubringen oder eine Entwicklungsumgebung langwierig aufsetzen. Es ist alles schon da. Im Laufe der Zeit können eine Menge Dinge passieren. Man kann einzelne Blöcke des Codes in anderen Bereichen verwenden. Theoretisch kann man seine Haupt-Entwicklungsumgebung betreiben in diesem Texteditor. Das ist wirklich interessant für uns und wir denken, dass GitHub dann eine Komponente in dieser Umgebung sein kann, im Texteditor. Aber es könnten auch eine Million anderer Sachen sein. Man kann es natürlich auch mit einem Konkurrenzprodukt zu GitHub nutzen. Wir glauben, dass das eine wirklich interessantes Investment ist.

Genauso wie Electron. Dieses Investment fängt gerade an, die Welt der Software-Entwicklung zu verändern. Es ist heute stark verändert im Vergleich zu dem, wie es noch vor fünf Jahren war und wir denken, das wird in weiteren fünf Jahren nochmal so sein wird. Und wenn wir in fünf Jahren nicht daran arbeiten uns obsolet zu machen – Es ist besser, sich selbst obsolet zu machen, als das andren zu überlassen. Ich denke, das ist auch, warum die ATOM Strategie Sinn ergibt für uns.

Ich weiß nicht ob ich über den Teil, der Kommen wird, schon sprechen kann. Wir denken eine Menge darüber nach. Wir denken darüber nach, wie Software Entwicklung in fünf Jahren sein wird und wir verwenden viel Zeit darauf unsere Developer zu fragen: Was sind Eure größten Probleme? Und wenn wir über die Zukunft nachdenken, dann machen wir es uns nicht leicht und sagen „Das wird es geben“, sondern wir denken darüber nach, was es nicht mehr geben wird. Was nicht mehr existieren wird, weil es irrelevant wurde. Wir verwenden wirklich viel Zeit darauf, über das nachzudenken. Wir denken darüber nach, was zum Workflow dazukommen wird und welche Komplexität wir wegnehmen können.

GitHub hat den Start von ZenHub 2014 mitbekommen. Seid Ihr glücklich, wie sich dieses Projekt entwickelt hat? Wisst Ihr, ob viele GitHub-Nutzer ihren Account damit aufwerten oder ob sie es als unabhängiges Tool nutzen?

ZenHub gehört ja nicht zu GitHub. Es ist eine komplett eigenständige Marke. Sie nutzen, wie viele Unternehmen, unsere API um Funktionalitäten zu GitHub hinzuzufügen und das sehen wir sehr gerne. Die ZenHub-Leute sind auch mal bei uns im Office und wir verbringen Zeit miteinander. Für uns ist es sehr wichtig, dass wir ein reichhaltiges Ökosystem mit Developer-Tools zu haben. Aktuelle haben wir über 14.000 Developer-Tools die GitHub nutzen, um sich anzumelden. Software Entwicklungsfirmen integrieren GitHub, bevor sie andre Player am Markt ansprechen, weil bei uns einfach die Userbase so groß ist. Und nochmal: Das ist wirklich ein Privileg, für das wir sehr dankbar sind. Und ich denke, wir verdienen den Platz auch damit, weil wir unserer Community dienen.

Der IT-Sektor hat ja immer noch große Diversity-Themen. Wann immer ich in den letzten Jahren eine Tech-Konferenz betreten habe, habe ich immer überproportional viele weiße Jungs gesehen. Obwohl es besser wird, würde ich gerne wissen, wie GitHub damit umgeht es zu verändern.

Es ist ein sehr reales Problem und es ist ein schweres Problem. Ich habe viel Zeit damit verbracht, darüber nachzudenken. Und als Technologie-Unternehmen können wir auch nur in einem gewissen Rahmen etwas tun. Es hat einfach so viel mit unserer kulturellen Umgebung, wie wir aufwachsen und was wir in den Medien sehen zu tun. Aber es gibt einiges, was wir tun können:

Wir können dabei helfen, eine Umwelt zu schaffen, in der man an der Qualität seines Codes gemessen wird und nicht an Geschlecht, Hautfarbe, wo man zur Schule ging oder all diesen Dingen. GitHub macht das möglich.

Wir können dabei helfen, eine Umwelt zu schaffen, in der man an der Qualität seines Codes gemessen wird und nicht an Geschlecht, Hautfarbe, wo man zur Schule ging oder all diesen Dingen.

Wen man ein Developer-Profil auf LinkedIn ansieht, dann sieht man ihre verlinkten Accounts, Ihre Lebensläufe, Ihren Blog und auch ihre GitHub Accounts. Denn auf GitHub kann man den Code sehen und feststellen, ist das ein guter Coder oder nicht. Egal, ob da ein Dr. vom MIT oder von Standford steht. Und es gibt viele, viele sehr gute Developer aus aller Welt, die niemals auch nur einer Universität nahe gekommen sind. Und auch sie sollten über die Qualität ihres Codes beurteilt werden.

Die zweite Sache, die wir tun können, ist wir können Flexibilität geben. Für Frauen wie Männer, die sagen, ich sollte von überall aus arbeiten können. Ich sollte jederzeit arbeiten können, wenn ich möchte. Und das sollte okay sein. 70% der GitHub Angestellten arbeiten außerhalb des HeadOffice. Es sind Frauen wie Männer, die ihre Familie an die erste Stelle rücken und von zuhause aus arbeite. Weil sie ihr Kind an der Tür begrüßen können und dann wieder ein Stück Code schreiben können. Dann machen sie eine Pause für das Abendessen und arbeiten noch von 10 bis 2h nachts. Was immer sie tun möchten, sie müssen die Flexibilität haben, zu wählen. Und ich denke, es is sehr wichtig zu sagen, dass es nicht nur für Frauen wichtig ist, sondern auch für Männer. Denn auch Männer können dann zuhause bleiben und Frauen können dann zurück in Ihren Job und das ist wirklich wichtig.

Und dann ist da, dass wir Menschen lernen, Code zu schreiben und den Code zugänglicher machen. Je höher die Barriere ist, je mehr Fachwissen braucht man um zu coden, desto schwieriger wird es, in die Tech-Welt einzusteigen. Und ich denke durch die große Bibliothek an Code bei GitHub, können die Menschen einfacher anfangen zu Code zu schreiben. Wenn man jetzt JavaScript lernt, kann man auf GitHub gehen und tausende JavaCode Stücke ansehen.

Bevor ich bei GitHub gearbeitet habe, habe ich in einem Coding-Brotcamp für Frauen gearbeitet. Die erste Sache, die wir gemeinsam gemacht haben, ist einen GitHub Account aufsetzen und ein Profil zu bekommen.  Einfach mal loslegen und der Welt zeigen, was man kann. Und das war ein wichtiger Teil der Erfahrung für die Frauen.

Das sind natürlich nicht die einzigen Antworten und es sind auch unvollständige Antworten, aber ich denke, es gibt schon drei Möglichkeiten, wie GitHub helfen kann.

Danke für das Gespräch.