Reconciliation Proposal #978

Closed
mikeal opened this Issue Feb 26, 2015 · 222 comments

Comments

Projects
None yet
@mikeal
Member

mikeal commented Feb 26, 2015

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.

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

This comment has been minimized.

Show comment
Hide comment
@piscisaureus

piscisaureus Feb 26, 2015

Member

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)

Member

piscisaureus commented Feb 26, 2015

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)

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 26, 2015

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

ghost commented Feb 26, 2015

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

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Feb 26, 2015

Member

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.

Member

mikeal commented Feb 26, 2015

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

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Feb 26, 2015

Member

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 👍 ...)

Member

jasnell commented Feb 26, 2015

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

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Feb 26, 2015

Member

@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?

Member

mikeal commented Feb 26, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@rvagg

rvagg Feb 26, 2015

Member

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.

Member

rvagg commented Feb 26, 2015

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

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Feb 26, 2015

Member

That sounds about right, yes.

Member

jasnell commented Feb 26, 2015

That sounds about right, yes.

@piscisaureus

This comment has been minimized.

Show comment
Hide comment
@piscisaureus

piscisaureus Feb 26, 2015

Member

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.
Member

piscisaureus commented Feb 26, 2015

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

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Feb 26, 2015

Member

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

Member

mikeal commented Feb 26, 2015

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

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Feb 26, 2015

Member

@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.

Member

mikeal commented Feb 26, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@piscisaureus

piscisaureus Feb 26, 2015

Member

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.

Member

piscisaureus commented Feb 26, 2015

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.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 26, 2015

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

ghost commented Feb 26, 2015

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

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Feb 26, 2015

Member

@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.)

Member

jasnell commented Feb 26, 2015

@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.)

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 26, 2015

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

ghost commented Feb 26, 2015

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

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Feb 26, 2015

Member

@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.

Member

jasnell commented Feb 26, 2015

@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.

@piscisaureus

This comment has been minimized.

Show comment
Hide comment
@piscisaureus

piscisaureus Feb 26, 2015

Member

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

I think it's not too compelling two have two versions that differ only in ecma402 support. We should just pick a reasonable default and - if needed - distribute additional bits on npm.

Member

piscisaureus commented Feb 26, 2015

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

I think it's not too compelling two have two versions that differ only in ecma402 support. We should just pick a reasonable default and - if needed - distribute additional bits on npm.

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Feb 27, 2015

Member

@jasnell @piscisaureus updated so that just Michael is in LTS WG.

Member

mikeal commented Feb 27, 2015

@jasnell @piscisaureus updated so that just Michael is in LTS WG.

@piscisaureus

This comment has been minimized.

Show comment
Hide comment
@piscisaureus

piscisaureus Feb 27, 2015

Member

@joyent/node @iojs/collaborators

Member

piscisaureus commented Feb 27, 2015

@joyent/node @iojs/collaborators

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Feb 27, 2015

Member

We'll need all the working groups to ratify so I'm going to ping them:

  • @iojs/docker-admin
  • @iojs/build
  • @iojs/collaborators
  • @iojs/core
  • @iojs/tracing
  • @iojs/crypto
  • @iojs/website
  • @iojs/evangelism
  • @iojs/streams
  • @iojs/iojs-bg
  • @iojs/iojs-bn
  • @iojs/iojs-cn
  • @iojs/iojs-cs
  • @iojs/iojs-da
  • @iojs/iojs-de
  • @iojs/iojs-el
  • @iojs/iojs-es
  • @iojs/iojs-fa
  • @iojs/iojs-fi
  • @iojs/iojs-fr
  • @iojs/iojs-he
  • @iojs/iojs-hi
  • @iojs/iojs-hu
  • @iojs/iojs-id
  • @iojs/iojs-it
  • @iojs/iojs-ja
  • @iojs/iojs-ka
  • @iojs/iojs-ko
  • @iojs/iojs-mk
  • @iojs/iojs-nl
  • @iojs/iojs-no
  • @iojs/iojs-pl
  • @iojs/iojs-pt
  • @iojs/iojs-ro
  • @iojs/iojs-ru
  • @iojs/iojs-sv
  • @iojs/iojs-ta
  • @iojs/iojs-tr
  • @iojs/iojs-tw
  • @iojs/iojs-uk
  • @iojs/iojs-vi
Member

mikeal commented Feb 27, 2015

We'll need all the working groups to ratify so I'm going to ping them:

  • @iojs/docker-admin
  • @iojs/build
  • @iojs/collaborators
  • @iojs/core
  • @iojs/tracing
  • @iojs/crypto
  • @iojs/website
  • @iojs/evangelism
  • @iojs/streams
  • @iojs/iojs-bg
  • @iojs/iojs-bn
  • @iojs/iojs-cn
  • @iojs/iojs-cs
  • @iojs/iojs-da
  • @iojs/iojs-de
  • @iojs/iojs-el
  • @iojs/iojs-es
  • @iojs/iojs-fa
  • @iojs/iojs-fi
  • @iojs/iojs-fr
  • @iojs/iojs-he
  • @iojs/iojs-hi
  • @iojs/iojs-hu
  • @iojs/iojs-id
  • @iojs/iojs-it
  • @iojs/iojs-ja
  • @iojs/iojs-ka
  • @iojs/iojs-ko
  • @iojs/iojs-mk
  • @iojs/iojs-nl
  • @iojs/iojs-no
  • @iojs/iojs-pl
  • @iojs/iojs-pt
  • @iojs/iojs-ro
  • @iojs/iojs-ru
  • @iojs/iojs-sv
  • @iojs/iojs-ta
  • @iojs/iojs-tr
  • @iojs/iojs-tw
  • @iojs/iojs-uk
  • @iojs/iojs-vi

@ghost ghost referenced this issue in nodejs/node-v0.x-archive Feb 27, 2015

Closed

Reconciliation with io.js #9295

@ghost

This comment has been minimized.

Show comment
Hide comment

ghost commented Feb 27, 2015

@mikeal I notified joyent/node via nodejs/node-v0.x-archive#9295.

@benjamingr

This comment has been minimized.

Show comment
Hide comment
@benjamingr

benjamingr Feb 27, 2015

Member

As a member or @iojs/iojs-he I'm fine with moving to Node as long as contributing stays similar to how it is in io.js and the governance model remains open and community driven.

Member

benjamingr commented Feb 27, 2015

As a member or @iojs/iojs-he I'm fine with moving to Node as long as contributing stays similar to how it is in io.js and the governance model remains open and community driven.

@indexzero

This comment has been minimized.

Show comment
Hide comment
@indexzero

indexzero Feb 27, 2015

This is a well written and even keeled approach to reconciling the two code bases. The only large question I see here @mikeal is what would happen to node.js@0.12.x if it was continued to support over LTS and continues to diverge from io.js@1.x.x for natural reasons under a unified TC.

That is however, largely a question for @iojs/core and the node.js core folks and I'm sure a reasonable plan will be agreed upon.

