Microsoft hat die zweite Preview-Version für .NET 11.0 veröffentlicht und bringt darin unter anderem Neuerungen für die asynchrone Programmierung.

Die Schlüsselwörter async und await sind in vielen modernen Programmiersprachen verankert, zum Beispiel in Python seit 2015, in JavaScript seit 2017, in Rust seit 2019 und in Swift seit 2021. Auf die Frage „Wer hat es erfunden?“ muss man in diesem Fall sagen: Microsoft. Im Jahr 2012 erschienen diese beiden Schlüsselwörter zuerst in C# Version 5.0 und Visual Basic .NET Version 11.0. Sie vereinfachten die asynchrone Programmierung für Entwicklerinnen und Entwickler gegenüber vorher existierenden Konzepten und inspirierten danach viele andere Programmiersprachen.

Was für Entwicklerinnen und Entwickler einfach ist, ist unter der Haube aber bis heute komplex: In den .NET-Sprachen sind async und await bisher im Compiler als State Machines realisiert. In .NET 11.0 Preview 2 bringt Microsoft nun eine weiterentwickelte Version der .NET-Laufzeitumgebung Common Language Runtime (CLR), die nativ das Aussetzen und die Wiederaufnahme asynchroner Methoden unterstützt. Das erzeugt nicht nur weniger Overhead als die bisherigen State Machines, sondern ermöglicht schlankere Stack Traces und einfacheres Debugging.

Listing 1 zeigt vier asynchrone Methoden, die sich gegenseitig aufrufen.

using System.Diagnostics;
namespace NET11_Console.Runtime;
 
public class NET11_RuntimeAsync
{
 
 public async Task Run()
 {
  await MethodeEbene1();
 }
 
 async Task MethodeEbene1()
 {
  await Task.CompletedTask;
  await MethodeEbene2();
 }
 
 async Task MethodeEbene2()
 {
  await Task.CompletedTask;
  await MethodeEbene3();
 }
 
 async Task MethodeEbene3()
 {
  await Task.CompletedTask;
  Console.WriteLine(new StackTrace(fNeedFileInfo: true));
 }
 
}

Listing 1: Verkettung asynchroner Methoden

Bisher sah man als Ergebnis von Listing 1 die State Machine im Stack Trace:

   at NET11_Console.Runtime.NET11_RuntimeAsync.MethodeEbene3() in 
 h:\git\ITVDemos\NET11\NET11_Console\Runtime\NET11_RuntimeAsync.cs:line 27
   at
 System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](TStateMachine&
 stateMachine)
   at NET11_Console.Runtime.NET11_RuntimeAsync.MethodeEbene3()
   at NET11_Console.Runtime.NET11_RuntimeAsync.MethodeEbene2() in
 h:\git\ITVDemos\NET11\NET11_Console\Runtime\NET11_RuntimeAsync.cs:line 21
   at
 System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](TStateMachine&
 stateMachine)
   at NET11_Console.Runtime.NET11_RuntimeAsync.MethodeEbene2()
   at NET11_Console.Runtime.NET11_RuntimeAsync.MethodeEbene1() in 
 h:\git\ITVDemos\NET11\NET11_Console\Runtime\NET11_RuntimeAsync.cs:line 15
   at
 System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](TStateMachine&
 stateMachine)
   at NET11_Console.Runtime.NET11_RuntimeAsync.MethodeEbene1()
   at NET11_Console.Runtime.NET11_RuntimeAsync.Run() in h:\git\ITVDemos\NET11\NET11_Console\Runtime\NET11_RuntimeAsync.cs:line 9
   at
 System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](TStateMachine&
 stateMachine)
   at NET11_Console.Runtime.NET11_RuntimeAsync.Run()
   at Program.
$(String[] args) in h:\git\ITVDemos\NET11\NET11_Console\Program.cs:line 8

Mit der neuen Laufzeitunterstützung für Asynchronität ist der Stack Trace deutlich kompakter:

at NET11_Console.Runtime.NET11_RuntimeAsync.MethodeEbene3() in 
h:\git\ITVDemos\NET11\NET11_Console\Runtime\NET11_RuntimeAsync.cs:line 27
   at NET11_Console.Runtime.NET11_RuntimeAsync.MethodeEbene2() in 
h:\git\ITVDemos\NET11\NET11_Console\Runtime\NET11_RuntimeAsync.cs:line 21
   at NET11_Console.Runtime.NET11_RuntimeAsync.MethodeEbene1() in 
