An "open governance" fork of Node.js

In early December, a group of key Node.js developers announced the creation of a fork that they call io.js. The new project insists that its effort will remain compatible with Node.js and that the principal reasons for starting the new project are issues of governance and management style. Nevertheless, part of the project-management style adopted by the io.js team involves faster feature development and releases—so it certainly remains to be seen whether the new codebase diverges in a significant way, much less how the user community will respond to the competing projects.

For those unfamiliar with it, Node.js is a web application framework that emphasizes I/O performance between the client (the browser) and the server. It uses the V8 JavaScript engine developed by Google for Chrome/Chromium. Since its inception, Node.js has been maintained by the cloud-computing vendor Joyent, who employed Node.js's creator Ryan Dahl as well as several other core team members.

History

In recent years, however, several leading Node.js developers not employed by Joyent began to express dissatisfaction with the manner in which the company managed the project. In mid-2014, some of those developers launched Node Forward, which is described as "a broad community effort" to improve Node.js and projects that depend on it.

On Node Forward's issue tracker, participants aired a number of specific complaints about Joyent's management. They include the long delay between versions 0.11 and 0.12 (over one year and counting), the lag between a new release of V8 and that release being rolled into Node.js, and the length of time that the project takes to respond to pull requests.

There were, of course, quite a few technical issues raised by individual Node.js users and developers as well. But, regarding the project-management concerns, perhaps the fundamental issue underneath all of them was the perception that Joyent's project team was overruling the senior community developers. Those community members wanted faster releases, for example, but the company wanted to take its time. So Node.js takes its time between releases, even if more than half of the core team disagrees.

In October, after the Node Forward group went public with its grievances, Joyent responded by forming a Node Advisory Board designed to give community members a way to "advise Joyent and the Node.js project core committers team leadership" about Node.js development—but not, notably, to serve in any formal leadership or governance role. That was not, evidently, a sufficient solution to the key Node Forward players, however: on December 2 they announced the io.js fork. Video recordings for several of the Node Forward meetings have been released on YouTube, as have text minutes—although, so far, the meeting that precipitated the official fork has not been released.

Governance and openness

Officially, the io.js GitHub repository calls the new project a "spork," not a fork. The distinction, unfortunately, is not elaborated upon, but perhaps it comes down to the io.js team's insistence that their project differs from Node.js only in terms of governance. As the io.js repository's README file puts it:

(NPM is the Node.js package manager, which is developed independently of Node.js and Joyent.)

The new project's governance model is explained in detail in a section of the CONTRIBUTING file. It starts with a technical committee (TC) that has final authority over technical direction, the governance process, all policies, and code-of-conduct guidelines for participants. The TC is said to hold weekly meetings on Google Hangouts, and will attempt to resolve all questions by unanimous consensus:

The initial TC members are Ben Noordhuis, Bert Belder, Fedor Indutny, Isaac Schlueter, Nathan Rajlich, and Trevor Norris. Indutny, Rajlich, and Norris were members of the Node.js core team prior to the fork, while Belder, Noordhuis, Schlueter were listed as core team alumni. In a blog post, Schlueter said that TJ Fontaine, the current Node.js project lead at Joyent, was invited to participate, but declined.

Development

Schlueter's post is also interesting reading because it asserts that the io.js project is a continuation of the Node Forward effort, which was "created with the express intent of merging changes with the joyent/node repository" and is not intended to be a competing project. The name change, he said, is solely an effort to avoid stepping on Joyent's trademarks.

That is, no doubt, a comforting outcome for Node.js users. Having the two projects compete and diverge on technical matters rather than merely adopt different release schedules would fracture the Node.js ecosystem and force downstream development projects into making a difficult choice. On the other hand, even when projects diverge for non-technical reasons, it is still easy for fissures to emerge between the feature sets and APIs.

The io.js TC says it has an initial release planned for January 13. That release will be based on the Node.js 0.12 development branch, but will be tagged 1.0-alpha1, leading up to an eventual io.js 1.0 release. The goal moving forward is to make new releases every week, with continuous integration keeping the codebase stable in between releases, and to adopt new V8 releases as quickly as possible.

A few commenters on the initial-release plan expressed concerns about leaping immediately into a rapid-release schedule but, for the most part, the proposal seemed to have the support of the io.js community. Nevertheless, it is difficult not to observe ambivalence on the part of the new project when it comes to maintaining compatibility with Node.js. There is an io.js roadmap discussion taking place at the GitHub site, some points of which might result in compatibility troubles—from merging in external projects to building io.js as a shared library rather than as an executable.

The way forward

Which is not to say that breaking compatibility with Node.js would necessarily be a bad thing. As Wesley Smith wrote on his blog, it is entirely possible for both projects to move forward and build active communities—just as it is possible for one or the other to achieve dominance and the rival to fizzle out.

The io.js project does have some work ahead of it, though, if it aims to take the lead away from Node.js. The initial-release plan asserts that Node.js is "pretty damn stable" as-is—the product of Joyent's slow release model—but it also asserts that moving to the "as fast as possible" model will make io.js more stable, not less. That will have to be proven with stable releases.

The io.js leadership may also have to grapple with project management, which is often not as easy as it sounds. "Openness" in governance, after all, is frequently in the eye of the beholder—and a lack of openness is often only perceived by those whose wishes are overruled by a project's existing governance. Cynics might note, for example, that io.js's Technical Committee is a self-appointing body with no term limits, no fixed size, and no formal eligibility requirements. Some users and developers might not call that open governance, either.

Forks are a natural part of the open development model—so much so that GitHub famously plasters a "fork your own copy" button on almost every page. But forks that attempt to set up and maintain an actively developed project in parallel to the original are rarer. Sometimes they work out well in their own right, sometimes they serve to catalyze changes in the original project, and sometimes they fade away. The io.js effort clearly demonstrates how critical Node.js has become to modern developers. What impact it will have in the long term remains to be seen.