Microsoft hat verkündet, dass für Package-Maintainer im NuGet.org-Ökosystem – dem Paketmanager für .NET – das neue Sponsorship-Feature zur Verfügung steht. Es erlaubt ihnen das Hinterlegen von Sponsorship-URLs, unter der User ihnen finanzielle Unterstützung zukommen lassen können.

Der Link zu den Sponsorship-URLs erscheint als Herz-Emoji beziehungsweise „Sponsor“-Button auf der jeweiligen Paketseite. Nach einem Klick darauf können User mittels einer Plattform wie GitHub Sponsors oder Patreon ihre gewünschte Zahlung tätigen. Wie Microsoft betont, können auch kleine Beiträge einen großen Unterschied machen, um zur Verwaltung und Sicherheit kritischer Pakete beizutragen.

Eintragen von Sponsorship-Links

Entwicklerinnen und Entwickler, die einen Link zum Sponsoring einfügen möchten, müssen Besitzer oder Co-Besitzer des betreffenden NuGet-Pakets sein. Der Link muss zu einer der folgenden zugelassenen Plattformen führen: GitHub Sponsors, Patreon, Open Collective, Ko-fi, Tidelift oder Liberapay.

Auf der Paketmanagement-Seite des jeweiligen Pakets müssen Developer dafür zum Abschnitt „Sponsorship Links“ herunterscrollen und dort in das Formular einen oder mehrere Links eintragen, zum Beispiel Es lassen sich je Package-ID bis zu zehn URLs hinterlegen und per „Remove“-Button bei Bedarf wieder entfernen.

Nach dem Eintragen der URLs können Developer verifizieren, dass das Hinterlegen funktioniert hat, indem sie die öffentliche Seite ihres Pakets aufrufen. Dort sollte im „About“-Abschnitt der „Sponsor“-Button erscheinen und beim Klick darauf ein Pop-up zu den hinterlegten URLs anzeigen.

Im Rahmen des Sponsorship-Features werden auf NuGet.org keine persönlichen oder Zahlungsinformationen gespeichert, denn die Transaktionen geschehen auf den gewählten externen Plattformen, wie Microsoft betont.

Weitere Informationen und ein FAQ-Abschnitt finden sich in der Ankündigung auf Microsofts Entwicklerblog.

(mai)

Moin.

Wir sind eine große Familie, sang Peter Alexander 1973, und mancher Chef holt den Schlager auch heute nochmal heraus. Während das Lied eine Geschmacksfrage ist, lädt der Satz im Firmenkontext dazu ein, aufmerksam zu werden. „Wir sind eine große Familie“, sagt der Chef. Klingt super, finde ich. Oder doch nicht?

Auch Familien haben ihre Schattenseiten. So wurden 2023 mehr als 250.000 Menschen das Opfer häuslicher Gewalt. Davon sind mehr als 78.000 Opfer innerfamiliärer Gewalt zwischen nahen Angehörigen. (Quelle: BKA-Lagebild, BMFSFJ)

Vermutlich meint mein Chef das nicht, wenn er von Familie spricht, aber was denn dann? Welchen Zweck verfolgt er mit seiner Aussage? Was will er von mir? Welches Verhalten soll meinerseits hervorgerufen werden? Und, last, but not least: Wie gehe ich damit um?

Am liebsten würde ich es bei den Fragen belassen, weil Ihr bestimmt auch eigene Antworten parat habt. Dann wäre der Beitrag allerdings sehr kurz. Deshalb ein Vorschlag: Macht beim Lesen eine Pause, denkt über die Fragen nach und schreibt Antworten in die Kommentare. Danach könnt Ihr meine Antworten lesen. Ich bedanke mich im Voraus für Eure Beiträge.

Ein Märchen

Zum Zweck der Äußerung: Meine beste Antwort lautet „Bindung“. Wer das sagt, möchte andere an sich binden; möglicherweise vor dem Hintergrund einer unangenehmen Aufgabe oder bevorstehenden negativen Veränderung. Zumindest denke ich, dass es nicht nötig ist, bei der Bindung nachzuhelfen, wenn das Arbeitsleben im Augenblick das reinste Paradies ist. Wer sollte dann gehen wollen?

