Was wir gelernt haben, als wir einen großen Teil von Mailgun als Open Source veröffentlicht haben

Vor einigen Wochen veröffentlichten wir als Open Source Flanker, unsere Bibliothek zur MIME-Verarbeitung und E-Mail-Validierung. Wir haben uns sehr über die Veröffentlichung und das große Interesse der Python-Community gefreut. Dieser Tweet steht stellvertretend für das, was wir seit der Veröffentlichung gehört haben:

Software als Open Source zu veröffentlichen mag einfach erscheinen, ist aber weitaus komplexer, als den Code einfach auf GitHub hochzuladen und die Sache als erledigt zu betrachten. Tatsächlich waren wir von einigen der aufgetretenen Herausforderungen überrascht. Daher möchten wir Einblicke in den Prozess geben, um hoffentlich anderen Entwicklerteams zu helfen, die planen, ihren eigenen Code als Open Source zu veröffentlichen. Im Folgenden erfahren Sie, wie wir vorgegangen sind und was wir dabei gelernt haben.

Ursprünglich wollten wir Guardpost, unseren Validator für E-Mail-Adressen, als Open Source veröffentlichen. Als wir diesen Weg einschlugen, stellten wir schnell fest, dass es wesentlich wertvoller wäre, dies mit unserer MIME-Parsing-Bibliothek zu bündeln und gemeinsam als Flanker zu veröffentlichen. Dies führte zu zusätzlichen Komplikationen, da wir nun einen beträchtlichen Teil der zentralen Codebasis von Mailgun als Open Source zur Verfügung stellten.

Da Flanker ursprünglich nicht für die Nutzung durch Dritte konzipiert war, bestand die Herausforderung darin, sicherzustellen, dass alle Abhängigkeiten zur proprietären Codebasis entfernt wurden. Wir wollten anderen, die das Tool nutzen, nicht den Einsatz bestimmter Technologien aufzwingen. Daher haben wir Teile von Flanker, die spezifische Python-Module oder Datenbanken wie Redis und dnspython nutzten, modularer gestaltet. Nutzen Sie nun eine beliebige (oder gar keine) Datenbank, um Ihre Ergebnisse zwischenzuspeichern.

Dies bedeutete, dass wir zunächst den Code herauslösen und sicherstellen mussten, dass er für Dritte nutzbar ist, um Flanker anschließend in seiner neuen Form wieder effektiv in Mailgun zu integrieren. Wir nutzten diese Gelegenheit auch, um große Teile des Adress-Parsers zu überarbeiten (siehe 5. unten), was die Sache komplizierter machte.

Wir hätten einfach unsere interne Flanker-Codebasis forken, die Abhängigkeiten nach bestem Wissen entfernen und intern weiter das nutzen können, was bereits funktionierte. Doch dann hätten wir entweder den Open-Source-Code vernachlässigt oder zwei verschiedene Codebasen pflegen müssen. Stattdessen haben wir beschlossen, den Open-Source-Code weiterhin in der Produktion einzusetzen.

Wenn wir nun einen Pull Request mergen (wir haben acht seit der Open-Source-Veröffentlichung von Flanker vor einigen Wochen durchgeführt und vier weitere stehen aus), müssen wir nicht nur auf sauberen Code, Wartbarkeit und Leistung achten, sondern auch sicherstellen, dass alle Änderungen reibungslos mit dem Rest von Mailgun zusammenarbeiten.

Wie Sie sich vorstellen können, sind sowohl das Adress-Parsing als auch das MIME-Parsing das Herzstück von Mailgun. Da wir bei der Open-Source-Veröffentlichung erhebliche Änderungen am Code vorgenommen hatten, mussten wir bei der Rückintegration in Mailgun sehr vorsichtig sein, um die Anwendungen unserer Kundschaft nicht zu beeinträchtigen. Vielleicht nicht ganz so beeindruckend, aber es fühlte sich ein wenig an wie ein Spagat zwischen zwei rückwärts fahrenden Sattelschleppern.

