Eine Reihe von Open-Source-Projekten, die weit verbreitet und tief in Produktionssystemen eingebettet sind, befinden sich in einer Grauzone zwischen aktiver Entwicklung und nachlassendem Engagement – bis hin zur vollständigen Aufgabe. Die Anwendungen arbeiten stabil, benötigen aber für den weiterhin zuverlässigen Betrieb in Produktion zumindest eine minimale Wartung für Sicherheitspatches und Dependency-Updates. Ziehen sich jedoch die Maintainer aus diesen Projekten zurück, können sie zu einem Sicherheitsrisiko werden. An dieser Stelle setzt das neue Programm „EmeritOSS“ von Chainguard an.

Das Unternehmen Chainguard, das unter anderem gehärtete Container Images bereitstellt, will laut Ankündigung mit EmeritOSS betroffenen Open-Source-Projekten eine „stabile und verlässliche Heimat“ bieten. Vordringliches Ziel sei nicht die Weiterentwicklung dieser Projekte, sondern die Stärkung der Nachhaltigkeit von Open-Source-Software insgesamt.

Die xz-utils-Backdoor als warnendes Beispiel

Als eine Motivation für das Programm führt Chainguard beispielhaft den Social-Engineering-Angriff auf das Free/Libre-Open-Source-Software-Projekt (FLOSS) xz-utils an. Bei diesem 2024 bekannt gewordenen Vorfall hatte sich der ursprüngliche Maintainer nach langjährigem Engagement aus dem Projekt zurückziehen wollen. Ein neuer Contributor konnte schrittweise dessen Vertrauen gewinnen – und versuchte dann, eine Backdoor einzuschleusen, die unzählige Systeme hätte kompromittieren können.

Unternehmen, die solche ausgereiften Projekte nutzen und von deren Sicherheit und Zuverlässigkeit abhängen, soll EmeritOSS nun ein strukturiertes Übergangsmodell bereitstellen. Der Support-Umfang ist jedoch bewusst begrenzt. Das Programm sieht verschiedene Unterstützungsstufen je nach Community-Erwartungen und Projektlebenszyklus vor – darunter öffentliche Forks zum Erhalten des Codezugangs, Dependency-Updates zum Beheben von Schwachstellen, neue Releases mit den genannten Updates, klare Dokumentation zum Support-Umfang sowie bei Bedarf Container-Images und APK-Pakete.

Stabilität statt neuer Features

Auf das Entwickeln neuer Features oder proaktives Engagement mit Community-Issues und Pull-Requests verzichtet das Programm laut Chainguard ausdrücklich. Die geforkten, auf Stabilität fokussierten Quellcode-Versionen sollen frei auf GitHub verfügbar bleiben. Organisationen, die ein sicheres, kontinuierlich gewartetes Container-Image oder APK bevorzugen, sollten auf kommerzielle Distribution ausweichen. Chainguard wolle mit den Forks lediglich die Kontinuität der Projekte sichern, nicht in Wettbewerb zu kommerziellen Anbietern treten.

Kaniko, Kubeapps und ingress-nginx als erste Projekte

Den Start des EmeritOSS-Programms markierte die Aufnahme des Kaniko-Projekts, dessen Archivierung Google im Juni 2025 angekündigt hatte. Kaniko ermöglicht das Erstellen von Docker-Images innerhalb von Kubernetes-Clustern ohne privilegierte Container und ist vor allem in regulierten Branchen wie dem Finanzwesen verbreitet. Chainguard hat nach eigenen Angaben die Wartung eines Forks übernommen und bereits CVE-Fixes, Dependency-Updates und gepflegte Images bereitgestellt.

Neu hinzugekommen sind zuletzt die Projekte Kubeapps und ingress-nginx. Nachdem die Kubernetes Community angekündigt hat, ingress-nginx im März 2026 auslaufen zu lassen und künftig standardmäßig auf die Gateway API für das Networking in Kubernetes zu bauen, stehen Nutzer vor der Herausforderung, auf andere Ingress-Controller auszuweichen oder eine Migration auf die Gateway API einzuleiten. Der Fork im Rahmen des EmeritOSS-Programms verschafft Betroffenen nun mehr Zeit beim Evaluieren.

Wer darüber hinaus Vorschläge für weitere Open-Source-Projekte hat, die in das Programm aufgenommen werden sollten, kann diese dem EmeritOSS-Team bei Chainguard gezielt unterbreiten.

(map)

Ab Januar 2026 führt GitHub neue Preise für die automatisierten Aufgaben der Actions in privaten Repositories ein. Für Runner, auf denen die Actions laufen, gibt es eine Preisreduktion um circa vierzig Prozent, wenn GitHub sie hostet. Selbstgehostete Runner kosten ab jetzt hingegen erstmalig eine Gebühr von 0,2 US-Cent pro Minute.

Actions in öffentlichen Repositories bleiben kostenlos und auch für Enterprise Server ändert sich nichts. GitHub begründet die Änderung mit einer faireren Verteilung der Infrastrukturkosten, weil bislang Hostingkunden die Selbsthoster mitfinanzierten. GitHub hat ausgerechnet, dass sich für 96 Prozent der Kunden nichts ändern wird, vom Rest werden 85 Prozent eine Preisreduktion auf der Rechnung finden. Alle anderen müssen mit einer Erhöhung um 13 Dollar im Median pro Monat rechnen. Über einen Preiskalkulator online lassen sich die Kosten planen.