Bindung an sich ist ja nicht so schlecht, allerdings stellt sich eine weitere Frage: Was ist, wenn die wirtschaftliche Lage für die Firma schlechter wird? Wir sind doch eine große Familie, oder? Hier wird doch niemand gefeuert, oder? Wir alle kennen die Wahrheit und das genügt, um die Mär der großen Familie als genau das zu entlarven: ein Märchen. Es gibt Firmen, die eine Ausnahme darstellen, aber dort ist es vermutlich nicht nötig, auf die starke Bindung mit der Familienaussage hinzuweisen.

Damit kommen wir zur wichtigsten Frage: Wie gehe ich damit um? Das hängt natürlich stark vom Einzelfall ab, sodass ich hier keine universelle Antwort anbieten kann. Mein Vorschlag ist, klar zu kommunizieren, wie das, was man gerade hört, ankommt.

Zum Einstieg vielleicht eine Erwiderung der Art: „Wenn ich höre, dass wir eine Familie sind, habe ich den Eindruck/bekomme ich das Gefühl, dass …“

Bindung funktioniert anders

Wenn es um Bindung geht, kann man deutlich machen, dass wir keine Familie sind und Bindung anders funktioniert. Das ist der richtige Zeitpunkt, die eigene Motivation auszusprechen. Was treibt Dich an und was möchtest Du demnächst oder mittelfristig erreichen? Wenn die Wir-sind-eine-Familie-Aussage mit der unangenehmen Aufgabe wie Überstunden für einen längeren Zeitraum verbunden ist, ist es ein guter Zeitpunkt, über Gegenleistungen zu sprechen. Die Palette ist breit gefächert. Man kann über Überstundenausgleich, Sonderurlaub, Fortbildungen oder natürlich Prämien sprechen. Das sind alles persönliche Benefits.

Alternativ kann man auch Veränderung in der Arbeit ansprechen. Geht es beispielsweise darum, dass ein vorgegebener Termin in der Produktentwicklung nicht ohne Überstunden des Teams gehalten werden kann, ist es vielleicht der richtige Zeitpunkt, auf die Ursache einzugehen. Eine mögliche Forderung wäre dann Mitspracherecht bei zukünftigen Terminen. Wozu sollte man für das anstehende Release Überstunden machen, wenn absehbar ist, dass es beim nächsten Release genauso läuft?

In jedem Fall verstehe ich „Wir sind eine Familie“ als Einstieg in eine Verhandlung. Wer sie als Person oder als Team nicht nutzt, verschenkt die Chance für eine Verbesserung.

Erst Lesen, dann Hören

Im Podcast Escape the Feature Factory greife ich ausgewählte Themen des Blogs auf und diskutiere sie mit einem Gast. Durch den Austausch lerne ich eine zweite Perspektive kennen. Wenn Du auch daran interessiert bist, findest Du den Podcast bei Spotify, Deezer, Amazon Music, und Apple Podcasts. Wenn Du die Themen, die ich im Blog anspreche, in Deiner Firma verbessern möchtest, komm‘ in unsere Leadership-Community für Softwareentwicklung.

(rme)

In modernen Softwareprojekten ist das Deployment längst keine einmalige Aktion mehr, sondern ein kontinuierlicher Prozess. Anwendungen bestehen aus Dutzenden oder Hunderten von Services, laufen in Containern und erhalten oft mehrmals am Tag ein Update. Um neue Funktionen schrittweise zu aktivieren, greifen Teams auf Feature Flags oder Konfigurationsschalter zurück. Diese Flexibilität ist ein Segen – und gleichzeitig eine erhebliche Gefahrenquelle.

Muster 5: Deployment, Konfiguration und Flags: Wenn ein Schalter Millionen kostet

Ein eindrückliches Beispiel liefert der Fall Knight Capital aus dem Jahr 2012. Das Unternehmen war ein Schwergewicht im elektronischen Handel an der US-Börse und wickelte täglich Millionen von Transaktionen ab. Am 1. August 2012 spielte Knight ein neues Softwareupdate aus, das eine Funktion namens „Retail Liquidity Program“ unterstützen sollte. Die Bereitstellung lief jedoch schief: Ein Feature Flag, das ursprünglich für Testzwecke existierte, wurde auf einem von acht Servern nicht korrekt aktualisiert.