h:\git\ITVDemos\NET11\NET11_Console\Runtime\NET11_RuntimeAsync.cs:line 15
   at NET11_Console.Runtime.NET11_RuntimeAsync.Run() in 
h:\git\ITVDemos\NET11\NET11_Console\Runtime\NET11_RuntimeAsync.cs:line 9
   at Program.
$(String[] args) in h:\git\ITVDemos\NET11\NET11_Console\Program.cs:line 8

Auf dieser Basis konnte Microsoft auch das Debugging-Erlebnis verbessern, siehe Pull Request „Runtime support for breakpoints and stepping“ auf GitHub.

Allerdings erfordert die neue Unterstützung für Asynchronität in der Laufzeitumgebung aktuell noch, dass diese Neuerung in der Projektdatei separat aktiviert wird, siehe Listing 2.

 
 
  net11.0
  …
 
 
 
 
   runtime-async=on
   true
 

Listing 2: Aktivierung der Asynchronität in der Laufzeitumgebung per Projekteinstellungen

Alle TAR-Formate

Das TAR-Archivformat beherrscht .NET seit der Version 7.0 mit den Klassen TarFile, TarEntry, TarReader und TarWriter im Namensraum System.Formats.Tar. Bei der Erstellung einer TAR-Datei mit TarFile.CreateFromDirectory() und TarFile.CreateFromDirectoryAsync() wurde als Archivformat immer das PAX-Format (POSIX.1-2001) verwendet. Entwicklerinnen und Entwickler haben seit .NET 11.0 Preview 2 die Möglichkeit, alle vier TAR-Formate zu wählen: TarEntryFormat.V7 (das ursprüngliche TAR-Format), TarEntryFormat.Ustar (Unix Standard TAR), TarEntryFormat.Gnu und TarEntryFormat.Pax.

Dies geschieht durch den zusätzlichen Parameter mit einem Enumerationswert aus TarEntryFormat:

TarFile.CreateFromDirectory("d:\Export", @"t:\archiv.gnu.rar",
  includeBaseDirectory: true, TarEntryFormat.Gnu);

Ein wesentlicher Unterschied zwischen den TAR-Formaten sind die maximalen Dateilängen: V7 erlaubt nur maximal 100 Zeichen für den Namen eines Eintrags. Bei USTAR sind es 256 Zeichen. Bei GNU und PAX ist die Länge von Dateinamen unbegrenzt. Bei USTAR ist die Dateigröße auf 8 GB beschränkt.

MinBy() und MaxBy() für Datenbankzugriffe

Die LINQ-Operatoren MinBy() und MaxBy() hat Microsoft bereits in .NET 6.0 eingeführt. Anders als die schon seit der ersten LINQ-Version in .NET Framework 3.5 verfügbaren Operatoren Min() und Max() liefern MinBy() und MaxBy() nicht nur den Minimal- bzw. Maximalwert selbst, sondern das ganze umgebende Objekt mit. Bisher waren MinBy() und MaxBy() nur in LINQ-to-Objects einsetzbar. Das ändert sich nun in .NET 11.0: Auch Entity Framework Core kann diese LINQ-Operatoren in SQL-Befehle umsetzen, siehe Listing 3.

var ctx = new DA.WWWings.WwwingsV1EnContext();

// Min vs. MinBy()
var wenigsteFreiePlaetze = ctx.Flights.Min(x => x.FreeSeats);
CUI.H1("Der Flug mit den wenigsten Plätzen hat " + wenigsteFreiePlaetze + " freie Plätze");
var flugMitDenWenigstenFreienPlaetzen = ctx.Flights.MinBy(x => x.FreeSeats);
Console.WriteLine(flugMitDenWenigstenFreienPlaetzen);

// Max() vs. MaxBy()
var meisteFreiePlaetze = ctx.Flights.Max(x => x.FreeSeats);
CUI.H1("Der Flug mit den meisten freien Plätzen hat " + meisteFreiePlaetze + " freie Plätze");
var flugMitDenMeistenFreienPlaetzen = ctx.Flights.MaxBy(x => x.FreeSeats);
Console.WriteLine(flugMitDenMeistenFreienPlaetzen);

Listing 3: MinBy() und MaxBy() in Entity Framework Core 11.0

Während der LINQ-Operator Min() die MIN()-Funktion in SQL nutzt

SELECT MIN([f].[FreeSeats])
      FROM [Operation].[Flight] AS [f]

erstellt MinBy() eine sortierte Datensatzmenge und liefert den obersten Datensatz mit TOP(1) zurück:

SELECT TOP(1) [f].[FlightNo], [f].[Airline], [f].[Departure], [f].[Destination], 
[f].[FlightDate], [f].[FreeSeats], [f].[Memo], [f].[NonSmokingFlight], [f].[Pilot_PersonID], 
[f].[Seats], [f].[Timestamp]
      FROM [Operation].[Flight] AS [f]
      ORDER BY [f].[FreeSeats]

Datenübergabe zwischen HTTP-Anfragen mit TempData

Die in .NET 8.0 eingeführte Blazor-Variante Static Server-Side Rendering (SSR) ist den vorherigen Ansätzen für die Erstellung von Multi-Page-Apps im modernen .NET (ASP.NET Core Model-View-Controller (MVC) und ASP.NET Core Razor Pages) überlegen, hinsichtlich des Komponentenmodells, der Razor-Syntax und des partiellen Seitenaustauschs. Allerdings gab es bis dato auch einige Funktionen in MVC und Razor Pages, die Blazor SSR nicht beherrschte. Dazu gehören das Caching von Seitenteilen, erweiterbare Bedingungen für Routenparameter und die Datenübergabe zwischen HTTP-Anfragen mit dem TempData-Objekt (siehe GitHub-Issue). Letzteres ist nun in .NET 11.0 Preview 2 möglich. Die Datenspeicherung erfolgt wahlweise als Cookie (CookieTempDataProvider) oder im Session Storage (SessionStorageTempDataProvider) des Webbrowsers.

Anders als bei MVC und Razor Pages ist TempData aber keine Property der Basisklasse, sondern muss als Cascading Parameter explizit konsumiert werden, siehe Listing 5. Dabei ist zu beachten, dass TempData wie bei MVC und Razor Pages nur Zeichenketten abspeichern kann, das heißt, komplexe Objekte müssen Entwicklerinnen und Entwickler selbst serialisieren, siehe Listing 4.

@page "/Registration"
@using BlazorSSRSamples
@using Newtonsoft.Json
@inject NavigationManager NavigationManager
 

 
 

  Ihr Name: 
   reg.Name)" />
 
 

  Ihre E-Mail-Adresse: 
   reg.EMail)" />
 
 Bestellen

 
@code {
 [SupplyParameterFromForm]
 RegistrationData reg { get; set; } = new();
 
 [CascadingParameter]
 public ITempData? TempData { get; set; }
 
 private string? message;
 
 private void HandleSubmit()
 {
  TempData!["Message"] = "Registrierung  erfolgreich übermittelt!";
  TempData!["Reg"] = System.Text.Json.JsonSerializer.Serialize(reg); // speichert nur Strings
  TempData!["RegInfo"] = DateTime.Now.ToString(); 
  NavigationManager.NavigateTo("RegistrationConfirm", new NavigationOptions() { ForceLoad = true });
 }
}

Listing 4: TempData in Blazor-SSR-Seite befüllen

@page "/RegistrationConfirm"
@using BlazorSSRSamples
@inject NavigationManager NavigationManager
 
@message
 
@if (reg.HasValue)
{
 
Ihre Daten:
@reg.Name
@reg.EMail
}
 
@if (regInfo.HasValue)
{
 
Registriert am:
@regInfo
}
 
@code {
 [CascadingParameter]
 public ITempData? TempData { get; set; }
 
 private string? message;
 private string? regInfo;
 BlazorSSRSamples.RegistrationData? reg { get; set; } = new();
 
 protected override void OnInitialized()
 {
  message = TempData?.Get("Message") as string ?? "No message";
  reg = System.Text.Json.JsonSerializer.Deserialize(TempData?.Get("Reg").ToString());
  regInfo = TempData?.Get("regInfo") as string;
 }
}

Listing 5: TempData in Blazor-SSR-Seite auslesen

Geplant für kommende Preview-Versionen ist, dass das Auslesen von Daten aus TempData über eine Annotation [SupplyParameterFromTempData], mit der man eine Property annotieren kann, vereinfacht wird, siehe Pull Request.

Weitere Neuerungen in .NET 11.0 Preview 2

Laut den Release Notes von .NET 11.0 Preview 2 gibt es folgende weitere Neuerungen:

• Der in ASP.NET integrierte Webserver Kestrel lehnt nun ungültige Anfragen schneller ab, weil Microsoft intern auf das Auslösen einer BadHttpRequestException verzichtet und stattdessen eine Struktur zurückgibt. Das verbessert laut Microsoft den Durchsatz um 20 bis 40 Prozent bei Angriffen via Port Scanning oder mit fehlerhaften Anfragen.
• .NET-Core-basierte WebAPIs unterstützen jetzt die Open API Specification in der Version 3.2. In .NET 10.0 war es Version 3.1.1.
• Für die Erstellung von Web-Worker-Projekten gibt es nun eine eigene Projektvorlage „.NET Web Worker“ in Visual Studio beziehungsweise an der Kommandozeile: dotnet new webworker. Dabei entsteht eine DLL, die in Blazor-WebAssembly-basierten Anwendungen genutzt werden kann.
• Bei Entity Framework Core kann man nun für SQL Server die dort eingebaute Volltextsuche via Fluent API konfigurieren:

modelBuilder.Entity(b =>
{
 b.HasFullTextIndex(e => new { e.Titel, e.Text})
     .HasKeyIndex("PK_FullTextEntity")
     .HasLanguage("Titel", "German")
     .HasLanguage("Text", "German");
});

• Ebenso steht in Entity Framework Core die Vektorsuche mit der SQL-Server-2025-Funktion VECTOR_SEARCH() via LINQ-Operation VectorSearch() zur Verfügung:

var sqlVector = new SqlVector(EmbeddingsUtil.Get(suchBegriff));
  var q =  ctx.TexteSet.VectorSearch>(b => b.Embedding, sqlVector, "cosine", topN: 5);

Dabei ist zu beachten, dass man VECTOR_SEARCH() auch in der stabilen Version von SQL Server 2025 erst via SQL-Befehl aktivieren muss

ALTER DATABASE SCOPED CONFIGURATION SET PREVIEW_FEATURES ON

und in .NET die Warnung „EP9105“ deaktivieren muss:

#pragma warning disable EF9105 // Type is for evaluation purposes only and is subject to change or removal in future updates. Suppress this diagnostic to proceed.

• In .NET MAUI wurde das Steuerelement
verbessert. Die Syntax ist nun kompakter.

Außerdem kann man Elemente auf der Karte (Polygon, Polyline, Circle) nun per IsVisible und ZIndex steuern. Zudem gibt es Click()-Ereignisse auf diesen Elementen.

• Auch .NET-MAUI-Anwendungen für Apple-Betriebssysteme (iOS, tvOS und Mac Catalyst) können nun auf der .NET Core Runtime statt Mono laufen. Seit .NET 10.0 war dies experimentell für MAUI-Anwendungen auf Android möglich. Auch die Apple-Implementierung der .NET Core Runtime gilt aber als experimentell. Die Anwendungen werden aktuell durch die Umstellung aber größer und das Debugging ist noch eingeschränkt.
• Die Größe der Container Images von .NET SDK 11.0 Preview 2 ist gegenüber .NET 11.0 Preview 1 um 41 bis 44 MB (bis zu 17 Prozent) verkleinert, da Microsoft nun Hard Links für doppelte Dateien verwendet. Das gilt auch für die Installer für Linux und macOS.

Sonst nichts Neues

Laut den Release Notes von .NET 11.0 Preview 2 gibt es in dieser Vorschauversion keine Neuerungen für die Sprachsyntax von Visual Basic und C# sowie das GUI-Framework Windows Forms. Bei der Windows Presentation Foundation (WPF) gibt es nur einen Bugfix.

Ausblick

.NET 11.0 soll im November 2026 erscheinen und einen Standard-Term Support von zwei Jahren erhalten. Bis dahin können Entwicklerinnen und Entwickler mit fünf weiteren Preview-Versionen von April bis August sowie jeweils einer Release-Candidate-Version im September und Oktober rechnen. heise developer wird jeweils berichten.

(mai)

Das quelloffene JavaScript-Framework Astro hat Version 6.0 erreicht. Darin sind zahlreiche Neuerungen enthalten, unter anderem eine Überarbeitung des Entwicklungsservers und eine integrierte Fonts-API. Die bestehenden Features Live Content Collections und Content-Security-Policy-API sind nun stabil. Als experimentelle Funktion steht ein neuer Rust-Compiler als Nachfolger des Go-basierten Compilers in den Startlöchern.

Rust-Compiler: vom Experiment zum geplanten Standard

