By Nathan Willis
January 7, 2015
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:
io.js contributions, releases, and contributorship are under an open
governance model. We intend to land, with increasing regularity,
releases which are compatible with the npm ecosystem that has been
built to date for node.js.
(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:
If an agenda item cannot reach a consensus a TC member can call for
either a closing vote or a vote to table the issue to the next
meeting. The call for a vote must be seconded by a majority of the TC
or else the discussion will continue. Simple majority wins.
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.
(
Log in to post comments)