Wir haben dies erreicht, indem wir Flanker in Phasen eingeführt haben. Zunächst haben wir Flanker für einen kleinen Teil unseres Traffics bereitgestellt. So konnten wir Situationen erkennen, in denen das Verhalten des neuen Adress-Parsers strenger war als zuvor. Bestimmte Dinge, wie das Zulassen von Steuerzeichen in Anzeigenamen, haben wir aufgrund des Sicherheitsrisikos untersagt. Bei anderen Aspekten, wie dem Unicode-Support, haben wir uns bemüht, bei der Akzeptanz so flexibel wie möglich zu sein. Ja, das bedeutet, dass Sie jetzt das Kot-Emoji als Anzeigenamen über Mailgun versenden und wir es korrekt kodieren und weiterleiten.

Wir hielten es auch für klug zu prüfen, ob wir es als Open Source veröffentlichen könnten, ohne entlassen zu werden. Flanker ist ein zentraler Bestandteil von Mailgun und daher für Rackspace äußerst wertvoll. Auch wenn wir der Meinung sind, dass es manchmal eine gute Strategie ist, um Verzeihung zu bitten statt um Erlaubnis, um Dinge voranzutreiben, war dies wahrscheinlich nicht der richtige Zeitpunkt dafür. Daher haben wir es mit den Rechts- und Produktteams von Rackspace abgestimmt, um sicherzustellen, dass sie einverstanden sind. Glücklicherweise lautet der Slogan von Rackspace „The Open Cloud Company“ und das Unternehmen setzt auf Open-Source-Software. Es war also nicht schwer, das Team davon zu überzeugen, dass die Veröffentlichung von Flanker als Open Source der richtige Schritt war.

Wir haben unseren MIME-Parser schon lange in der Produktion eingesetzt, aber der E-Mail-Validator (Guardpost) war relativ neu. Wir haben Guardpost als API eingeführt, bevor wir Flanker als Open Source veröffentlicht haben. So konnten wir vor der Open-Source-Veröffentlichung effektiv unter realen Bedingungen testen.

Als Guardpost immer beliebter wurde, hatte das Tool trotz Ausführung auf einem ziemlich leistungsstarken, fest zugewiesenen Server Probleme, den anfallenden Traffic zu bewältigen. Wir haben also einige Zeit mit dem Profiling von Guardpost verbracht, um die Ursache für die Verlangsamung zu finden. Es stellte sich heraus, dass es an der Rechtschreibkorrektur lag. Wir haben eine Weile recherchiert, wie wir sie verbessern können, und sie schließlich komplett neu geschrieben. In unserem Blogbeitrag erfahren Sie, wie wir die Rechtschreibkorrektur 135-mal schneller gemacht haben als zuvor.

Zudem konnten wir eine Vielzahl von Bugs beheben, die von der Nutzerschaft gemeldet wurden. Das reichte vom Hinzufügen des Internet-Explorer-Supports für unsere Validator-Demo (niemand von uns hatte tatsächlich einen Windows-Rechner; wir mussten eine Windows-Lizenz erwerben, um diesen Bug zu beheben) bis hin zum direkten Versand von E-Mails an eine Top-Level-Domain (TLD).

Den Code vor der Open-Source-Veröffentlichung in der Produktion einzusetzen, gab uns das Vertrauen, stolz auf den Code zu sein, den wir der Öffentlichkeit zugänglich machten.

Das ist ein wichtiger Punkt. Wenn Sie an einer internen Codebasis arbeiten, können Sie einfach zu der Person gehen, die sie geschrieben hat, und eine kurze Frage stellen. Bei Open-Source-Software ist das nicht der Fall. Daher wollten wir sicherstellen, dass Flanker gut dokumentiert ist, damit sich neue Mitwirkende leicht einarbeiten können. Das bedeutet, dass Flanker sowohl durch Kommentare im Code als auch durch externe Dokumentationen gut beschrieben ist, wie beispielsweise eine Schnellstart-Anleitung, Nutzerhandbuch und API-Referenz.

Das sind also unsere Erkenntnisse aus der Open-Source-Veröffentlichung von Flanker. Auch wenn es letztendlich viel Arbeit war, war es ein kathartischer Prozess, und wir freuen uns darauf, in Zukunft von den Vorteilen zu profitieren.

Teilen Sie Ihre Erfahrungen gerne in den Kommentaren zu diesem Beitrag oder auf HackerNews.

Ihr Mailgun-Team

Autor: The Sinch Mailgun team The Sinch Mailgun team shares news, best practices, and strategies to take your products and apps to the next level using email. Subscribe to our newsletter to get all the articles in your inbox!