 Cool, ok. Ja, kommen wir noch rein. Ja, guten Abend. Schön, dass ihr nicht zum Armnissen gegangen sind und jetzt noch einen Vortrag wird, das finde ich toll. Ich werde jetzt ein bisschen über Open Source sprechen und generell über meine tägliche Arbeit seit wir bei uns in der Firma eigentlich das Hauptprojekt geopened haben und was das jetzt so über die Jahre ausgelöst hat. Ich habe da ein Slide, wo ich mich kurz vorstelle. Ich bin System Engineer bei MAZIO, das ist die Firma, wo ich mein Geld verdiene. Wir machen containerbasiertes Hosting. Ich lebe in Zürich. Im Internet findet ihr mich als das Recht. Und ich bin mit sehr vielen Nebenprojekten unterwegs. Ich bin Teil der digitalen Gesellschaft in der Schweiz. Wir haben ein Winterkongress, der meistens im Februar in Zürich stattfindet, wo wir auch so netzpolitisch und digitale Themen zeigen. Ich bin im Vorstand vom Community Rack, wo wir unterdessen zwei ganze Racks für unsere Mitglieder in Zürich betreiben, wo man seine Serverchen hinbringen kann und wir werden die dann ans Netz anhängen. Ich bin auch noch im Team von TEDxBern und generell wenn jemand zu mir sagt, komm mit dem Worten, hey, ich sag mal, kennst du nicht, kannst du nicht? Dann kannst du schnell mal in so einer Situation enden, wo ein paar Freunde von mir gesagt haben, hey, wir würden da mal gerne ein Opener-Sinema machen. Hast du eine Idee, wie man das machen könnte? Ja, stellst du ein Container hin und packst ein Projektort rein und dann kurze Zeit später haben wir dann wirklich ein Opener-Sinema gemacht. Es war doch relativ lustig, wenn man somit 64A Strom rumspielen darf, war was Großes. Aber generell über was reden wir heute? Generell ist es Open Source, wir reden ein bisschen über die technische Sache, die Container, wir reden über die Herausforderungen, die Vorteile, ein paar Fehler, die wir gemacht haben, gelerntes und wieso ich finde, dass jeder ein bisschen Open Source machen sollte. Machen wir kurz mal eine kleine Abstimmung. Wer nutzt Open Source Software täglich? Okay, für die Hände, die noch nicht oben sind, muss der Tropal, nee, WordPress, ja, Composer, ein Riesenlister. Also mal Hände hoch, wer irgendwie mit in was von dem zu tun hat. Okay, geil. Sind wir uns mal einig, Open Source ist überall. Auch am Easter-Hack. Wenn ich schon nur schaue, das Bock das hier ist, das Engelsystem, das Phone Operations Team, die Pre-Talks, also der ganze Schedule und das C3NAF, das ist alles Open Source, das ist toll. Also ich habe am letzten Kongress, habe ich so gedacht, hm, wie machen die bei dem ganzen C3NAF, dass man da wirklich in-house sehen kann, wo das ist. Und dann habe ich mir ein bisschen im Kot eingefunden und gesagt, oh man, das ist noch cool. Und das ist das Tolle an Open Source und man hat wirklich einfach sieht, was genau läuft. Kurz zur Firma, wo ich arbeite und damit den bisschen Hintergrund habe, wieso ich über Open Source spreche. Wir betreiben eine Open Source Hosting-Plattform, die heißt Lagoon. Zudem kommen wir später noch. Momentan hat unsere Team etwa elf Angestellte und wir machen seit mehr oder weniger acht Jahren Web-Hosting. Für Webseiten alle Grüße, also es können tante immerlagen sein, es können aber auch richtig große Webseiten sein, wie zum Beispiel in der Schweiz hatten wir die Eröffnung von, von Gotthard-Basis-Tunnel und da gibt es so schön Traffic-Spike, wenn dann die ganze Welt und vor allem in die große Zeitung plötzlich die Zeit, deine Seite verlinken gibt es so einen schönen Spike, das ist was wir so machen. Unser ganzes Team ist Remote, also ich bin der einzige Momentan in Europa und das Team ist über momentan fünf Zeit-Zonen verteilt. Das macht es ganz lustig, wenn man ein Meeting mit allen machen will, dann bleibt einer lange wach und einer steht früh auf. Und das Lustige an unserem Produkt oder ein Lagoon ist, dass wir das halt in verschiedenen Ländern anbieten können. Also momentan, die Briten mit Brexit, die sagen, nee, nee, nee, wir möchten unsere Seite bitte bei uns hier auf der Insel und wir kommen heim und sagen, ja, es tut gut, machen wir für euch. Und das Ganze kann man in der Klau betreiben oder auch on-premise, weil wir Kunden haben, die halt sagen, ja, die Daten dürfen aus irgendeinem Runden nicht aus unserem Rechenzentrum raus. Da können wir das auch in den Kunden-Rechenzentrum betreiben. Kurz ein Geständnis vorne weg. Früher war eine Großzahl meiner Arbeit oder was wir in der Firma gemacht haben, nicht open source. Es war auch ein Weg dahin. Also wir haben nicht in der Firma gegründet gesagt, aber jetzt machen wir alles open source. Es war wirklich nicht ein Denkprozess, wo wir halt hinkommen mussten und ein bisschen wie es dazu kam. So, ganz am Anfang waren wir eigentlich ein Teil von der Webangentur. Ich war größtenteils der Einzige, der das Ganze betrieben hat. Wir haben einen Hosting und das war okay. Das war nicht das superfansigste Ding, aber es hat seinen Job getan. Es war alles handgestrickt. Und wir hatten so mit der Zeit, weil wir halt immer das Neuste wollten, und dann wirst du eine neue PRP-Version und eine Spezialkonfigur. Und da haben wir so gemerkt, dass wir mit allen Systemen, die es halt gibt, sind wir nicht so happy. Und wir hatten auch andere Agenturen, die immer gefragt haben, hey, ihr habt immer das Neuste Zeug. Wie macht ihr denn das? Und dann haben wir so gedacht, okay, wir könnten uns mal überlegen, ob wir das irgendwann mal öffnen. Das ist halt alles sehen, wie wir das machen. Und was wir auch früh gemacht haben, ist eigentlich bei uns in den Entwicklern angefangen. Es hat die lokale Entwicklungsumgebung. Da zeigen wir euch, da bauen wir was. Und das ist sozusagen unser Testbed, um neues Zeug auszuprobieren. Das Ganze hat dann angefangen, dass wir irgendwie so mit VMs und Vagrant und Chef in sowas zusammengeklöppelt haben. Das war toll. Und dann dachten wir so, okay, jetzt schauen wir mal, wie wir das Ganze auf unsere Infrastruktur anwenden. Und dann haben wir irgendwie gemerkt, okay, machen wir doch das mal mit Puppet. Also haben wir eigentlich den ganzen Infrastruktur von Grund auf neu mit Puppet gebaut. Und das kam eigentlich von unseren Erfahrungen, die wir hatten mit den lokalen Entwicklungsumgebungen. Und irgendwann im ganzen Prozess haben wir gemerkt, so ja, ein Webagentur und Hostingdienstleister, das passt irgendwie schon zusammen. Aber wenn du mit anderen Kunden zusammenarbeiten willst, wird es dann auch schwierig. Da haben wir ein Business Case gemacht. Und glücklicherweise haben wir da auch das Go bekommen, dass wir eigentlich den ganzen Web Hosting Teil aus der Firma auslagern konnten. Und dann waren wir da an dem Punkt, wo wir sagen, okay, wir werden eine eigene Firma machen. Aber wir hatten ja immer noch das Problem, dass wir halt den, wie das Gefühl hatten, ja, die VMs, wie das momentan läuft, das ist uns zu wenig flexibel. Weil das braucht viel RAM, jede Seite braucht eine neue VM, das ist irgendwie von gestern. Und wir haben Docker Container oder Container Lösungen angeschaut und genossen viel Ruhm und wurden breit eingesetzt. Aber wenn du irgendwie nicht gerade Netflix, Amazon oder Google warst, dann war das nicht so ein großes Ding, das da für dich überklebt. Und wir haben dann mal ein Docker ein bisschen angeschaut und das gab dann auch so Zeiten, wo halt wirklich Docker das Ding für Container wurde. Und dann haben wir mal versucht, ja, wie bauen wir denn eine lokale Entwicklungsumgebung mit Docker. Und Docker ist nicht perfekt. Und da haben wir gedacht, okay, unser Ziel ist, dass wir mehrere Entwicklungsumgebungen lokal betreiben können. Wir wollen die ganze SSH-Keygeschichte irgendwie gelöst haben. Wir wollen lokal E-Mails testen können. Also haben wir, um Docker eigentlich ein Toolset gebaut, das Pygmy heißt, dass uns das halt alles bringt. Also es ist eigentlich nichts anderes, das uns erlaubt, mehrere Seiten lokal zu entwickeln. Ja, und wir dachten da so, okay, das funktioniert lokal. Jetzt suchen wir mal ein bisschen die Erfahrung, wie funktioniert das denn, wenn da mal Produktionslast drauf kommt. Also haben wir mal ein paar Systeme oder Komponenten in unserem Hosting Stack einfach durch Docker Container setzt. So konnten wir eigentlich mit relativ wenig Risiko mal schauen, wie das denn so funktioniert. Auf was muss ich achten, welche Fehler kann ich machen. Und in der Zeit wurde halt Lagoon eigentlich der Projektname Intent zu allem, was wir gemacht haben. Ja, und dann kam so unser großes Projekt zu uns und sagt so, hey, wir haben Zeit, wir haben verschiedene Publikationen und sehr viel Traffic. Und wir haben eine De-Couple-Zeit, also einen Drupal im Backend und dann irgendwie sieben oder acht Node.js-Applikationen im Frontend, die halt dann die Publikationen rausspielen, könnte das auch in Container und unser Team war so, ja klar. Also haben wir eigentlich mit unserem größten Projekt begonnen, eine neue Lösung zu bauen. Und wir hatten Lagoon schon, aber wir mussten da ein bisschen Sachen umbauen und halt rausfinden, was braucht denn ein großes Projekt wirklich. Wir brauchten viel mehr Flexibilität, weil früher haben wir einfach normale Webseitenbetriebe und das war einfach so PRP und Datenbank-Server und Leaf. Und plötzlich kommt da wirklich so ein riesiges Ding, da kommen Fragen wie, wie skaliert wir denn und solche Sachen. Und in der Zeit haben wir auch, wir haben das Thema relativ lange hin und her gewälzt und so, wir haben die Frage so, ja, wenn wir das haben, wenn wir das einfach open sourcing, das war so eine Bierdiskussion mal. Und wir haben gesagt, ja, könnten wir eigentlich machen, das war dann so im Hintergrund. Und dann hatten wir da das System und das Leaf und wir hatten einen Kunden produktiv drauf. Und dann kam so die Frage so, ja, wenn wir das jetzt open sourcing, wann, wenn nicht jetzt. Und da haben wir das geopen sourcing. Da spreche ich dann ein bisschen auch noch drüber. Und momentan sind wir eigentlich die einzige Host, die wirklich die ganze Secret Source, die jeder andere Host hat, wo man einfach hingeht und neue Seite klickt, ist wirklich alles open sourcing, das findet man auf GitHub. Da kann man eigentlich einen ganzen Code gehen und sehen, welche Konfigurationen laufen. Aber zu Lagoon, was ist das genau? Und das ist hier mit meiner Zeit relativ knapp. Das Ding macht einiges. Das ist momentan das Microservice Diagramm, das klick ich gleich wieder weg. Was das ganze Ding eigentlich macht, ist, es gibt jedem Entwickler die Möglichkeit, lokal mit Docker und Containern das Ganze seine Infrastruktur aufzubauen und das dann einfach um uns ein Service weiterzugeben. Und was wir machen, wir schauen an, ja, welche Service brauchst du und welche Container brauchst du. Und von dem bauen wir dann basierend auf zwei, drei Konfigurationsdateien, die standardisiert sind, eigentlich die ganze Infrastruktur auf. Das ist das Ding, das ich irgendwie vor nun mal mehr oder weniger zehn Jahren zum ersten Mal mit einem Entwickler diskutiert habe, wo wir so gesagt haben, ja, wir haben jetzt automatisierte Systeme und das ist cool. Kann ich das auch einfach irgendwo in ein Pfeil reinschreiben und wenn ich einen neuen Branch mache in meinem Git, gibt das auch eine ganz neue Infrastruktur und das war, ja, geben wir uns noch ein bisschen Zeit, aber das ist eigentlich das. Also wir können die ganze Infrastruktur, die eine Webseite oder eine WebApp-Klikation braucht, komplett abbilden. Ja, dann haben wir das Ding geopen sourced und das ist bei GitHub so. Also das war dann relativ spannende Tag, es war etwa zwei Jahre her, wir haben ein Press-Release gemacht, Blogpost veröffentlicht, alle Tweets sind raus und ich saß so da so, toll, ich erzählte, was dann geschehen ist. Ich war da so da und es war in meiner Zeit, weil wir haben das auf Europa-Zeit getimped und dann hatten wir so 24 Stunden, wo wir so nachschauten, was läuft da jetzt und bei mir passiert es so etwa das. Auf uns hat niemand gewartet, eine Person hat sich gemeldet. Hermeson hat sich gemeldet. Nämlich wegen dem. Ja, wir haben das Repo hochgestellt und da war noch eine unserer Access Keys drin. Also der Lester von Hermeson hat sich da gemeldet und gesagt, hey, ich habe einen Kige von, könnt ihr mal bitte so revoken und schauen, dass ihr dann nicht in eine halben Stunde kommt. Fünf Minuten mit Profis. Aber was wir da gesehen haben, ist, dass die eigentliche Arbeit und das ganze Open Source Thema erst beginnt. Und ich habe da so ein paar Mantras und das eine Mantra ist, das Rad nicht neu erfinden. Also etwas, das wir sehr stark versuchen, ist, wenn es ein Open Source Tool gibt, dass uns die Möglichkeit gibt, etwas zu tun, dann bauen wir das nicht neu, dann verwenden wir das Tool. Unser ganzes Lock Storage, das ist ein Elastic Search, wir müssen dann nicht irgendwas HG Büchernes bauen, nur dass wir das Gefühl haben, ja, wir haben das selbst erfunden. Wir profitieren einfach von den anderen Open Source Projekten, die draußen sind. Und ich nenne das immer so auf den Schultern von Riesenstehen, weil es hilft uns, basierend auf anderen Projekten unser Projekt auch weiterzutreiben. Und unsere Kunden, oder die größeren Kunden von uns, die kommen dann auch mit Sachen und sagen, wäre cool, wenn wir das auch noch könnten. Und ich habe auch Leute drin im Team oder in der Kundschaft, die halt einfach das Zeug dann bauen. Und da kommst du in den Montag hin, denkst du, wow, was ist das? Und die so, ja, ich mach dann Ende Woche noch ein Pull Request. Ich hatte dann eine Idee übers Wochenende. Ein bisschen über die Vorteile reden. Also, was wirklich cool ist am ganzen Projekt, ist, dass halt der ganze Entwicklungsstatus für jeden ersichtlich ist. Man kann wirklich einfach auf GitHub gehen, auf Tickets und alle Sachen sind priorisiert. Und man sieht, was halt in der Planung rauskommen soll. In der Planung mit Deadlines sind wir nicht immer gut, weil wir halt wirklich basierend auf teilweise größere Features auf Kunden Anfragen machen. Aber generell sieht man, was da so in der Mache ist. Andere Vorteile, wenn ich jetzt über Omensoßprojekte spreche, ist, weil halt alles öffentlich ist, gibt es keine Barriere, die uns sagt, ja, da ist jetzt irgendwas im Tun. Aber es ist halt ersichtlich, wenn es ein Problem gibt und mehrere Leute das Problem haben, dann können sie das auch online finden. Und das ist cool, wenn ich halt in Barcarpo oder was das halt noch nicht super funktioniert, dann kann ich auch den Kunden sagen, hey, du kannst auf GitHub das Ding subscriben und dann siehst du, was der Status ist. Du siehst, wanns released wird. Und das ist halt wirklich eine coole Sache, da es nicht einfach ist. Ah ja, wir haben das eingeplant. Und das hat keinen Disconnect mehr zwischen einer Firma, die was macht, ein Omensoßprojekt, das was macht und dem Kunden. Du kannst wirklich sehen, was man kommt. Ich habe teilweise in GitHub Issues Kunden oder Nutzer des Produkts, die halt wirklich einfach einander helfen und da kommt einer so rein, ah ja, das habe ich so gefixt. Das ist ein Workaround und du kannst die Workarounds vom einen Projekt aufs andere anwenden. Das ist relativ cool. Wir haben eine öffentliche Roadmap und wir haben auch ein Idea Space. Also wir hatten auch Leute, die reinkamen und gesagt haben, hey, könnt ihr auch einfach so Native Kubernetes machen? Geht das? Und das ist ein Ding, das kam in wie letztes Jahr an und das haben wir jetzt angefangen zu überlegen. Ja, können wir das? Ich würde mich daran das Ganze so aufzusplinden, dass wir das längerfristig auch direkt auf Kubernetes machen können, dass die ganze Infrastruktur einfacher wird. Und für alle, die die Lösung nutzen, ist das ein viel kollaborativer Umgang, weil es ist nicht mehr, du sprichst immer zu einer Person, es ist halt, dass man probiert, das Problem zu finden. Wenn ich ein Problem finde, dann reporte ich das. Es ist halt anders, als was man sich normalerweise von Hostern oder im Geschäftsumfeld gewöhnt ist. Es gibt auch ein paar Herausforderungen. Wir haben, das war nach dem Release, wir hatten halt immer noch den Firmennamen überall drin. Da haben wir ein Ticket aufgemacht und gesagt, es ist schon cool, aber wenn ich ein Open Source Projekt zeige, wieso habt ihr da überall den Firmennamen drin? Das hat dann einen sehr lustigen Commit, der eigentlich alles Search Replaced hat mit dem Projektnamen Lagoon. Und wir haben das dann durch die Testpipeline gejagt und das hat größtenteils funktioniert. Die größtenteils, ihr seht da am Schluss, Entschuldigung. Am Schluss steht noch everything else. Das ist alles, was man da vergessen hatte. Das haben wir noch so hinterher geflickt. Das ist spannend, weil man halt auch direkten Feedback gekriegt hat und die Leute gesagt haben, ja, wenn dann Firmenname drin steht, ist das ja nicht wirklich Open Source, dann ist das ja euer Ding. Und das war halt schon spannend. Andere Herausforderungen. Jeder kann zum Projekt beitragen. Das muss aber erlernt sein. Wie ich vorher erwähnt hatte, Leute können das Zeug ändern. Leute können ihre Änderungen einbringen. Aber man muss sie eigentlich an der Hand nehmen und die Leute können das Zeug ändern. Wenn du mir den Fehler sagst, such doch mal, wo im Code das vorkommt. Das ist das Coole, weil ich habe Leute, mit denen ich zusammenarbeite, da kommt wirklich entweder schon die komplette Lösung in einem Pull Request oder es kommt ein so detaillierter Fehler beschrieb, dass einer von uns in den Engineers das durchliest und sagt, das habe ich geschrieben, ja, das habe ich verbockt Eine andere Herausforderung ist, dass gewisse Leute sich gar nicht involvieren wollen. Die wollen einfach sagen, hey, da ist was kaputt und wir sollen das dann flicken. Dann machen wir sozusagen den Proxy, um GitHub issues zu erstellen. Aber wenn dafür bezahlt wird, ist das auch kein Problem. Ein anderes lustiges Ding ist, dass plötzlich erwartet wird, dass alles, was wir machen, Open Source ist. Auch die ganz alten, bösen Legacy-Systeme, die wirklich nicht Open Source sind. Das ist dann schon spannend, wenn man sagt, ja, weißt du, das ist wirklich so fünf Jahre alt. Das war vor unserer Open Source sein. Das sind Systeme, die wir momentan aktiv versuchen, irgendwie loszuwerden. Es geht halt immer im Moment. Ein anderes Ding ist, dass eine Herausforderung ist, dass man den ganzen Code und einfach alles, was man macht, ein bisschen mehr mit Zorgfalt und Aufmerksamkeit bearbeitet. Man hinterfragt, macht die Änderung, die ich da mache, Sinn? Gibt es irgendwie Probleme? Muss sich eine Dokumentation anpassen? Wir hatten früher dieses Jahr ein Release, wo wir irgendwie die ganzen Suchserver kaputt gemacht haben, wenn man eine ganz spezielle Suchkonfiguration reingenommen hat. Wir haben einfach nicht daran gedacht, dass das irgendwie passieren könnte. Das war so für uns der Startpunkt, wo wir gesagt haben, ja, okay, hier müssen wir jetzt wirklich ein Prozess einbauen und das Ganze in wie sauber tracken und wirklich schauen, dass, wenn wir solche Changes drin haben, dass wir das auch an die Leute zurück kommunizieren. Kommunikation ist auch wichtig. Wenn wir größere Änderungen haben, gibt es immer ein Release-Log, das wirklich auch jetzt eine Section drin hat, wo man sieht, hey, wenn du das brauchst, könnte passieren, dass dieses und dieses eintritt. Das ist halt wichtig zu unterstreichen bei unseren Kunden, wie das halt funktioniert, dass sie halt wirklich auch dabei sind, sich in einem laufenden Projekt Änderungen mitzumachen. Andere Herausforderungen sind halt, größere neue Features zu bauen. Wie ich vorher erwähnt habe, ist die Idee, dass wir eigentlich nicht mehr auf OpenShift basieren, sondern auf Kubernetes laufen können. Und das ist eigentlich ein relativ fundamentaler Wäschel vom ganzen System. Und wir versuchen, dass eigentlich beides nebeneinander funktionieren wird. Aber es ist halt eine große Änderung. Also das braucht viel Handschmalz, bis das mal läuft. Und die andere große Frage, die ich mir jeden Tag wieder stellen stelle, ist, was kostet denn so ein Feature in einem OpenSoft-Projekt? Also wir haben Leute, die kommen und sagen, hey, wir machen so OpenData Sachen. Könnt ihr das auch? Wir sagen, ja, klar, können wir das auch. Jetzt müssen wir halt einfach schauen, wie wir das für euch umbauen und implementieren. Und was, dass wir jetzt letztlich gelernt haben oder erlernen durften, ist, dass nicht alle von uns betriebenen Plattformen die gleichen Release-Zyklen haben. Also wir haben Kunden, die halt sagen, ihr könnt auf die Plattform releaseen, wenn unser Board das absignet. Die kriegen alle ChangeLogs und schauen das durch und sagen, das könnt ihr nächste Woche releaseen. Und wir kommen, ursprünglich war das Projekt so wie ein Rolling Release. Also das hat jede Woche haben wir das einfach auf jeden Cluster rausgebügelt und das lief. Aber mit der Komplikation, dass wir halt aufpassen müssen, wer welche Version hat, haben wir auch relativ viele ChangeLogs eingebaut. Und das war ein spannendes Learning oder eine spannende Herausforderung, dass wir halt eigentlich von einem Rolling Release, wo alles irgendwie funktionieren muss, auf ein versionisiertes Release umstellen mussten. Aber reden wir ein bisschen über einen Rückblick auf zwei Jahre Entwicklung. Wir haben in den zwei Jahren hier sind ein paar Daten, die sind aktuell von heute Morgen. Wir haben 600 Pull Request abgeschlossen, momentan haben wir leider wieder 135 Open Issues. Ich sage jetzt leider, weil ich möchte die Zahl am liebsten unter 100 haben. Aber momentan mit so vielen Ideen, die wir da in das Projekt reinkippen oder auch mit dem ganzen Hey, lass uns mal überlegen, was wir alles brauchen für Kubernetes, direkt. Gibt es relativ viele zusätzliche Tickets, die wir halt in die Cluster müssen. Es gibt auch 80 Forks vom Projekt und ich kenne Leute, die eigentlich seit mehr als 9 Jahren einen Fork betreiben für sich und wir haben mit denen eigentlich nicht viel zu tun. Die lassen das für sich laufen, das ist cool. Und wir haben auch externe Verwirkende, die halt auch reinkommen und sagen hey, ich habe das gesehen, ich habe hier in der Dokumentation etwas gesehen und das uns helfen, da weiterzukommen. Das ist ein weiteres Open Source Mantra, das kein Beitrag eigentlich zu klein ist. Also ich bin noch so happy, wenn jemand reinkommt und sagt hey, ich habe hier ein Problem gehabt, ich habe hier ein Problem gemeldet, das ist cool. Oder wenn jemand seine Meinung einbringt, wenn sie berechtigt ist, dass jemand sagt hey, wir haben das schon gesehen, da hat es nicht funktioniert. Also überlegt euch mal, ob dir das auch so bauen wollte. Oder Leute, die einfach die Dokumentation einfach mal gegen Rechtschreibfehler prüfen. Wir haben dann ein Kollege von mir, der hat das mal eigentlich so einen Wochenende, so in 2, 3 Stunden alles durchgeklickt und das war doch ein sehr guter Beitrag an die ganze Dokumentation, dass sie sagt ja, ihr braucht da immer die verschiedenen Wörter für das und das wird halt alles mal standardisieren. Und drum sage ich, es ist eigentlich kein Beitrag zu klein, wenn jemand schon nur eine Idee hat, wie man etwas besser machen könnte, ist das schon toll. Und wenn ich auf die 2 Jahre zurückschau, ist es relativ spannend, was passiert ist. Wir dachten einfach, dass die Open Source Nest, oder dass wir halt das Open Source Projekt zur Verfügung stellen, wird uns helfen in Security Audits. Wir haben ein paar Nutzer von der Plattform, die halt wirklich jedes Jahr in Security Audit gegen die Plattform laufen lassen. Da kommt immer so die Frage so, ja, können wir Rout-Axis haben auf dem System und bei uns ist so, nee, wirklich nicht. Und was wir in der Vergangenheit gemacht haben, ist halt komplett die Infrastruktur von den Leuten neu aufgebaut und gesagt, hier, das ist eure Penetration Testing Plattform, ihr könnt sie kaputt machen, die wird einfach, das ist der Standard, wo auch eure Seite drauf ist. Aber es ist einfach nicht so cool. Und jetzt können wir eigentlich hingehen und das Ding bei euch selbst hochfahren und ihr könnt alle Konfigurationen sehen. Also es gibt eigentlich keine Blindspots mehr, wo man sieht, da versteckt jemand etwas vor uns. Und wir haben auch gesehen, dass es viele Leute gibt, die wirklich drauf etwas suchen, dass wirklich komplett Open Source ist. Die ganzen Stacks, die wir haben, sind eigentlich, passieren wir alles auf Open Source aber die ganzen Hosting Provider, die haben einfach so ihre Secret Source, die dann das ganze betreibt. Und das werden wir eigentlich mit unserer Lösung los. Und was auch cool ist, dass wir den Leuten die Möglichkeit geben, das auf ihrer eigenen Infrastruktur zu betreiben. Du kannst dich einfach zu ihnen im Hoster hingehen und sagen, hey, ich hätte gerne mal deine Plattform in meinem Rechenzentrum. Das heißt meistens, nee, sorry können wir nicht. Was ich auch sehe ist, dass das Vertrauen wäscht. Das ist etwas, das man sich arbeiten muss. Am Anfang haben wir eigentlich mich einen Kunden gestartet, die wir von der Web-Agentur übernommen haben. Aber wir sehen jetzt auch, dass halt andere Agenturen aufspringen und andere Kunden aufspringen und sagen, ja, das ist cool, wir wollen das auch. Und das ist das Spannende. Es ist auch wichtig zu sehen, dass wenn man das ganze standardisiert, also wenn man irgendwie 50, 60 Webseiten betreibt, dass es einfacher ist, wenn alle den gleichen Technologiesteck fahren. Und das ist halt cool zu sehen, dass die Agenturen oder die Kunden, die da mit mehrern Seiten kommen, zum Beispiel Universitäten, die für jede Fakultät eine eigene Webseite haben, dass das halt den extrem viel bringt, wenn alles standardisiert ist. Das Spannende ist, dass auch die Weiterentwicklung, die Richtung völlig offen ist. Also wir gehen momentan dahin, wo wir sehen, dass die ganze Welle mit den Containern hingeht. Und das heißt auch, dass ich eigentlich nicht mehr immer über Docker spreche, sondern dass ich einfach sage Container, weil Docker ist irgendwie nicht mehr so ein wichtiger Begriff in dem ganzen Ding. Weil wir unterdessen Möglichkeiten haben, die Container anders zu bauen, mit anderen Tools, die auch Open Source sind. Ein anderer Punkt, der super ist, ist halt Leute zu finden, die bei uns arbeiten wollen und eigentlich ein Großteil ihres Tages in ein Open Source Projekt stecken können. Das ist etwas, dass man selten einfach so hat, dass man sagen kann, hey, den ganzen Code, den du schreibst für die Plattform, wird Open Source sein. Und ein sehr wichtiger Punkt ist, dass wir auch mit der öffentlichen Hand oder Universitäten und den Behörden eigentlich relativ ein gutes, eine gute Beziehung haben, weil in vielen Ländern wird unterdessen gesagt, hey, wenn dir eine Ausreibung macht und ein Open Source Projekt um die Ecke kommt, dass das Problem löst, dann nehmen wir das Open Source Projekt. Nicht, dass man irgendwie Geld in Lizenzen investiert. Und das ist das Coole, das halt von Exzernen Gruppen halt Druck aufgesetzt wird auf die Behörden, die Länder, dass man gesagt, hey, wenn ihr Geld investiert, dann heißt das, dass das öffentliche Geld, das investiert wird, auch in öffentlichen Code umgewandelt wird. Und das ist cool. Und unterdessen können wir mehr als nur Drupal, was wir im Anfang gemacht haben. Wir haben jetzt verschiedene Sachen gemacht, wo wir halt die Couples-Seiten betrieben haben oder auch Dinge wie die ganze Open Data Container. Von einer Stadt kam die Anfrage, hey, wir würden da gerne unsere Open Data Sachen bei euch betreiben. Wir haben die Idee, wie man die Container bauen könnte, aber wir brauchen ein bisschen Unterstützung. Und da sind wir mit ihnen zusammengesessen und haben das Ganze halt gebaut, wie das das Open Data wie das Open Data Projekt das nutzt. Und das ist auch etwas, das wir auch geopened haben. Das anderes, das wir gelernt haben, ist da einfach, Dokumentation macht viel einfacher. Ein großer Teil meiner Contribution zum Projekt ist momentan Dokumentation verbessern. Ich mache viel Support. Ich sehe eigentlich täglich mit welchen Problemen, dass die Leute, die es nutzen, ob es auf der Engineering-Seite oder auf der Kunden-Seite ist, auf der Nutzer-Seite im Ende, mit was sie kämpfen. Und das ist die Liste, die abgearbeitet wird für Dokumentationsverbesserung. Wir haben, wie ich vorhin erwähnt habe, gelernt, dass die die ganzen Change-Logs sehr wichtig sind. Wir haben gesehen, hey, unsere Change-Logs sind da, aber die könnten besser sein. Also haben wir Prozesse implementiert, die halt zeigen, wie man, dass wir nichts vergessen, dass eigentlich jeder Release ein sauberes Release-Log hat, dass alles drin ist. Wir haben einen Release auf versionisierte Releases umgestellt. Wenn ein bisschen auf GitHub unterwegs ist und den, wo hingeht und ein Ticket dürfen will, die jungen Projekte, bei denen kommt einfach eine Maske mit einem Eingabefeld und man kann ein Ticket aufmachen. Das ist die Hölle, weil es erlaubt einfach, jemanden ein Titel einzugeben, sagen irgendwie, seinen Frust in einem Titel zu hinterlassen und das Problem dahinter ist. Was wir hier gemacht haben, ist, dass wir Issue und Pull Request-Vorlagen gemacht haben. Dass man, wenn man etwas reportiert, dass man eine Vorlage hat, was wir alles wollen, um zu verstehen, was das Problem ist. Um von Kunden abzuholen oder von der Person, die das Problem hat, abzuholen, was ist genau das Problem? Erklär's mir. Das hilft viel. Wir haben ein Text abgefangen, wo den Exchange-Log reinkommt. Du kannst nicht ein Pull Request aufmachen, ohne dass du spezifizierst, was kommt in den Exchange-Log? Das wird einfach vom Release-Manager, der das wochentlich release, wird das zurückgeschehen. Du hast kein Exchange-Log drin. Wir wissen nicht, was das ganze Ding macht. Auch wenn es im Code klar ist, aber wir wollen es in einer einfachen Beschreibung haben, wo es jeder versteht. Das ist ein klinglerer Mantra. Etwas ist immer kaputt. Ich sag meistens so, es ist einfach noch nicht perfekt. Wir spielen hier viel mit neuen Technologien. Neue Technologien haben ihre Tücken. Ich sag immer, wer auf all das technologien aufbaut, der basiert oder profitiert von allen Fehlern, die schon mal gemacht wurden. Da weiß man, wie man was konfiguriert. Probleme, man reinlaufen kann. Und das ist halt, dass wenn man mit einem jungen Open Source Projekt zusammenarbeitet, dass man wirklich eine konstante Veränderung hat. Dinge funktionieren halt, weil man die mal baut, weil man sagt, ja wir haben etwa so 50 Datenbanken, die wir betreiben muss, bis man halt an die Grenze stoßt, bis man halt merkt, ah ja, wir betreiben jetzt jenseits von 150 Datenbanken und das ist mein momentanes Paradebeispiel dass wir halt die Datenbanken auch aus Container betrieben haben. Das hat dann irgendwo halt nicht mehr skaliert, weil man nicht mehr Schreibgeschwindigkeit auf Festplatten hingekriegt hat. Oder was wir auch haben ist, dass wir teilweise von gewissen Nutzern sagen, ja aber ihr wollt jetzt das ändern, aber das ist doch weniger sicher, vor allem bei der Datenbank-Diskussion, weil wir halt jetzt System haben, dass wir die Datenbankkomponenten eigentlich aus dem ganzen Cluster rausgenommen haben und da wie der Datenbank-Server betreiben. Und wenn eine Komponente haben, die einfach hingeht und sieht, ah, jemand will eine MariaDB oder ein Postgres und das halt macht, aber das ist alles sicher, weil es über Username Passwords und über andere Sicherheits-Levels voneinander abgetrennt ist. Aber da gibt es auch teilweise Kunden, die sagen, hey, das will ich nicht und dann müssen wir denen auch einen Weg bieten, wie sie es halt ohne das Neue betreiben können. Und ja, vielleicht merken Sie halt, dass wir längerfristig, dass wir halt unsere Begründungen haben, wieso wir etwas so machen und das ist ein schwieriger Punkt, den wir immer wieder sehen müssen, wenn man halt viele Änderungen in einem Projekt hat, dass es auch Leute gibt, die sagen, hey, mach mal halb lang, wir wollen da nicht immer das Neuste. Ich möchte mit einer kleinen Frage an jeden, der jetzt hier drin sitzt, abschließen und das ist, wenn du deine Arbeit anschaust, das alles, was du am Tag machst, den ganzen Code, den du schreibst, die ganzen Ideen, die du hast, könnte jemand anderes von dem profitieren, wenn du das frei zur Verfügung stellen würdest. Und vielleicht ist ja das dein Code oder deine Sachen, die du den ganzen Tag machst, die Schulter des Riesen, auf welchem jemand anderes seine Lösungen und seine technischen Umsetzungen basieren könnte. Das ist etwas, das ich euch mitgeben würde und möchte damit abschließen und für Ihre Aufmerksamkeit danken. Fragen. Ich habe ein Mikrofonengel. Wie verdient eure Firma Geld, wenn ich fragen darf? Viele Firmen haben Angst, ihr Code zu veröffentlichen, weil sie sagen, das ist unser Kapital. Das ist ein Support-Modell oder da kam jetzt eure Mitarbeiterzahl vielleicht ein bisschen klein dafür vor, was zu sagen. Ja, klar, dazu könnte ich was sagen. Also, was wir machen ist, wir betreiben einerseits die Plattform für jeden, der eine Seite betreiben will. Wir haben jetzt aber auch angefangen, weil wir, wie ich erwähnt habe, die öffentliche Hand, zum Beispiel das australische, die australische Regierung die hatten Ausschreiben gemacht, wo halt auch die Open Source Komponente sehr wichtig waren. Das haben wir gewonnen. Da betreiben wir halt für die Regierung selbst ein kompletter Cluster, der komplett auf ihrer Infrastruktur läuft. Und das sind halt schon, das sind Support-Dienstleistungen. Also wir betreiben mehrere unserer Plattformen für verschiedene Kunden. Und das kann halt alles möglich sein. Also wir haben dann eine Support Komponente drin, die halt hilft, das Ganze zu finanzieren. Okay, danke. Darf ich noch eine Frage direkt anschließen? Natürlich. Du hast am Anfang gesagt, der Widerhalt von unserer Veröffentlichung war Anfangs sehr klein, bis auf Amazon. Was hat denn euch jetzt so für den Durchbruch da, was hat euch geholfen? Haben wir eigentlich Tech-Magazine oder Portal über euch geschrieben? Oder wie wurde ihr quasi bekannt? Ich, es wäre jetzt übertrieben zu sagen, wir sind mega bekannt. Wer von uns oder wer von hier im Raum kennt die Firma für die Arbeit? Okay, das ist keiner. Also ich würde jetzt sagen, es ist nicht so, dass wir mega bekannt werden. Wir sind bekannt in den Kreisen, wo halt in Rundum Drupal, weil wir halt da groß geworden sind oder groß geworden sind, weil wir halt von da kommen. Was uns hilft, ist, dass sich rumsprecht mit welchen Anbietern größere Projekte umgesetzt wird. Und das ist halt jetzt, was uns da wirklich hilft, ist zu sehen, dass die Leute, die verstehen, wie wir arbeiten, also dass wir zusammen mit den Kunden ihren nächsten Schritt oder die nächste Evolution der Webseiten oder der Web-Apps rausbringen können, wenn die verstehen, dass es nicht nur ein Produkt ist, wo ich sage, hier, ich klick mir eine Webseite, sondern das ist ein aktiver Dialogis, wo man halt auch mal was fordern kann und wir auch was speziell bauen, dass das dann wieder ins Projekt zurückfließt. Ich denke, da ist die Magie hinterm Ganzen, dass wir halt einen weiten Weg gehen und sehr angepasste Lösungen anbieten können. Wie geht dir um mit dem Code von Dritten, der zum Beispiel über Pull Requests kommt? Müssten die einen Copyright Assignment unterschreiben oder? Nee, momentan, wenn du einen, nee, überhaupt nicht. Es ist einfach, ich weiß gar nicht, wie die Lizenz, die wir drin haben, auswendig. Aber das ist eigentlich, es passiert auf der Glenna auch gleich eine Lizenz, die reinkommt. Es ist nicht so wie bei anderen Projekten, wo du zuerst was unterschreiben musst. Es ist einfach, hey, wenn du eine Idee hast, wenn du einen Change hast, dann be free to commit. Also unser Ziel ist es nicht da, irgendwie noch in was drum aufzubauen über die Ownership vom Code. Und wir arbeiten längerfristig auch dran, dass das nicht mehr auf unserem Github Account ist, sondern dass es halt ein Projekt Github Account gibt. Aber das ist momentan ein bisschen zurückgestuft, weil wir halt einfach auch noch andere Dinge haben, die wir gerade machen müssen. Andere Fragen. OK, wenn keine Fragen sind, ich bin die ganze Zeit da und wenn ihr Fragen habt, könnt ihr mir auf mich zukommen. Danke.