JavaScript: Node.js 5.7 und "gesundes" Open Source

Zwei Wochen nach dem letzten, auf Sicherheit konzentrierten Update, haben die Node.js-Entwickler nun Version 5.7 ihres Projekts veröffentlicht. Neben kleineren Korrekturen und Ergänzungen, etwa im Zusammenhang mit ESLint, konnten sie unter anderem die Performance der Plattform steigern und Überarbeitungen am Buffer vornehmen. So lässt sich Letzterem etwa ein encoding-Argument mitgeben und Buffer#indexOf() benötigt keinen byteOffset, sollte der Nutzer eine encoding-Angabe machen wollen.

Darüber hinaus sind net und http nun mit einer booleschen Variable listening ausgestattet, um anzeigen zu können, ob der Server auf Verbindungen horcht. Um mit dem Code-Cache der JavaScript Engine V8 interagieren zu können, steht vm.Script() mit den Optionen produceCachedData und cacheData zur Verfügung. Erstellt man ein entsprechendes Objekt und setzt produceCachedData gleich true, entsteht ein Buffer mit V8s zwischengespeicherten Daten. Die Plattform legt sie im Anschluss in der cachedData-Eigenschaft des zurückgelieferten Objekts ab.

Weitere Neuerungen umfassen, dass spawn() und spawnSync() in child_process nun eine shell-Option zum Ausführen von Befehlen in einer Shell enthalten und socket.send() in dgram Arrays aus Buffers und Strings als erstes Argument annimmt. Nähere Änderungen lassen sich dem Changelog entnehmen.

Zu gesundem Open Source beitragen

Passend zur Veröffentlichung hat sich auch Mikeal Rogers, der zu io.js-Zeiten als Sprecher des Forks an die Öffentlichkeit trat, wieder zu Wort gemeldet. In seinem Artikel "Healthy Open Source" informiert er über die grundlegenden Regeln zur Projektmitarbeit, wie sie die Node.js-Foundation derzeit befolgt. Sie orientieren sich an den Werten Transparenz, Mitbestimmung und Wirksamkeit und sollen auch als Richtlinien für Projekte wie Express gelten, die ein neues Zuhause unter dem Dach der Stiftung finden.

Die Regeln sind im Repository des Technical Steering Committee der Foundation festgehalten und dienen dazu, neue Beiträge zu motivieren, Beitragende dazu zu bewegen, sich über längere Zeit einzubringen, unnötige Bürokratie und Prozesse zu vermeiden und transparente Entscheidungsprozesse zu etablieren. Die Gemeinschaft wird zu dem Zweck in Nutzer, Mitwirkende, Committer, also diejenigen, die Schreiberechte im Repository haben, und das Technical Committee eingeteilt. Dabei ist es wichtig, dass die Gruppen proportional zueinander wachsen. Ist das nicht der Fall, kommt es wie in den frühen Zeiten des Projekts zu einem Ungleichgewicht, was seinen Fortschritt gefährdet oder sich mit der Zeit in der Sicherheit beziehungsweise Stabilität niederschlägt.

Um die Hürde für die Beteiligung am Projekt gering zu halten, verweisen die Regeln nicht zuerst darauf, die Dokumentation zu lesen, sondern Probleme aller Art (Sicherheitslücken ausgeschlossen) in Issues zu loggen. Mitwirkende, also jeder, der schon einmal etwas zum Projekt beigetragen hat, können, falls der Fehler beim Nutzer liegt, dann über den richtigen Gebrauch aufklären. Sollte es sich tatsächlich um eine Fehlfunktion handeln, widmen sich dann Committer dem Issue, indem sie an ein anderes Repository verweisen, sollte das Problem außerhalb ihrer Zuständigkeit liegen, bei Unklarheiten nachfragen und entsprechende Metadaten hinzufügen. Bei jeglicher Kommunikation ist dabei der Code of Conduct des Projekts zu beachten.

Mitarbeit sichern

Alle Änderungen sind über einen Pull Request (PR) einzubringen, sodass nicht der Eindruck entsteht, dass etwa die Änderungen der Committer bevorzugt behandelt werden, weil sie bereits im Projekt etabliert sind. PRs müssen einen Review-Prozess durchlaufen. Sollte der Beitrag so kontrovers sein, dass sich die Committer nicht darüber einigen können, ob und wie er in das Projekt einzubringen ist, wird er an das Technical Committee weitergeleitet.

Um genug Committer im Projekt zu haben, sehen die Regeln vor, jeden, der einen nicht trivialen Beitrag geleistet hat, entsprechend schnell Schreiberechte zuzugestehen. Zwar gäbe es häufig Vorbehalte gegenüber neuen Mitgliedern, die nicht alle Aspekte eines Projekts komplett verstünden, allerdings vertraue man darauf, dass die Committer sich ihrer Grenzen bewusst seien und bereit, bei Entscheidungen auf diejenigen zu verweisen, die entsprechende Kompetenz besäßen. (jul)