Wie das Astro-Team ausführt, begann der neue Rust-Compiler zunächst nur als KI-Experiment. Aber da er sich als schneller und teils sogar zuverlässiger erwiesen hat als der Go-Compiler, soll er in Zukunft zum Standard werden. Interessierte können ihn bereits ausprobieren, indem sie das rustCompiler-Flag aktivieren und das entsprechende Package installieren (npm install @astrojs/compiler-rs). Auch an weiterem Rust-basierten Tooling arbeiten die Astro-Entwickler nach eigenen Angaben bereits.

Neue Fonts-API und stabile Funktionen

In Astro 6.0 finden Entwickler eine integrierte Fonts-API vor. Damit lassen sich Fonts mithilfe lokaler Dateien oder Anbietern wie Google oder Fontsource konfigurieren. Anschließend übernimmt Astro weitere Arbeiten wie das Herunterladen und Caching für Selbst-Hosting oder das Generieren optimierter Fallbacks.

Bereits seit Astro 2.0 sind Content Collections mit an Bord. Damit können Entwicklerinnen und Entwickler Sets an strukturierten Inhalten in Astro-Projekten verwalten, beispielsweise Blogeinträge oder Produktbeschreibungen. Astro kann hierfür mit lokal gespeicherten Daten in den Formaten Markdown, MDX, Markdoc, YAML, TOML oder JSON umgehen. Bisher erforderten Content Collections einen Rebuild, wenn sich Inhalte änderten.

Das gehört dank der nun stabilen Live Content Collections der Vergangenheit an: Sie erfassen den Content zur Request-Zeit und erlauben eine unverzügliche Aktualisierung von Inhalten ohne Rebuild. Astro-Developer können eine Live-Quelle in der Datei src/live.config.ts mittels defineLiveCollection() festlegen. Parallel zu den Live Content Collections lassen sich im gleichen Projekt auch die klassischen Content Collections nutzen.

Ebenfalls stabil ist ein sicherheitsrelevantes Feature, die Content-Security-Policy-API. Laut dem Astro-Team ist Astro eines der ersten JavaScript-Metaframeworks, die integrierten Support für Content Security Policy (CSP) für statische und dynamische Seiten sowohl in Server- als auch Serverless-Umgebungen bieten.

Cloudflare-Fokus: Update für astro dev

Astros Entwicklungsserver astro dev wurde überarbeitet, um mit Runtimes abseits von Node.js, wie Cloudflares workerd-Laufzeit, zusammenzuspielen. Dazu kommt Vites neue Environment API zum Einsatz. Da der Dev-Server ursprünglich auf Node.js ausgelegt war, konnten Developer unter Verwendung anderer Runtimes wie Cloudflare Workers, Bun oder Deno die eigentliche Produktionslaufzeit bisher nicht während der Entwicklung einsetzen. Nun können sie während der Entwicklung eine benutzerdefinierte Laufzeitumgebung auswählen. Dev-Server und Build-Pipeline verwenden in Astro 6.0 die gleichen Codepfade.

Diese Überarbeitung entspringt der offiziellen Partnerschaft mit dem Unternehmen Cloudflare, das im Herbst letzten Jahres Astro mit 150.000 US-Dollar unterstützte. Im Januar 2026 wurde Astro von Cloudflare übernommen, soll jedoch Open Source bleiben.

Weitere Details zu den Neuerungen in Astro 6.0 lassen sich dem Astro-Blog entnehmen.

(mai)

Nach Protesten der Open-Source-Community hat das Unternehmen MariaDB plc die geplante Entfernung der Galera-Clustering-Technologie aus dem Community-Server von MariaDB zurückgenommen. Die Open-Source-Hochverfügbarkeit bleibt damit in Version 12.3 enthalten, Alternativen dazu hätte es nur in den kommerziellen Angeboten gegeben.

Wie Max Mether, Vice President, Server Product Management der Firma, in einem Blogbeitrag erklärte, ist das Feedback der Community „ein wichtiger Bestandteil von MariaDB, und kürzlich habt ihr euch zur Aufnahme von Galera Cluster in die Version 12.3 geäußert“. Nach sorgfältiger Prüfung habe man daraufhin entschieden, die Galera-Cluster-Bibliotheken in unveränderter Form mit dem Community-Server weiterhin auszuliefern.

Galera-Dependencies aus dem MariaDB-Server ohne Vorwarnung entfernt