This is a well written and even keeled approach to reconciling the two code bases. The only large question I see here @mikeal is what would happen to node.js@0.12.x if it was continued to support over LTS and continues to diverge from io.js@1.x.x for natural reasons under a unified TC.

That is however, largely a question for @iojs/core and the node.js core folks and I'm sure a reasonable plan will be agreed upon.

@isaacs

This comment has been minimized.

Show comment
Hide comment
@isaacs

isaacs Feb 27, 2015

Contributor

Most of this looks good to me.

The only point of significant technical divergence at this time seems to be intl.

I do not want to see io.js become "node-lite" and joyent/node to become "node-with-intl". It's not a pressing issue blocking merging the projects, but I would like to see some very clear-cut decision made by the TC about whether we're going to ship intl or not. We should not have two different flavors or distros, especially not under the same name; that's even worse than what we have now.

The most successful end-game is a single "node" that can make forward progress.

What I've heard from Joyent folks is that they'd like to see a clear-cut strategy for long-term support that doesn't leave users behind in the cold. I think that's a fair request, and the LTSWG is working on it. Let's continue that process.

Another concern I've heard from Joyent collaborators is that they don't want to be excluded or marginalized before the projects have had a chance to integrate and find common ground. That's also fair, in my opinion. Merging these projects will certainly cause some conflicts, and it's unlikely that anyone will be able to collaborate in good faith if they're busy watching their backs for political maneuvering. I've suggested in the past a temporary moratorium on expelling anyone from the TC for some reasonable period of time as a way to address that concern, but there may be other strategies as well.

From what I've seen and heard in the foundation setup, they do want the TC to be self-governed, and protected from undue influence by the executive board. However, they also want to make sure that the project won't be hijacked immediately in bad faith, which is why we've heard suggestions of specific TC governance rules being set on day 1, some of which are significantly different from the io.js tc, and some of which (like requiring strict consensus for every TC decision) I personally believe will be extremely problematic and likely to stall progress.

At the last JNAB meeting, there was a suggestion of getting the io.js TC and the node foundation folks together to discuss this. I think that's a good idea, but also sent out some homework questions to hopefully prime the discussion in an empathetic and collaborative direction. Hopefully we won't just get in a room and talk past each other for hours.

Contributor

isaacs commented Feb 27, 2015

Most of this looks good to me.

The only point of significant technical divergence at this time seems to be intl.

I do not want to see io.js become "node-lite" and joyent/node to become "node-with-intl". It's not a pressing issue blocking merging the projects, but I would like to see some very clear-cut decision made by the TC about whether we're going to ship intl or not. We should not have two different flavors or distros, especially not under the same name; that's even worse than what we have now.

The most successful end-game is a single "node" that can make forward progress.

What I've heard from Joyent folks is that they'd like to see a clear-cut strategy for long-term support that doesn't leave users behind in the cold. I think that's a fair request, and the LTSWG is working on it. Let's continue that process.

Another concern I've heard from Joyent collaborators is that they don't want to be excluded or marginalized before the projects have had a chance to integrate and find common ground. That's also fair, in my opinion. Merging these projects will certainly cause some conflicts, and it's unlikely that anyone will be able to collaborate in good faith if they're busy watching their backs for political maneuvering. I've suggested in the past a temporary moratorium on expelling anyone from the TC for some reasonable period of time as a way to address that concern, but there may be other strategies as well.

From what I've seen and heard in the foundation setup, they do want the TC to be self-governed, and protected from undue influence by the executive board. However, they also want to make sure that the project won't be hijacked immediately in bad faith, which is why we've heard suggestions of specific TC governance rules being set on day 1, some of which are significantly different from the io.js tc, and some of which (like requiring strict consensus for every TC decision) I personally believe will be extremely problematic and likely to stall progress.

At the last JNAB meeting, there was a suggestion of getting the io.js TC and the node foundation folks together to discuss this. I think that's a good idea, but also sent out some homework questions to hopefully prime the discussion in an empathetic and collaborative direction. Hopefully we won't just get in a room and talk past each other for hours.

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Feb 27, 2015

Member

Another concern I've heard from Joyent collaborators is that they don't want to be excluded or marginalized.

I understand that this is a concern but I find it somewhat unwarranted. The process is too transparent for a set of people to successfully cut someone out in bad faith without significant negative consequences for those people and the project as a whole. Additionally, I would expect that those who are significantly invested in concerns over the stability of prior releases and LTS to be members of the LTS WG which is just being created and, being that it will mostly be involved in 0.12, I would expect it to be dominated by node.js contributors, at least at first.

Anyway, if all of this isn't enough to alleviate concerns then we can consider some period of time where people cannot be removed from the TC. That said, we can't mint membership entirely or guarantee seats for too long, considering how fast the project has grown and how much we've needed to adjust as we've gone we don't want to mint anything for too long.

Member

mikeal commented Feb 27, 2015

Another concern I've heard from Joyent collaborators is that they don't want to be excluded or marginalized.

I understand that this is a concern but I find it somewhat unwarranted. The process is too transparent for a set of people to successfully cut someone out in bad faith without significant negative consequences for those people and the project as a whole. Additionally, I would expect that those who are significantly invested in concerns over the stability of prior releases and LTS to be members of the LTS WG which is just being created and, being that it will mostly be involved in 0.12, I would expect it to be dominated by node.js contributors, at least at first.

Anyway, if all of this isn't enough to alleviate concerns then we can consider some period of time where people cannot be removed from the TC. That said, we can't mint membership entirely or guarantee seats for too long, considering how fast the project has grown and how much we've needed to adjust as we've gone we don't want to mint anything for too long.

@indexzero

This comment has been minimized.

Show comment
Hide comment
@indexzero

indexzero Feb 27, 2015

@isaacs we've heard suggestions of specific TC governance rules being set on day 1, some of which are significantly different from the io.js tc, and some of which (like requiring strict consensus for every TC decision) I personally believe will be extremely problematic and likely to stall progress.

I 100% agree with you that strict consensus (i.e. veto) will be very problematic for getting things done from the technical perspective. What other significant differences are there? I've lost track of where the JNAB minute notes get posted.

@isaacs we've heard suggestions of specific TC governance rules being set on day 1, some of which are significantly different from the io.js tc, and some of which (like requiring strict consensus for every TC decision) I personally believe will be extremely problematic and likely to stall progress.

I 100% agree with you that strict consensus (i.e. veto) will be very problematic for getting things done from the technical perspective. What other significant differences are there? I've lost track of where the JNAB minute notes get posted.

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Feb 27, 2015

Member

strict consensus

I'm gonna go out on a limb and say that strict consensus for any part of decision making is a deal breaker. If an argument breaks down and we can't reach an agreement it isn't acceptable to just do nothing and grind to a halt and we already know that is where strict consensus can lead for this exact group of people.

The consensus seeking model is working tremendously well. If we're worried that the voting fallback (which we've never actually had to use BTW) is too permissive for certain decisions we can consider upping the majority necessary to 60%.

Member

mikeal commented Feb 27, 2015

strict consensus