Im August hatte GitHub eine neue Infrastruktur für die Actions eingeführt, auf der 71 Millionen Jobs am Tag laufen. Die Actions automatisieren Jobs für die Softwareproduktion wie Tests und Builds. Diese laufen auf Runnern, also virtuellen OS-Umgebungen.

(who)

Beim Blick auf Large Language Models vergeht fast keine Woche ohne neue Modelle, die sich in bestimmten Nischen positionieren oder neue Techniken ausprobieren. Das hat uns dazu bewogen, regelmäßig über diese Updates zu berichten. Bei größeren Neuerungen werden wir den geplanten Zweiwochentakt unterbrechen und neue Modelle direkt untersuchen.

Dieses erste Update fällt etwas umfangreicher aus. Aktuelle Modelle finden sich bei Hugging Face oder durch konsequentes Mitlesen im sehr aktiven LocalLLaMa-Subreddit. Gerne nehmen wir auch Vorschläge über Modelle entgegen, die wir uns näher anschauen sollen.

Kleine Spezialmodelle

Der Trend muss nicht zu immer größeren Modellen gehen. Bei Hugging Face finden sich einige Modelle, die sehr beliebt, aber nicht besonders groß sind.

Ganz vorn steht hier VibeThinker von WeiboAI. Das Reasoning-Modell ist vor allem darauf ausgelegt, mathematische Fragen zu beantworten oder Programmcode zu erzeugen. Für diese Aufgaben ist es sehr gut geeignet. Laut den Benchmarks spielt es in der gleichen Liga wie das (ältere) Gemini 2.5 Flash und überholt teilweise sogar DeepSeek R1.

Erstaunlich ist, dass das Modell mit nur 1,5 Milliarden Parametern auskommt. Die anderen genannten Modelle haben 400-mal mehr Gewichte zu verarbeiten und sind dadurch entsprechend langsam. Die Größe spielt besonders bei Coding-Modellen eine entscheidende Rolle: Erstens will man die Modelle möglicherweise auch lokal ausführen, nachdem man sie potenziell feingetunt hat, und zweitens generieren diese Modelle sehr viele Token – je schneller das geht, desto kürzer ist die Wartezeit auf den generierten Code.

Mit vier Milliarden Parametern etwas größer, aber noch spezialisierter ist AesCoder, das mithilfe von GRPO (Group Relative Policy Optimization) auf die Erledigung von Web-Designaufgaben spezialisiert ist.

Konkurrenzfähige offene Modelle von Olmo

Auch wenn man häufig von Open-Source-Modellen spricht, sind meist lediglich die Gewichte der Modelle frei verfügbar. Nur wenige Anbieter veröffentlichen die Trainingsdaten und die Algorithmen, mit denen sie die Modelle trainiert haben. Neben Hugging Face mit SmolLM gibt es offene Trainingsdaten für das Modell Apertus aus der Schweiz und vor allem für die Olmo-Modelle vom Allen AI Institute. Letzteres braucht sich aufgrund der Investitionen durch Microsoft-Mitgründer Paul Allen keine großen Gedanken um die Finanzierung zu machen.

Besonders die jüngsten Olmo-3-Modelle integrieren viele innovative Techniken und machen damit einen gewaltigen Sprung nach vorn. Sie stehen in zwei Größen mit 7 und 32 Milliarden Parametern zur Verfügung. Das größere Modell gibt es in einer Reasoning-Variante, das kleinere zusätzlich noch als Instruction-Following-Modell ohne Reasoning. Für diejenigen, die die Modelle feintunen möchten, stellt Olmo anders als die meisten anderen Anbieter die Basismodelle zur Verfügung.

Im Vergleich zu anderen Modellen wie Qwen3 hat Olmo 3 deutlich weniger Token im Training erhalten: 5,9 Billionen aus dem Datensatz Dolma 3 Mix. Das macht sich leider in der Modellperformance bemerkbar, die nach ersten Tests nicht mit den Qwen3-Modellen in der gleichen Größenordnung mithalten kann. Die Strawberry-Challenge mit der Frage nach der Anzahl der „e“ in „Erdbeere“ (oder „r“ in „strawberry“) beantwortet das Modell konsequent falsch. Auch die deutschen Sprachfähigkeiten der kleineren Modelle sind nicht besonders gut ausgeprägt:

Der Artikel zu Olmo 3 enthält viele Details über die Architektur und das Training des Modells. Das gibt interessante Einblicke in den Trainingsprozess. Insbesondere das Post-Training ist sehr anspruchsvoll, weil Olmo dabei mit unterschiedlichen Datensets arbeitet, um die Qualität zu verbessern. Viele Innovationen gibt es beim Reinforcement Learning des Reasoning-Modells (bei Olmo „Thinking“ genannt).

Einige der GRPO-Optimierungen sind von anderen Modellen bekannt, kommen aber in dieser Kombination erstmals bei Olmo zum Einsatz. Das Modell setzt außerdem die weiterentwickelte Version des Verfahrens Reinforcement Learning with Verifiable Rewards (RLVR) ein, mit dem auch das neue Training von DeepSeek arbeitet. Mit RLVR kann man automatisiert überprüfen, ob Sprachmodelle die richtigen Ergebnisse vorhersagen. Die Besonderheit der weiterentwickelten Version ist, dass man damit Trainingsdaten automatisiert erzeugen kann – in Grenzen und bestimmten fachlichen Domänen.