Reconciliation Proposal

[mikeal]

A lot of questions have been coming our way about what a merger of the node.js and io.js projects might look like. People in both projects want to know their work won't be thrown away and that we can preserve the positive aspects of each project.

This is a draft and will be continually updated and edited based on input from the community. It is not an ultimatum to Joyent or The Node.js Foundation but rather a collaboration point for the io.js community to produce a proposal for merging.

This document uses the terms io.js and node.js to refer to those projects prior to a merge and Node to refer to a future merged project.

While io.js is often used as a starting point this document treats a future project under the foundation as a new organism made from the merger of each project and not as an extension of only node.js or only io.js. The goal of the merger should be a project that is actually greater than the sum these parts.

Technical Governance

The Node.js Foundation would adopt, as it's Technical Governance Structure (which is distinct and seperate from the foundation governance structure), a very simple structure which would ensure the following:

• Decision making autonomy from the foundation and its board.
• Ownership of its own governance and voting structure.

Because foundation bylaws are quite difficult to change and the TC wishes to make continued iterative improvements to its structure it would be a mistake to bake the entire governance structure as it exists today in to the foundation bylaws.

As an initial agreed upon structure, beyond what is in the bylaws, the following documents would be adopted from io.js.

• GOVERNANCE.md (TC, Voting, etc.)
• CONTRIBUTING.md (Collaborator policy, CoC, DCO, etc.)
• WORKING_GROUPS.md
• ROADMAP.md

In addition to the definition of "collaborator" from CONTRIBUTING.md the list of existing collaborators to io.js would also transfer.

The following changes would be made to these documents prior adoption:

• Addition of TC members:
  • TJ Fontaine
  • Alexis Campailla
  • Julien Gilli
• Addition of Collaborators:
  • James M Snell
  • Stephen Loomis
  • Michael Dawson

Long Term Support

High level ideas about LTS are addressed in the io.js roadmap but it lacks specifics because io.js has not yet produced a release that breaks compatibility with prior releases which would cause it to begin executing on this plan. The node.js project has an informal Long Term Support policy which is not formally documented but it does produce patch releases for prior versions so we can assume some policy does exist.

LTS WG (Long Term Support Working Group)

The following is a draft charter for the LTS WG which would be added to WORKING_GROUPS.md.

The LTS WG is responsible for maintenance and releases of prior versions of Node.

Node produces patch releases of prior versions for as long as community members are willing to maintain them. The LTS WG is responsible for when it no longer has the contributions necessary to support a particular version.

The LTS WG's responsibilities are:

• Authoring and backporting bug fixes, stability improvements, and other relevant
  changes to prior releases (not CURRENT or CANARY).
• Creation and maintenance of tools to help manage and automate backporting changes.
• Documentation and enforcement of policies to ensure the stability of patch releases.

Initial Members would include

• Michael Dawson

Note that specifics around managing branches is left out of the
charter but is part of the responsibilities for the working group under the last
bullet point.

Versions Merger

Because there is currently no overlap between io.js and node.js versions we can, and in fact must, consider all versions of both projects as now being versions of Node. If we did not we would unnecessarily break a large portion of the community that depends on these versions.

Prior Releases

The following versions are considered "prior releases" and are under the control of the LTS WG>

• 0.8.x
• 0.10.x
• 0.12.x

It should be noted that while 1.0+ releases follow semver versions prior to 1.0 did not and it is at the discretion of the LTS WG whether or not they would like to take API additions in to 0.12.x and 0.10.x patch releases. However, backwards incompatible changes cannot be made to these releases in following with the existing policies of both node.js and io.js.

Current Release

• 1.x

As it stands there are two CURRENT development lines: node.js 0.12.x and io.js 1.x. Development, in some form, will need to continue on both of these lines as different users depending on each line. The question then becomes "which line do we put in to LTS?"

In the last few months io.js has made huge gains in part due to the fact that it aligned its current stable line of development with that of its dependencies. That, along with a faster release cycle, has also brought many module authors in to core and so the ecosystem is beginning to also align its current stable development with that of core. This has ushered in a new era of collaboration between projects and the larger community which Node should continue.

This does not, however, mean that 0.12.x is a "dead" line. Far from it, 0.12.x and 0.10.x are still in use by many users and it will be the work of the LTS WG to continue to ensure those users have a stable and supported platform.

Non-Versioned Releases

CANARY ("next" V8 and any changes marked as major)

Along with the current stable line of development there should be a future line. This line exists as a branch and non-versioned nightly builds for testing. It is a testing ground for changes to Node that would necessitate bumping its major version as well as for testing the CANARY version of V8.

Just as we have done with current stable, the "next" line of Node development should align with that of its dependencies. This allows the project and its users to easily test for performance regressions and potentially breaking changes in those dependencies while active development is still occuring and long before they land in a stable version of Node.

Website

The nodejs.org website would transfer to the Website WG and become the responsibility of that working group. The website will be retooled similar to iojs.org (gulp builds) so that it can be localized by the various language communities from io.js.

Social Media

The social media accounts (Twitter, Facebook, etc) will transfer to the Evangelism WG.

Evangelism WG

This io.js WG will move to Node (pending a vote by the WG) and continue to produce weekly updates, social media engagement, etc, for the Node project.

i18n

All io.js language community working groups (32 individual teams by last count) will vote to
move to the Node project where they would continue to be endpoints for community members to
collaborate with each other in their language of choice and produce localizations of project resources.

Roadmap WG

This io.js WG will move to Node (pending a vote by the WG) and continue to draw in feedback
from users and draft roadmap materials for consideration by the TC.

Streams WG