I'm gonna go out on a limb and say that strict consensus for any part of decision making is a deal breaker. If an argument breaks down and we can't reach an agreement it isn't acceptable to just do nothing and grind to a halt and we already know that is where strict consensus can lead for this exact group of people.

The consensus seeking model is working tremendously well. If we're worried that the voting fallback (which we've never actually had to use BTW) is too permissive for certain decisions we can consider upping the majority necessary to 60%.

@davglass

This comment has been minimized.

Show comment
Hide comment
@davglass

davglass Feb 27, 2015

Contributor

I'd like to see Intl added in as a single language by default then allow the end user to compile in all the languages that they want or hot load them on the fly. We are very excited to be able to use Intl for all of the languages that we have to support 😄

Contributor

davglass commented Feb 27, 2015

I'd like to see Intl added in as a single language by default then allow the end user to compile in all the languages that they want or hot load them on the fly. We are very excited to be able to use Intl for all of the languages that we have to support 😄

@listochkin

This comment has been minimized.

Show comment
Hide comment
@listochkin

listochkin Feb 27, 2015

Member

Like others said, the plan looks reasonable and promising, and @iojs/iojs-uk group will definitely support its current version or any modified version that still follows the spirit of the original proposal. We are interested in promoting and expanding Node-the-ecosystem and strongly believe that the unified project will benefit everyone.

Regarding Intl we support having it build into Node. Ukrainian is a distinctive Slavic language with non-Latin alphabet, distinct collation rules, etc. The target audience of our group are people who use Ukrainian to learn programming in general, JavaScript and Node in particular, and who are very likely use it to use Ukrainian in their software. The fact that many language-specific features will just work is very valuable.

We don't think it should be a separate module on npm, though. Ecma402 defines the standard I18n API with globals, and we would expect Node to behave this way, too. Ultimately, both Node.js and iojs today claim to be JavaScript platforms, and global Intl is a part of the standard.

If it can be a some kind of magic module, then so be it. However, if a person would have to download it and/or update it separately, then we'd likely repeat the mistake JVM made with an isolated copy of tzdata. JVM's tzdata can be updated separately from a system-wide one. Most developers and admins, however, don't bother with it. As a result most Java deployments out there have an up-to-date system-wide tzdata that is completely ignored by the JVM, which instead uses an obsolete version.

Speaking of binary sizes I suspect that most major operating systems have i18n libraries and APIs build in. We could potentially link to those instead of forcing users to download ICU every time they update Node.

Of couse there are certain situations when having Intl enabled is undesirable, for example for Raspberry Pi builds. However, in our opinion not having Intl should be a deliberate choice. I18n should be opt out, not opt in

Member

listochkin commented Feb 27, 2015

Like others said, the plan looks reasonable and promising, and @iojs/iojs-uk group will definitely support its current version or any modified version that still follows the spirit of the original proposal. We are interested in promoting and expanding Node-the-ecosystem and strongly believe that the unified project will benefit everyone.

Regarding Intl we support having it build into Node. Ukrainian is a distinctive Slavic language with non-Latin alphabet, distinct collation rules, etc. The target audience of our group are people who use Ukrainian to learn programming in general, JavaScript and Node in particular, and who are very likely use it to use Ukrainian in their software. The fact that many language-specific features will just work is very valuable.

We don't think it should be a separate module on npm, though. Ecma402 defines the standard I18n API with globals, and we would expect Node to behave this way, too. Ultimately, both Node.js and iojs today claim to be JavaScript platforms, and global Intl is a part of the standard.

If it can be a some kind of magic module, then so be it. However, if a person would have to download it and/or update it separately, then we'd likely repeat the mistake JVM made with an isolated copy of tzdata. JVM's tzdata can be updated separately from a system-wide one. Most developers and admins, however, don't bother with it. As a result most Java deployments out there have an up-to-date system-wide tzdata that is completely ignored by the JVM, which instead uses an obsolete version.

Speaking of binary sizes I suspect that most major operating systems have i18n libraries and APIs build in. We could potentially link to those instead of forcing users to download ICU every time they update Node.

Of couse there are certain situations when having Intl enabled is undesirable, for example for Raspberry Pi builds. However, in our opinion not having Intl should be a deliberate choice. I18n should be opt out, not opt in

@yoshuawuyts

This comment has been minimized.

Show comment
Hide comment
@yoshuawuyts

yoshuawuyts Feb 27, 2015

Member

The goal of the merger should be a project that is actually greater than the sum these parts.

To me it's still unclear what benefits a merger with node.js would have. This issue appears to be more focused on the how of a merger, and less on the why. Is there an overview where the benefits / costs of merging with node.js are outlined? If there's not, I'd be curious to know what the view of the io.js TC and collaborators is on this (possibly in separate issue, if this is not the right place for it). Thanks!

Member

yoshuawuyts commented Feb 27, 2015

The goal of the merger should be a project that is actually greater than the sum these parts.

To me it's still unclear what benefits a merger with node.js would have. This issue appears to be more focused on the how of a merger, and less on the why. Is there an overview where the benefits / costs of merging with node.js are outlined? If there's not, I'd be curious to know what the view of the io.js TC and collaborators is on this (possibly in separate issue, if this is not the right place for it). Thanks!

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Feb 27, 2015

Member

@yoshuawuyts we covered that in https://medium.com/@iojs/io-js-and-a-node-js-foundation-4e14699fb7be

"The only thing that could make io.js better is putting to rest the questions hanging over the future of our split with node.js."

Member

mikeal commented Feb 27, 2015

@yoshuawuyts we covered that in https://medium.com/@iojs/io-js-and-a-node-js-foundation-4e14699fb7be

"The only thing that could make io.js better is putting to rest the questions hanging over the future of our split with node.js."

@Qard

This comment has been minimized.

Show comment
Hide comment
@Qard

Qard Feb 27, 2015

Member

👍 I'm all for joining forces and transforming into one big node-powered megazord team.

Member

Qard commented Feb 27, 2015

👍 I'm all for joining forces and transforming into one big node-powered megazord team.

@richb-hanover

This comment has been minimized.

Show comment
Hide comment
@richb-hanover

richb-hanover Feb 27, 2015

Nit: it's === it is; use "its" for possessive
Nit: separate ("a rat" is in the middle)

Nit: it's === it is; use "its" for possessive
Nit: separate ("a rat" is in the middle)

@fengmk2

This comment has been minimized.

Show comment
Hide comment
@fengmk2

fengmk2 Feb 27, 2015

Member

How the Node.js Foundation progress? I only see current node is still joyent/node.

Before we start voting to move WG to Node project, the Node project to transfer to names like nodejs/node or node-foundation/node.

At the last JNAB meeting, there was a suggestion of getting the io.js TC and the node foundation folks together to discuss this.

Let's make the discuss happen.

Member

fengmk2 commented Feb 27, 2015

How the Node.js Foundation progress? I only see current node is still joyent/node.

Before we start voting to move WG to Node project, the Node project to transfer to names like nodejs/node or node-foundation/node.

At the last JNAB meeting, there was a suggestion of getting the io.js TC and the node foundation folks together to discuss this.