Was folgte, war ein Paradebeispiel für die Kaskade aus Konfigurationsfehlern und fehlender Deployment-Sicherheit: Auf sieben Servern lief die neue Logik wie geplant, ein einzelner Server führte beim Start jedoch alten Code aus, der längst nicht mehr produktiv sein sollte – weil das Flag dort nicht korrekt gesetzt war.

Dieser alte Code enthielt eine Legacy-Routine, die fälschlicherweise massenhaft Kaufaufträge generierte. Innerhalb von nur 45 Minuten verursachte Knight Capital rund 440 Millionen US-Dollar Verlust. Das Unternehmen stand am Rand der Insolvenz, nur eine schnelle Übernahme und externe Finanzierung retteten es vor dem Aus.

Die Lehren aus diesem Vorfall sind für jede Organisation relevant – ob Börsenhandel, E-Commerce oder SaaS-Betrieb:

1. Feature Flags brauchen einen Lebenszyklus: Ein Schalter, der nicht dokumentiert, nicht versioniert und nicht befristet ist, wird irgendwann zum Risiko. Flags müssen ein Ablaufdatum, einen Owner und eine Entfernungsperspektive haben.
2. Deployments müssen atomar und konsistent sein: Es reicht nicht, acht Server irgendwann nacheinander zu aktualisieren. Ohne Sicherstellung, dass alle Instanzen dasselbe Release und dieselbe Konfiguration fahren, entstehen Split-Brain-Situationen. Moderne CI/CD-Pipelines oder Kubernetes-Rollouts lösen dieses Problem durch atomare Deployments und Health-Checks. „Atomar“ bedeutet hier nicht, dass alle Instanzen gleichzeitig umgestellt werden, sondern dass innerhalb eines Deployments keine Mischzustände existieren.
3. Immutable Infrastructure ist die beste Versicherung: Systeme, die man nicht nachträglich verändert, sondern bei Änderungen komplett neu instanziiert, vermeiden Zombiecode. Wer ein neues Image ausrollt, kann sicher sein, dass kein Server alten Code im RAM behält.
4. Staged Rollouts und Kill-Switches reduzieren den Schaden: Große Änderungen sollten zunächst bei einem Bruchteil der Instanzen aktiviert werden, am besten begleitet von automatisierten Metriken. Ein zentraler Schalter zum sofortigen Abschalten (Kill-Switch) kann Milliardenverluste verhindern. Jede Stufe eines Rollouts ist dabei für sich konsistent, aber die Ausweitung auf alle Instanzen erfolgt schrittweise.
5. Runbooks und Übung unter Realbedingungen: Selbst die beste Technik hilft wenig, wenn im Ernstfall niemand weiß, wie man reagiert. Unternehmen, die Notfallprozeduren für fehlerhafte Deployments proben, reagieren schneller und souveräner.

Interessant ist, dass Knight Capital nicht am Fehlen von Technologie scheiterte. Die Tools für sichere Deployments existierten längst. Es war vielmehr ein Organisations- und Prozessversagen, bei dem technische Schulden (wie Legacy-Code und Flag-Wildwuchs) und menschliche Routine („haben wir immer so gemacht“) zusammenkamen.

Für moderne Cloud- und Webprojekte gilt übrigens dasselbe Muster: Wer Feature Flags einsetzt, ohne Lifecycle und Dokumentation zu etablieren, erzeugt unbemerkt eine tickende Zeitbombe. Und wer Deployments manuell oder halbautomatisch ausrollt, nimmt Inkonsistenzen in Kauf, die sich irgendwann rächen.

Die Lösung ist eine Kombination aus Disziplin und Automatisierung:

• Feature Flags werden wie Code behandelt, mit Versionierung, Owner und Entfernungspflicht.
• Deployments laufen atomar und reproduzierbar, am besten als Infrastructure as Code.
• Ein zentraler Kill-Switch schützt vor irreversiblen Schäden.

Knight Capital ist das prominenteste Beispiel, aber ähnliche Zwischenfälle gab es seither mehrfach – von falschen Cloudkonfigurationen bis zu versehentlich aktivierten Debug-Modi in der Produktion. Und jedes Mal zeigt sich erneut: Ein einziger vergessener Schalter kann ausreichen, um ein Unternehmen ins Wanken zu bringen.

(who)