Letzte Woche veranstalteten wir das erste Treffen der NGINX-Community in San José, Kalifornien, seit dem Ausbruch von COVID-19. Es war großartig, unsere Open-Source-Community aus der Bay Area persönlich wiederzusehen und den Vorträgen unserer Referenten zuzuhören.
Nach einer Einführung durch Shawn Wormke, General Manager von F5 NGINX, erläuterte Maxim Konovalov, CTO und Mitbegründer von NGINX, ausführlich die Geschichte von NGINX – von den „dunklen Zeiten“ des Projekts bis hin zu den jüngsten Ereignissen. Aufbauend auf dieser Geschichte richteten wir den Blick in die Zukunft. Insbesondere stellten Principal Engineer Oscar Spencer und Principal Technical Product Manager Timo Stark die spannende neue Technologie WebAssembly vor und zeigten, wie sie zur sicheren und effizienten Lösung komplexer Probleme eingesetzt werden kann. Timo gab uns außerdem einen Überblick über NGINX JavaScript (njs), erläuterte dessen Architektur und demonstrierte, wie sich damit viele der komplexen Anwendungsszenarien von heute bewältigen lassen.
Das Highlight des Meetups war vor allem unser erneuertes gemeinsames Bekenntnis zur Open-Source-Community von NGINX.
Unser Ziel bei NGINX ist es, auch weiterhin ein Open-Source-Standard zu sein, ähnlich wie OpenSSL und Linux. Unsere Open-Source-Projekte werden von F5 gesponsert und bislang größtenteils von fest angestellten Mitarbeitenden bei F5 unterstützt, wobei die Community nur in begrenztem Umfang Beiträge geleistet hat. Dieses Modell hat sich für unsere Projekte zwar bewährt, doch wir sind überzeugt, dass der langfristige Erfolg davon abhängt, eine wesentlich größere und vielfältigere Community von Mitwirkenden einzubeziehen. Durch den Ausbau unserer Open-Source-Community stellen wir sicher, dass die besten Ideen Innovationen vorantreiben, während wir uns darum bemühen, komplexe Probleme moderner Anwendungen zu lösen.
Um dieses Ziel zu erreichen, gehen wir die folgenden Verpflichtungen ein, die die Langlebigkeit, Transparenz und Wirkung unserer Open-Source-Projekte gewährleisten:
- Bei der Annahme von Beiträgen werden wir offen, konsequent, transparent und fair vorgehen.
- Wir werden auch weiterhin neue Projekte weiterentwickeln und als Open Source veröffentlichen, die den technologischen Fortschritt vorantreiben.
- Wir werden Projekte auch weiterhin unter von der OSI anerkannten Softwarelizenzen anbieten.
- Wir werden bestehende Projekte oder Funktionen nicht entfernen und kommerzialisieren.
- Wir werden die Nutzung unserer Projekte nicht einschränken.
Mit diesen Zusagen hoffen wir, dass unsere Projekte mehr Beiträge aus der Community erhalten und sich daraus schließlich Maintainer und Kernmitglieder außerhalb von F5 entwickeln.
Diese Verpflichtungen stellen jedoch eine grundlegende Veränderung unserer Arbeitsweise dar. Bei vielen unserer Projekte, an denen nur wenige Personen mitwirken, wird diese Umstellung unkompliziert sein. Bei unserem Flaggschiff, dem NGINX-Proxy, der auf eine lange Geschichte und eine nachweisliche Erfolgsbilanz zurückblickt, erfordern diese Änderungen hingegen eine sorgfältige Planung. Wir möchten dabei umsichtig vorgehen und unsere Community frühzeitig informieren, damit sie sich mit möglichst geringen oder gar keinen Beeinträchtigungen auf diese Änderungen einstellen und sie übernehmen kann.
Wir freuen uns sehr über diese Zusagen und ihre positiven Auswirkungen auf unsere Community. Außerdem freuen wir uns auf weitere Gelegenheiten für persönliche Treffen in der Zukunft! Weitere Informationen und detaillierte Zeitpläne für diesen Übergang werden in Kürze auf nginx.org veröffentlicht.
Über den Autor
Ähnliche Blogbeiträge
Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
Beim NGINX Sprint 2022 besinnen wir uns auf unsere Open-Source-Wurzeln. Erfahren Sie mehr über die Initiativen, die wir im kommenden Jahr verfolgen, und teilen Sie uns mit, was Sie sich wünschen.
Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
Ein Ingress-Controller kann eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Erfahren Sie, wie Sie Ihre Ingress-Anforderungen ermitteln, um die beste Option auszuwählen.
Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet
Wir haben kürzlich den Lösungsleitfaden zum NGINX Ingress Controller um Empfehlungen zur Dimensionierung für Amazon Elastic Kubernetes Service (EKS) ergänzt. In diesem Blogbeitrag erläutern wir, wie wir diese Empfehlungen erarbeitet haben, und stellen Ihnen alle Informationen zur Verfügung, die Sie benötigen, um selbst ähnliche Tests durchzuführen.
Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77
Bei der Fehlersuche bei Datenverkehrsproblemen zwischen NGINX und Upstream-Servern konnte CDN77 die benötigten Daten nur aus dem Fehlerprotokoll mit aktivierter Debug-Ausgabe beziehen, was die Leistung beeinträchtigt und riesige Dateien erzeugt. Daher entwickelte das Team ein neues benutzerdefiniertes Modul, das ausschließlich die benötigten Daten protokolliert.
Ankündigung von NGINX Plus R16
NGINX Plus R16 ist eine einheitliche, elastische Ingress- und Egress-Schicht für Anwendungen, die die Funktionen eines Load Balancers, API-Gateways und einer WAF vereint und neue Features wie clusterfähige Ratenbegrenzung, Schlüssel-Wert-Speicher, „Random with Two Choices“, verbessertes UDP-Load-Balancing und vieles mehr bietet.
5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
Entdecken Sie fünf Gründe für den Wechsel zu einem softwarebasierten Load Balancer wie NGINX Plus, darunter Kosteneinsparungen, die Einführung von DevOps und eine einheitliche Lösung für alle Umgebungen.