Let's make the discuss happen.

@aredridel

This comment has been minimized.

Show comment
Hide comment
@aredridel

aredridel Feb 27, 2015

Contributor

I like how this sounds.

Contributor

aredridel commented Feb 27, 2015

I like how this sounds.

@davidjpeacock

This comment has been minimized.

Show comment
Hide comment
@davidjpeacock

davidjpeacock Feb 27, 2015

My only concern is with regards to LTS.

The nature of a robust LTS system is a guaranteed finite period of time that people running production or mission critical services can count on stable patches.

I'd like clarification on the mixed message I'm receiving, because this isn't obvious to me. What is meant by "The LTS WG is responsible for when it no longer has the contributions necessary to support a particular version." ? Does this mean that there will indeed be a committed to length of time for a given LTS version, or is this cancelled out by the "Node produces patch releases of prior versions for as long as community members are willing to maintain them." statement? I find this ambiguous.

Otherwise, I'm all in favour of this merger and proposed Node successor.

Keep up the good work, everyone involved, and thank you from a community member. :-)

My only concern is with regards to LTS.

The nature of a robust LTS system is a guaranteed finite period of time that people running production or mission critical services can count on stable patches.

I'd like clarification on the mixed message I'm receiving, because this isn't obvious to me. What is meant by "The LTS WG is responsible for when it no longer has the contributions necessary to support a particular version." ? Does this mean that there will indeed be a committed to length of time for a given LTS version, or is this cancelled out by the "Node produces patch releases of prior versions for as long as community members are willing to maintain them." statement? I find this ambiguous.

Otherwise, I'm all in favour of this merger and proposed Node successor.

Keep up the good work, everyone involved, and thank you from a community member. :-)

@trademark-question

This comment has been minimized.

Show comment
Hide comment
@trademark-question

trademark-question Feb 27, 2015

I'm not an io.js contributor, but have been very impressed with the progress io.js has seen in the last month.

One thing I did not realise prior to the fork was how restrictive Joyents Node.js trademark policy was.

Whilst not a technical point of difference, the io.js governance seems to be far better with respects to acceptable use policy for the project name.

Is this currently being considered as part of the reconciliation process?

I'm not an io.js contributor, but have been very impressed with the progress io.js has seen in the last month.

One thing I did not realise prior to the fork was how restrictive Joyents Node.js trademark policy was.

Whilst not a technical point of difference, the io.js governance seems to be far better with respects to acceptable use policy for the project name.

Is this currently being considered as part of the reconciliation process?

@Fishrock123

This comment has been minimized.

Show comment
Hide comment
@Fishrock123

Fishrock123 Mar 26, 2015

Member

Glad to hear. :)

I do agree the code merge would be fairly involved.

Member

Fishrock123 commented Mar 26, 2015

Glad to hear. :)

I do agree the code merge would be fairly involved.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Mar 26, 2015

Off topic (but I feel this is important):

@ravi, it is considered rude to delete your comments from the thread, especially when you are tagged and answered adequately. I am reading this thread now and noticed that rather than being appreciative to people who are trying to address your concerns, you instead deleted the comments.

ghost commented Mar 26, 2015

Off topic (but I feel this is important):

@ravi, it is considered rude to delete your comments from the thread, especially when you are tagged and answered adequately. I am reading this thread now and noticed that rather than being appreciative to people who are trying to address your concerns, you instead deleted the comments.

@cusspvz

This comment has been minimized.

Show comment
Hide comment
@cusspvz

cusspvz Mar 26, 2015

Contributor

Nice to hear that this is going forwards!

Contributor

cusspvz commented Mar 26, 2015

Nice to hear that this is going forwards!

@yadakhov

This comment has been minimized.

Show comment
Hide comment
@yadakhov

yadakhov Mar 30, 2015

Really hope things are moving forward.

I'm learning node.js for the first time this month. Hoping to use the power of node.js to replace some our legacy system. Then I learned about the fork.

It's going to be hard for me to convince upper management to use node.js/io.js if from the outside the project seems to lack stability.

Really hope things are moving forward.

I'm learning node.js for the first time this month. Hoping to use the power of node.js to replace some our legacy system. Then I learned about the fork.

It's going to be hard for me to convince upper management to use node.js/io.js if from the outside the project seems to lack stability.

@Fishrock123

This comment has been minimized.

Show comment
Hide comment
@Fishrock123

Fishrock123 Mar 30, 2015

Member

@yadakhov if it helps, node 0.10 is still as stable as it has been for many companies for the past 2+ years.

Member

Fishrock123 commented Mar 30, 2015

@yadakhov if it helps, node 0.10 is still as stable as it has been for many companies for the past 2+ years.

@seeekr

This comment has been minimized.

Show comment
Hide comment
@seeekr

seeekr Mar 30, 2015