This io.js WG will move to Node (pending a vote by the WG) along with readable-stream and will continue to define and improve streams in Node.

Tracing WG

This io.js WG will move to Node (pending a vote by the WG) and continue to improve the transparency of Node applications.

Build WG

This io.js WG will move to Node (pending a vote by the WG) and continue to maintain and improve the build infrastructure and produce Node builds.

[piscisaureus]

Addition of TC members: TJ Fontaine, Alexis Campailla

What about Julien, Steven, James, Michael who are now only working on node?

All io.js language community working groups (32 individual teams by last cound)

Nit: cound (spelling)

@mikeal Should we notify Node.js of this to get their input?

[mikeal]

What about Julien, Steven, James, Michael who are now only working on node?

The io.js TC is a small subset of the contributors/committers to io.js. I don't know enough about each of these individuals (other than Julien) and their work on node.js to know if they should be added to the TC (also wondering if they want to being that it's another weekly meeting on their schedule). Are these other people committers to node.js? Are they involved in driving the technical direction?

I saw that Julien did the 0.12 release though so it's pretty clear that he should be added.

[jasnell]

Steven, Michael and I (all from IBM) have recently been accepted as "Apprentice" members of the node.js core. Steven is primarily driving the Ecma-402 enablement, Michael's team is working on the ppc and system z ports, and I am focusing currently on globalization. As I understand it, we will soon have commit rights to node.js, albeit with an obvious need for review as we earn our stripes.

Once the foundation tc launches, we would very much like for our status to be retained, allowing us a chance to continue pushing forward with contributions. Each of us have been participating in the development of the node.js post v0.12 roadmap although we admittedly have a ways to go before rising above the "apprentice" level.

(and thank you @piscisaureus for thinking of us 👍 ...)

[mikeal]

@jasnell thanks! This clears things up.

The closest thing to "apprentice contributor" we have would be "collaborator" and that would also give you commit rights. Although it should be noted that all changes are done as pull requests and reviewed in io.js, even changes being made by TC members, and if the CONTRIBUTING.md file from io.js is adopted that policy would remain.

In addition to being collaborators it would make a lot of sense to add anyone working on PPC and Z ports to the LTS WG which would be maintaining old V8/node.js lines.

Does that sound about right?

[rvagg]

ECMA-402 & globalization support actually brings up an interesting issue: io.js hasn't enabled Intl support yet, both the TC and apparently the community (purely on anecdotal evidence, or the lack of it), haven't decided there is a need for this to be enabled in core. There may be technical reasons for it to be but the strong preference within the io.js "team" is to have a smaller core without overloading it with things that could be easily achieved in userland and we will strive hard to make that possible.

I have strong concerns about some of the work I see going on in joyent/node on this front. I'd like it noted that not only are there concerns on the Joyent side of this about the activity that has gone on in io.js since the fork (stated by Joyent representatives), but there are now also concerns on the io.js side of this about the activity that has gone on in joyent/node.

Clearly the longer it takes to find a mechanism for merging, the further the two projects will diverge based on both the amount of activity but also the philosophical and technical direction chosen by the separate parties and this will increase the difficulty of achieving a technical merger.

[jasnell]

That sounds about right, yes.

[piscisaureus]

Clearly the longer it takes to find a mechanism for merging the further the two projects will diverge based on both the amount of activity but also the philosophical and technical direction chosen by the separate parties and this will increase the difficulty of achieving a technical merger.

Maybe we can get concrete here/somewhere? The things that come to mind on my end -

• Node has landed ICU (ecma402 support). I'm not against that per se, but I have my opinions on the distribution model (iow -- let's not make node 3x bigger if we can help it).
• Node has added SSLv2 support and make SSLv2/3 configurable with a runtime option. Io.js has dropped support for either protocol for security reasons.

[mikeal]

Ok, added Julien to TC, IBM folks to collaborators and LTS WG.

[mikeal]

@rvagg @piscisaureus I think that these technical details should really be figured out by the TC and the LTS WG. New releases of 0.12.x should probably NOT drop support for something they previously supported. The 1.x line is already considered a "breaking change" from 0.12.x so there's no problem not having this stuff there (at least in terms of merging the existing versions).

As far as what happens with ICU and SSL in the CURRENT line (1.x), that's up to the TC which would gain 3 new voting members.

[piscisaureus]

Ok, added Julien to TC, IBM folks to collaborators and LTS WG.

That's okay for now I guess. I would argue it doesn't make much sense to put 3 IBM-ers in the LTS wg.

Ee can work this out later as well, e.g. if the IBM folks want to work on something not currently on the roadmap we could just consider the idea and create a separate wg if appropriate. Also having having at least one IBMer join TC meetings would be helpful.

@mikeal @rvagg Maybe we could have a "bare" edition (currently io.js) and a "extra" edition (currently node.js.

[jasnell]

@rvagg We happen to share many of those concerns and would like to see reconciliation happen as quickly and as smoothly as possible. Doing so would benefit the community as a whole.

As far as the Ecma402 work that @srl295 has been doing, we are definitely sensitive to the concerns but proper i18n support is a must have for us. It's why we put the work into enabling it. This thread, however, does not seem like the right place to have that particular discussion.

At some point, we ought to just get everyone together from both projects and simply lay the technical concerns out on the table and figure out how we're going to resolve them. (btw, If it would help, I've got a conference room in SF we can use to get as many people face to face as we can.)

Wait, @mikeal, do we want to notify node.js?

[jasnell]

@mikeal... as @piscisaureus suggests, it would likely make more sense to just have Michael in the LTS wg as it's his team that'll be working on those particular pieces.