Anfang Februar 2026 war bekannt geworden, dass MariaDB offenbar plante, die unter GPLv2 lizenzierte Galera-Technik aus künftigen Versionen des Community-Servers zu entfernen. Federico Razzoli, Gründer des Datenbankdienstleisters Vettabase – einem Silber-Sponsor der MariaDB Foundation –, hatte unter Berufung auf einschlägige Diskussionen bei GitHub auf LinkedIn öffentlich dokumentiert, dass Galera-Abhängigkeiten bereits ohne Commit-Meldungen oder Aufgabenbeschreibungen aus den Binärdateien entfernt worden waren. Die Kritik verbreitete sich schnell in der Community. Besonders einflussreich für das Umdenken des Unternehmens waren laut MariaDB die Rückmeldungen von Frédéric (lefred) Descamps (Community Advocate der MariaDB Foundation) und René Bonvanie (Board Member der MariaDB Foundation).

Galera ermöglicht synchrone Multi-Master-Replikation für MariaDB-Datenbanken. Dabei fungieren mehrere Server als gleichberechtigte Knoten in einem Cluster, wobei jeder Knoten Schreibvorgänge akzeptieren und automatisch an andere Knoten replizieren kann. Die Technik gilt als essenziell für hochverfügbare Produktionsumgebungen. Nachdem MariaDB die Galera-Technik von Codership bereits erstmals 2013 integriert hatte, entschlossen sich die Verantwortlichen im Mai 2025, das Entwicklerunternehmen Codership Oy komplett zu übernehmen.

Foundation bestätigt Dialog

Die MariaDB Foundation bestätigte in einem eigenen Blogbeitrag, dass es einen offenen Dialog zwischen Foundation und Unternehmen gegeben habe. Kaj Arnö, Executive Chairman der Foundation, charakterisierte die Zusammenarbeit als von „gegenseitigem Respekt und einem gemeinsamen langfristigen Interesse am MariaDB-Ökosystem“ geprägt. Unklar bleibt jedoch, wie die weitere Zukunft für die Galera-Entwicklung als Teil von MariaDB aussehen kann und ob die Community Edition weiterhin Galera-Updates erhalten wird.

Denn wie Max Mether in seinem Blogbeitrag auch unmissverständlich deutlich macht, verfolgt das Unternehmen mehrere Wege, Anwenderinnen und Anwendern Funktionen für die Hochverfügbarkeit bereitzustellen. Neben Galera im Community-Server sind dies vor allem der auf Galera aufbauende MariaDB Enterprise Cluster sowie der als Tech Preview verfügbare MariaDB Advanced Cluster, der das Raft-Protokoll verwendet, um verbesserte Skalierbarkeit und Datenkonsistenz auch über geografische Regionen hinweg zu gewährleisten. Beide Versionen stehen ausschließlich als kommerzielle Angebote von MariaDB zur Verfügung.

Während sich die MariaDB Foundation vor diesem Hintergrund weiter für eine vertrauensvolle Nutzung von Galera durch die Community einsetze, stellt die offizielle Erklärung von CEO Anna Widenius im Blog der Foundation aber auch klar, dass Entscheidungen über die zukünftige Entwicklung und Zuweisung von technischen Ressourcen allein in der Verantwortung von MariaDB plc liegen. Als Eigentümer von Galera kontrolliere das Unternehmen sowohl dessen Roadmap und die Namensgebung als auch die dahinterstehenden Entwicklungsressourcen.

Vertrauensfrage bleibt

Die Affäre offenbart einmal mehr strukturelle Spannungen zwischen den kommerziellen Interessen von MariaDB plc und den Open-Source-Idealen der Foundation. Razzoli forderte öffentlich, MariaDB plc solle auf seiner Website zusichern, dass die Open-Source-Software offen bleibe. Die Sorge: Das Unternehmen könnte Funktionen aus der freien Version entfernen, um Nutzer zu proprietären Angeboten zu bewegen.

MariaDB hat in den vergangenen Jahren turbulente Zeiten hinter sich. Nach einem SPAC-gestützten Börsengang Ende 2022 folgten Entlassungen, Warnungen zur Unternehmensfortführung und ein Kursverfall. Im Dezember 2023 gliederte das Unternehmen seinen DBaaS-Dienst SkySQL aus und wurde selbst im September 2024 privatisiert und holte SkySQL Mitte 2025 wieder zurück. Kaj Arnö hatte nach der Privatisierung erklärt, dass „Vernunft“ in die Beziehung zwischen Community und Unternehmen zurückgekehrt sei. Die Galera-Kontroverse zeigt jedoch, dass das Vertrauen weiterhin fragil ist – und dass die Community bereit ist, sich lautstark für den Erhalt offener Technologien einzusetzen.

(map)