@yadakhov fwiw my humble opinion on this: You're misinterpreting what's going on here if you think that the fork shows a lack of stability. The iojs fork shows the strength of the community, the will and desire to move the codebase, the community and the ecosystem forward! Plus on the other hand you have Joyent who are very very interested in providing a stable and long-term supported version of node.js, and despite the fork that version is still there and there are no major issues in using either joyent/node or the iojs fork (like npm modules are all (?) still compatible with both "node versions", it's not like the ecosystem has actually been splitting up really). So you see, this situation shows that there is both long-term commitment and stability from at least 2 major groups of people, plus strong desire and commitment to keep improving and keep moving forward and provide the community with the best version of "Node.JS" possible. And from that angle things are going just swimmingly. I think many of us are very very excited to see the work and commitment around the Node.JS community, both in core and module-wise on npm, plus the greater ecosystem of tools like nw.js that build on this strong and stable and enthusiastic community!
Nothing was lost by this fork and a whole lot was gained, with much more to come as well. Good times!

seeekr commented Mar 30, 2015

@yadakhov fwiw my humble opinion on this: You're misinterpreting what's going on here if you think that the fork shows a lack of stability. The iojs fork shows the strength of the community, the will and desire to move the codebase, the community and the ecosystem forward! Plus on the other hand you have Joyent who are very very interested in providing a stable and long-term supported version of node.js, and despite the fork that version is still there and there are no major issues in using either joyent/node or the iojs fork (like npm modules are all (?) still compatible with both "node versions", it's not like the ecosystem has actually been splitting up really). So you see, this situation shows that there is both long-term commitment and stability from at least 2 major groups of people, plus strong desire and commitment to keep improving and keep moving forward and provide the community with the best version of "Node.JS" possible. And from that angle things are going just swimmingly. I think many of us are very very excited to see the work and commitment around the Node.JS community, both in core and module-wise on npm, plus the greater ecosystem of tools like nw.js that build on this strong and stable and enthusiastic community!
Nothing was lost by this fork and a whole lot was gained, with much more to come as well. Good times!

@Fishrock123

This comment has been minimized.

Show comment
Hide comment
@Fishrock123

Fishrock123 Mar 30, 2015

Member

fwiw my humble opinion on this: You're misinterpreting what's going on here if you think that the fork shows a lack of stability.

@seeekr please see:

It's going to be hard for me to convince upper management to use node.js/io.js if from the outside the project seems to lack stability.

Usually doesn't matter what it is or is not to these sorts. All that matters is what it seems.

Member

Fishrock123 commented Mar 30, 2015

fwiw my humble opinion on this: You're misinterpreting what's going on here if you think that the fork shows a lack of stability.

@seeekr please see:

It's going to be hard for me to convince upper management to use node.js/io.js if from the outside the project seems to lack stability.

Usually doesn't matter what it is or is not to these sorts. All that matters is what it seems.

@tjwebb

This comment has been minimized.

Show comment
Hide comment
@tjwebb

tjwebb Mar 30, 2015

and despite the fork that version is still there and there are no major issues in using either joyent/node or the iojs fork

Well, it's only been a couple months. That everything still works magically together in 10 years is fantasy. This is the problem. Looking ahead, things aren't good. The iojs people either didn't think about the long-term consequences of this, or didn't care.

The iojs fork shows the strength of the community, the will and desire to move the codebase, the community and the ecosystem forward!

Actually it just shows that some people in the community think they are more equal than others.

While iojs and node people fight over who is the true node, the actual users you think you're helping will roll their eyes and actually get some work done. This whole thing is stupid, and reminds me of this: https://gist.github.com/mikeal/9242748.

iojs team: you've proved your point and you got your spiffy new v8 version and your foundation. Now stop. Every PR you merge is more technical debt on the entire community.

tjwebb commented Mar 30, 2015

and despite the fork that version is still there and there are no major issues in using either joyent/node or the iojs fork

Well, it's only been a couple months. That everything still works magically together in 10 years is fantasy. This is the problem. Looking ahead, things aren't good. The iojs people either didn't think about the long-term consequences of this, or didn't care.

The iojs fork shows the strength of the community, the will and desire to move the codebase, the community and the ecosystem forward!

Actually it just shows that some people in the community think they are more equal than others.

While iojs and node people fight over who is the true node, the actual users you think you're helping will roll their eyes and actually get some work done. This whole thing is stupid, and reminds me of this: https://gist.github.com/mikeal/9242748.

iojs team: you've proved your point and you got your spiffy new v8 version and your foundation. Now stop. Every PR you merge is more technical debt on the entire community.

@mgol

This comment has been minimized.

Show comment
Hide comment
@mgol

mgol Mar 30, 2015

Contributor

While iojs and node people fight over who is the true node, the actual users you think you're helping will roll their eyes and actually get some work done.

There are many Node.js/io.js users (like me) that are happy that something is finally happening in the Node land instead of the stagnation that followed for so many months. Sometimes some pain is required to save something from deteriorating completely. Just look at contribution graphs:

  1. Node.js: https://github.com/joyent/node/graphs/contributors
  2. io.js: https://github.com/iojs/io.js/graphs/contributors
Contributor

mgol commented Mar 30, 2015

While iojs and node people fight over who is the true node, the actual users you think you're helping will roll their eyes and actually get some work done.

There are many Node.js/io.js users (like me) that are happy that something is finally happening in the Node land instead of the stagnation that followed for so many months. Sometimes some pain is required to save something from deteriorating completely. Just look at contribution graphs:

  1. Node.js: https://github.com/joyent/node/graphs/contributors
  2. io.js: https://github.com/iojs/io.js/graphs/contributors
@tjwebb

This comment has been minimized.

Show comment
Hide comment
@tjwebb

tjwebb Mar 30, 2015

instead of the stagnation that followed for so many months

There was no stagnation, people have been working very hard on node the whole time. Don't confuse actual stagnation with you just weren't getting the features you wanted

tjwebb commented Mar 30, 2015

instead of the stagnation that followed for so many months

There was no stagnation, people have been working very hard on node the whole time. Don't confuse actual stagnation with you just weren't getting the features you wanted

@Fishrock123

This comment has been minimized.

Show comment
Hide comment
@Fishrock123

Fishrock123 Mar 30, 2015

Member

iojs team: you've proved your point and you got your spiffy new v8 version and your foundation. Now stop. Every PR you merge is more technical debt on the entire community.

The point was to have open collaboration to help move node forward. That has and will continue to happen. :)

There was no stagnation, people have been working very hard on node the whole time. Don't confuse actual stagnation with you just weren't getting the features you wanted

Why did most of the existing collaborators move (and want to move) the majority of their efforts here then?

Member

Fishrock123 commented Mar 30, 2015

iojs team: you've proved your point and you got your spiffy new v8 version and your foundation. Now stop. Every PR you merge is more technical debt on the entire community.

The point was to have open collaboration to help move node forward. That has and will continue to happen. :)

There was no stagnation, people have been working very hard on node the whole time. Don't confuse actual stagnation with you just weren't getting the features you wanted

Why did most of the existing collaborators move (and want to move) the majority of their efforts here then?

@algesten

This comment has been minimized.

Show comment
Hide comment
@algesten

algesten Mar 30, 2015

There was no stagnation, people have been working very hard on node the whole time.

So where is this hard work? Which repo? An opensource project, surely there are some commits somewhere?

There was no stagnation, people have been working very hard on node the whole time.

So where is this hard work? Which repo? An opensource project, surely there are some commits somewhere?

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Mar 30, 2015

Member

iojs team: you've proved your point and you got your spiffy new v8 version and your foundation. Now stop. Every PR you merge is more technical debt on the entire community.

Why would we stop development and why would it be technical debt? If you'd read the actually reconciliation proposal you'd see that the different version lines from both io.js and node.js would remain intact.

There was no stagnation

This is simply not true. Contributions to node.js were at an all time low when we forked and releases had slowed to almost zero. You don't have to take my word for it, you can look at the contribution graphs and the release timelines. Yes, there were "people working on node the whole time" and most of those people were the initial contributors to io.js :)

Anyway, this line of complaint is not actually productive. We have a proposal for reconciliation, we have a proposal for open governance in the advisory board we're working on. joyent/nodejs-advisory-board#30 Things are progressing nicely toward a reconciliation and there is no need to stop development of io.js waiting for those to complete. I honestly don't know where that hostility came from but it seems very misplaced.

Member

mikeal commented Mar 30, 2015

iojs team: you've proved your point and you got your spiffy new v8 version and your foundation. Now stop. Every PR you merge is more technical debt on the entire community.

Why would we stop development and why would it be technical debt? If you'd read the actually reconciliation proposal you'd see that the different version lines from both io.js and node.js would remain intact.

There was no stagnation

This is simply not true. Contributions to node.js were at an all time low when we forked and releases had slowed to almost zero. You don't have to take my word for it, you can look at the contribution graphs and the release timelines. Yes, there were "people working on node the whole time" and most of those people were the initial contributors to io.js :)

Anyway, this line of complaint is not actually productive. We have a proposal for reconciliation, we have a proposal for open governance in the advisory board we're working on. joyent/nodejs-advisory-board#30 Things are progressing nicely toward a reconciliation and there is no need to stop development of io.js waiting for those to complete. I honestly don't know where that hostility came from but it seems very misplaced.

@piscisaureus

This comment has been minimized.

Show comment
Hide comment
@piscisaureus

piscisaureus Mar 30, 2015

Member

After processing the first round of comments, a draft charter has been landed in joyent/nodejs-advisory-board@0609b04.

Mikeal is now making an attempt to add "support" for working groups to the foundation's technical governance documents: joyent/nodejs-advisory-board#33.

Member

piscisaureus commented Mar 30, 2015

After processing the first round of comments, a draft charter has been landed in joyent/nodejs-advisory-board@0609b04.

Mikeal is now making an attempt to add "support" for working groups to the foundation's technical governance documents: joyent/nodejs-advisory-board#33.

@rosskukulinski

This comment has been minimized.

Show comment
Hide comment
@cusspvz

This comment has been minimized.

Show comment
Hide comment
@cusspvz

cusspvz Mar 30, 2015

Contributor

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.

"Non-Versioned Releases" could use some clarification. This section notes that "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."

So, does it means that CANARY v8 version merges will be available on some sort of node 1.x-canary stable builds only after testing?

It would be great if there was a second diversion on node's canary releases such as unstable which could have most of merges from nightly CANARY. It would be faster to identify which could be merged or not every day.

Couldn't it allow CURRENT and CANARY to have similar releases, or even the same?

That would allow:

Versions:
x.x.x - CURRENT
x.x.x-canary - CANARY

Non-versions:
nightly-build-current - CURRENT branch
nightly-build-canary - CANARY branch
nightly-build-canary-unstable - CANARY testing branch

Contributor

cusspvz commented Mar 30, 2015

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.

"Non-Versioned Releases" could use some clarification. This section notes that "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."

So, does it means that CANARY v8 version merges will be available on some sort of node 1.x-canary stable builds only after testing?

It would be great if there was a second diversion on node's canary releases such as unstable which could have most of merges from nightly CANARY. It would be faster to identify which could be merged or not every day.

Couldn't it allow CURRENT and CANARY to have similar releases, or even the same?

That would allow:

Versions:
x.x.x - CURRENT
x.x.x-canary - CANARY

Non-versions:
nightly-build-current - CURRENT branch
nightly-build-canary - CANARY branch
nightly-build-canary-unstable - CANARY testing branch

@Starefossen

This comment has been minimized.

Show comment
Hide comment
@Starefossen

Starefossen Mar 31, 2015

Member

On 30. mars 2015, at 20:56, Travis Webb notifications@github.com wrote:

iojs team: you've proved your point and you got your spiffy new v8 version and your foundation. Now stop. Every PR you merge is more technical debt on the entire community.

It is obvious that you know very little (or nothing!) about what V8 actually is and what importance it plays in node. You don't really seam to grip how open source works either. Sad.

Member

Starefossen commented Mar 31, 2015

On 30. mars 2015, at 20:56, Travis Webb notifications@github.com wrote:

iojs team: you've proved your point and you got your spiffy new v8 version and your foundation. Now stop. Every PR you merge is more technical debt on the entire community.

It is obvious that you know very little (or nothing!) about what V8 actually is and what importance it plays in node. You don't really seam to grip how open source works either. Sad.

@cjihrig

This comment has been minimized.

Show comment
Hide comment
@cjihrig

cjihrig May 12, 2015

Contributor

Closing this in favor of #1664

Contributor

cjihrig commented May 12, 2015

Closing this in favor of #1664

@cjihrig cjihrig closed this May 12, 2015

@thephw thephw referenced this issue in DerbyBoutTime/bouttime Jun 2, 2015

Merged

Feature/tests #74

@gyaresu gyaresu referenced this issue in greenpeace/open-learning Jun 4, 2015

Closed

Hello Greenpeacers #7

@luke-john

This comment has been minimized.

Show comment
Hide comment
@luke-john

luke-john Jun 17, 2015

@trademark-question the trademark ownership will be transferred to the foundation as part of Joyent "putting node.js in a foundation" and the foundation will be responsible for a new trademark poilcy for node.js.

@mikeal The new foundations trademark policy contains the following text

Q: Does the Node.js Foundation Own the Node.js marks? A: No, the Node.js Foundation
does not own the registered Node.js marks, but the Foundation has full authority to
authorize your use of the Node.js marks consistent with these guidelines.
Joyent, Inc. acts as a Trademark steward for the Node.js word mark and logo. When reasonable, please
include this notice when you use a mark outside of the Foundation:
Node.js is a trademark of Joyent, Inc. and is used with its permission. We are not endorsed by or
affiliated with Joyent.”
https://nodejs.org/images/foundation-trademark-policy.pdf

Could you explain why the trademark ownership was never transferred? The new policy seems just as problematic as the previous one, which as I understand it caused the whole iojs/node split in the first place.

@trademark-question the trademark ownership will be transferred to the foundation as part of Joyent "putting node.js in a foundation" and the foundation will be responsible for a new trademark poilcy for node.js.

@mikeal The new foundations trademark policy contains the following text

Q: Does the Node.js Foundation Own the Node.js marks? A: No, the Node.js Foundation
does not own the registered Node.js marks, but the Foundation has full authority to
authorize your use of the Node.js marks consistent with these guidelines.
Joyent, Inc. acts as a Trademark steward for the Node.js word mark and logo. When reasonable, please
include this notice when you use a mark outside of the Foundation:
Node.js is a trademark of Joyent, Inc. and is used with its permission. We are not endorsed by or
affiliated with Joyent.”
https://nodejs.org/images/foundation-trademark-policy.pdf

Could you explain why the trademark ownership was never transferred? The new policy seems just as problematic as the previous one, which as I understand it caused the whole iojs/node split in the first place.

@Fishrock123

This comment has been minimized.

Show comment
Hide comment
@Fishrock123

Fishrock123 Jun 17, 2015

Member

Could you explain why the trademark ownership was never transferred? The new policy seems just as problematic as the previous one, which as I understand it caused the whole iojs/node split in the first place.

  1. It's a legal quagmire to do the actual transfer.
  2. Owning it would mean we would have to expend resources enforcing it ourselves.

(There might be a 3? I forget.)

Edit: Also it wasn't the actual cause of the split. Poor project management would be closer to the actual reason.

Member

Fishrock123 commented Jun 17, 2015

Could you explain why the trademark ownership was never transferred? The new policy seems just as problematic as the previous one, which as I understand it caused the whole iojs/node split in the first place.

  1. It's a legal quagmire to do the actual transfer.
  2. Owning it would mean we would have to expend resources enforcing it ourselves.

(There might be a 3? I forget.)

Edit: Also it wasn't the actual cause of the split. Poor project management would be closer to the actual reason.

@feross

This comment has been minimized.

Show comment
Hide comment
@feross

feross Jun 17, 2015

Contributor
  1. Why? Selling a trademark is straightforward. Joyent can sell it to the foundation for $1.
  2. Isn't that what all the corporate funding and fancy suits in the foundation should be doing?
Contributor

feross commented Jun 17, 2015

  1. Why? Selling a trademark is straightforward. Joyent can sell it to the foundation for $1.
  2. Isn't that what all the corporate funding and fancy suits in the foundation should be doing?
@Nicolab

This comment has been minimized.

Show comment
Hide comment
Contributor

Nicolab commented Jun 17, 2015

@mercmobily

This comment has been minimized.

Show comment
Hide comment
@mercmobily

mercmobily Jun 17, 2015

I am absolutely nobody here. Just giving my humble 2c

  1. It's not too hard
  2. I don't think it would be fair to expect Joyent to do all the work of protecting it. Quoting feross: "Isn't that what all the corporate funding and fancy suits in the foundation should be doing?"

Keeping the trademark, a crucial part of node, would be "leasing node to the foundation", rather than "giving it to the foundation".

I am absolutely nobody here. Just giving my humble 2c

  1. It's not too hard
  2. I don't think it would be fair to expect Joyent to do all the work of protecting it. Quoting feross: "Isn't that what all the corporate funding and fancy suits in the foundation should be doing?"

Keeping the trademark, a crucial part of node, would be "leasing node to the foundation", rather than "giving it to the foundation".

@mercmobily

This comment has been minimized.

Show comment
Hide comment
@mercmobily

mercmobily Jun 17, 2015

  1. You don't want to end up like this
  1. You don't want to end up like this
@Fishrock123

This comment has been minimized.

Show comment
Hide comment
Member

Fishrock123 commented Jun 17, 2015

^ cc @mikeal, @piscisaureus, & @rvagg I guess.

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Jun 17, 2015

Member

Sure, transferring an asset is simple but this is an asset that has been on the books of a company for 5 years while it has done all the things you would expect it to do (raise money, acquire lines of credit for hardware, etc). Joyent is not in a position where it can transfer the ownership of the mark (I'm sure they'd prefer it as the way the deal has to be structured they are stuck with the legal bill of enforcement while the foundation administers the conditions of use). I share the concerns around prior arrangements of this nature but you'll notice that many of the companies you note were unhappy with prior arrangements are members of the Node Foundation and they worked hard to make sure this arrangement did not have the same problems prior arrangements did. I'm not a lawyer, but I'm confident that the lawyers from companies suffering from prior arrangements did a good job of protecting us from those same problems. That doesn't mean we might not have new problems of our own some day, but I'm not worried about having the same problems you've noted.

The new policy seems just as problematic as the previous one, which as I understand it caused the whole iojs/node split in the first place.

The new policy allows the foundation (an independent body, not a single company) to approve uses of the mark. That is much different from the previous policy. If you're looking for a policy that doesn't require any approval for uses of the mark I'm afraid you're out of luck as trademark law doesn't really allow that.

The io.js fork was primarily motivated by governance issues. Joyent had full control over governance changes because it owned the assets (domain name, trademark, etc) so you could say the trademark was a part of that but the much bigger issue was that the contributors to node.js weren't in a position to run node.js. That has been resolved. Also note that the other assets (domain name, twitter handle, etc) should be transferred to the foundation outright.

Member

mikeal commented Jun 17, 2015

Sure, transferring an asset is simple but this is an asset that has been on the books of a company for 5 years while it has done all the things you would expect it to do (raise money, acquire lines of credit for hardware, etc). Joyent is not in a position where it can transfer the ownership of the mark (I'm sure they'd prefer it as the way the deal has to be structured they are stuck with the legal bill of enforcement while the foundation administers the conditions of use). I share the concerns around prior arrangements of this nature but you'll notice that many of the companies you note were unhappy with prior arrangements are members of the Node Foundation and they worked hard to make sure this arrangement did not have the same problems prior arrangements did. I'm not a lawyer, but I'm confident that the lawyers from companies suffering from prior arrangements did a good job of protecting us from those same problems. That doesn't mean we might not have new problems of our own some day, but I'm not worried about having the same problems you've noted.

The new policy seems just as problematic as the previous one, which as I understand it caused the whole iojs/node split in the first place.

The new policy allows the foundation (an independent body, not a single company) to approve uses of the mark. That is much different from the previous policy. If you're looking for a policy that doesn't require any approval for uses of the mark I'm afraid you're out of luck as trademark law doesn't really allow that.

The io.js fork was primarily motivated by governance issues. Joyent had full control over governance changes because it owned the assets (domain name, trademark, etc) so you could say the trademark was a part of that but the much bigger issue was that the contributors to node.js weren't in a position to run node.js. That has been resolved. Also note that the other assets (domain name, twitter handle, etc) should be transferred to the foundation outright.

@cusspvz

This comment has been minimized.

Show comment
Hide comment
@cusspvz

cusspvz Jun 17, 2015

Contributor

The new policy allows the foundation (an independent body, not a single company) to approve uses of the mark. That is much different from the previous policy.

👏

Contributor

cusspvz commented Jun 17, 2015

The new policy allows the foundation (an independent body, not a single company) to approve uses of the mark. That is much different from the previous policy.

👏

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Jun 19, 2015

Member

Just to echo Mikeal's remarks: the new trademark policy grants the
foundation full freedom to use and manage the node.js trademark. While the
mark is owned by joyent, it is fully managed by the foundation via a
perpetual, non-revokable license. The language referencing joyent is not
only appropriate, it's respectful of the fact that joyent is the company
that brought node.js forward.
On Jun 17, 2015 12:04 PM, "Mikeal Rogers" notifications@github.com wrote:

Sure, transferring an asset is simple but this is an asset that has been
on the books of a company for 5 years while it has done all the things you
would expect it to do (raise money, acquire lines of credit for hardware,
etc). Joyent is not in a position where it can transfer the ownership of
the mark (I'm sure they'd prefer it as the way the deal has to be
structured they are stuck with the legal bill of enforcement while the
foundation administers the conditions of use). I share the concerns around
prior arrangements of this nature but you'll notice that many of the
companies you note were unhappy with prior arrangements are members of the
Node Foundation and they worked hard to make sure this arrangement did not
have the same problems prior arrangements did. I'm not a lawyer, but I'm
confident that the lawyers from companies suffering from prior arrangements
did a good job of protecting us from those same problems. That doesn't mean
we might not have new problems of our own so me day, but I'm not worried
about having the same problems you've noted.

The new policy seems just as problematic as the previous one, which as I
understand it caused the whole iojs/node split in the first place.

The new policy allows the foundation (an independent body, not a single
company) to approve uses of the mark. That is much different from the
previous policy. If you're looking for a policy that doesn't require any
approval for uses of the mark I'm afraid you're out of luck as trademark
law doesn't really allow that.

The io.js fork was primarily motivated by governance issues. Joyent had
full control over governance changes because it owned the assets (domain
name, trademark, etc) so you could say the trademark was a part of that but
the much bigger issue was that the contributors to node.js weren't in a
position to run node.js. That has been resolved. Also note that the
other assets (domain name, twitter handle, etc) should be transferred to
the foundation outright.


Reply to this email directly or view it on GitHub
#978 (comment).

Member

jasnell commented Jun 19, 2015

Just to echo Mikeal's remarks: the new trademark policy grants the
foundation full freedom to use and manage the node.js trademark. While the
mark is owned by joyent, it is fully managed by the foundation via a
perpetual, non-revokable license. The language referencing joyent is not
only appropriate, it's respectful of the fact that joyent is the company
that brought node.js forward.
On Jun 17, 2015 12:04 PM, "Mikeal Rogers" notifications@github.com wrote:

Sure, transferring an asset is simple but this is an asset that has been
on the books of a company for 5 years while it has done all the things you
would expect it to do (raise money, acquire lines of credit for hardware,
etc). Joyent is not in a position where it can transfer the ownership of
the mark (I'm sure they'd prefer it as the way the deal has to be
structured they are stuck with the legal bill of enforcement while the
foundation administers the conditions of use). I share the concerns around
prior arrangements of this nature but you'll notice that many of the
companies you note were unhappy with prior arrangements are members of the
Node Foundation and they worked hard to make sure this arrangement did not
have the same problems prior arrangements did. I'm not a lawyer, but I'm
confident that the lawyers from companies suffering from prior arrangements
did a good job of protecting us from those same problems. That doesn't mean
we might not have new problems of our own so me day, but I'm not worried
about having the same problems you've noted.

The new policy seems just as problematic as the previous one, which as I
understand it caused the whole iojs/node split in the first place.

The new policy allows the foundation (an independent body, not a single
company) to approve uses of the mark. That is much different from the
previous policy. If you're looking for a policy that doesn't require any
approval for uses of the mark I'm afraid you're out of luck as trademark
law doesn't really allow that.

The io.js fork was primarily motivated by governance issues. Joyent had
full control over governance changes because it owned the assets (domain
name, trademark, etc) so you could say the trademark was a part of that but
the much bigger issue was that the contributors to node.js weren't in a
position to run node.js. That has been resolved. Also note that the
other assets (domain name, twitter handle, etc) should be transferred to
the foundation outright.


Reply to this email directly or view it on GitHub
#978 (comment).

@mercmobily

This comment has been minimized.

Show comment
Hide comment
@mercmobily

mercmobily Jun 19, 2015

@jasnell Are you saying that the reasons why the trademark isn't transferred is for the language referencing the trademark, where Joyent is perpetually included? I am asking because all Mickeal mentioned was the difficulty in handing it over, rather than the wording of the reference to the trademark that will "respectfully" include Joyent.

I think it's great that Joyent started node, and that their name will be in history no matter what.

@jasnell Are you saying that the reasons why the trademark isn't transferred is for the language referencing the trademark, where Joyent is perpetually included? I am asking because all Mickeal mentioned was the difficulty in handing it over, rather than the wording of the reference to the trademark that will "respectfully" include Joyent.

I think it's great that Joyent started node, and that their name will be in history no matter what.

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Jun 19, 2015

Member

No, I'm not saying that was the reason ownership wasn't transferred, just
that the exact ownership isn't important. The foundation is managing the
trademark now.
On Jun 19, 2015 8:07 AM, "Tony Mobily" notifications@github.com wrote:

@jasnell https://github.com/jasnell Are you saying that the reasons why
the trademark isn't transferred is for the language referencing the
trademark, where Joyent is perpetually included? I am asking because all
Mickeal mentioned was the difficulty in handing it over, rather than the
wording of the reference to the trademark that will "respectfully" include
Joyent.

I think it's great that Joyent started node, and that their name will be
in history no matter what.


Reply to this email directly or view it on GitHub
#978 (comment).

Member

jasnell commented Jun 19, 2015

No, I'm not saying that was the reason ownership wasn't transferred, just
that the exact ownership isn't important. The foundation is managing the
trademark now.
On Jun 19, 2015 8:07 AM, "Tony Mobily" notifications@github.com wrote:

@jasnell https://github.com/jasnell Are you saying that the reasons why
the trademark isn't transferred is for the language referencing the
trademark, where Joyent is perpetually included? I am asking because all
Mickeal mentioned was the difficulty in handing it over, rather than the
wording of the reference to the trademark that will "respectfully" include
Joyent.

I think it's great that Joyent started node, and that their name will be
in history no matter what.


Reply to this email directly or view it on GitHub
#978 (comment).

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Jun 19, 2015

Member

The reason you have to, in very few but noticeable circumstances, put a trademark notice referencing the owner is due to trademark law itself. In some scenarios if you were allowed to do that without a notice the mark would in danger of being considered "generic" and would be lost to all of us. The reason the notice says "is a trademark of Joyent" is because it is still owned by Joyent even though it is administered by the foundation.

Member

mikeal commented Jun 19, 2015

The reason you have to, in very few but noticeable circumstances, put a trademark notice referencing the owner is due to trademark law itself. In some scenarios if you were allowed to do that without a notice the mark would in danger of being considered "generic" and would be lost to all of us. The reason the notice says "is a trademark of Joyent" is because it is still owned by Joyent even though it is administered by the foundation.

@bnoordhuis

This comment has been minimized.

Show comment
Hide comment
@bnoordhuis

bnoordhuis Jun 19, 2015

Member

I think it's great that Joyent started node

Not so much 'started' as 'acquired'. They have a great PR department though.

Member

bnoordhuis commented Jun 19, 2015

I think it's great that Joyent started node

Not so much 'started' as 'acquired'. They have a great PR department though.

@ravi

This comment has been minimized.

Show comment
Hide comment
@ravi

ravi Oct 22, 2015

@jasonwilliams200OK I just noticed your comment addressed to me (for some reason GitHub did not notify me, or I missed the notification). You wrote:

@ravi, it is considered rude to delete your comments from the thread, especially when you are tagged and answered adequately. I am reading this thread now and noticed that rather than being appreciative to people who are trying to address your concerns, you instead deleted the comments.

The above is not quite correct. One of the comments in which I provided a significant bit of my thoughts was indeed deleted, albeit not by me. I do not recall by whom, but it was likely someone moderating this issue/discussion and I am perfectly fine with that. However, I cannot have a discussion reflect a partial view of what I had written. Consequently I removed the rest of my comments.

This has nothing to do with appreciativeness. I appreciate the effort every node contributor puts into all aspects of building node.

ravi commented Oct 22, 2015

@jasonwilliams200OK I just noticed your comment addressed to me (for some reason GitHub did not notify me, or I missed the notification). You wrote:

@ravi, it is considered rude to delete your comments from the thread, especially when you are tagged and answered adequately. I am reading this thread now and noticed that rather than being appreciative to people who are trying to address your concerns, you instead deleted the comments.

The above is not quite correct. One of the comments in which I provided a significant bit of my thoughts was indeed deleted, albeit not by me. I do not recall by whom, but it was likely someone moderating this issue/discussion and I am perfectly fine with that. However, I cannot have a discussion reflect a partial view of what I had written. Consequently I removed the rest of my comments.

This has nothing to do with appreciativeness. I appreciate the effort every node contributor puts into all aspects of building node.

@nodejs nodejs locked and limited conversation to collaborators Oct 23, 2015

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.