Diffing io.js and the Node.js Foundation

[mikeal]

The foundation policy drafts are here but the sheer size and volume of documentation is a little intimidating.

In order for the io.js community to evaluate what a merger looks like we need a better way for everyone to understand what could/would change.

I'd like to use this issue to track any differences between io.js and the Node.js Foundation policies. I don't want to make any judgement calls about these differences I merely want to expose each difference so that everyone can objectively evaluate it themselves.

Summary

I'll keep this summary up to date as people find more differences and post comments.

TSC Charter

• Charter states that no more than 1/4 of the TSC can be employed by the same company. io.js currently has this at a 1/3 rule.
• Charter defines a "TSC Chairperson."
  • Chairperson holds the responsibilities that io.js' current moderator holds.
  • Chairperson represents the TSC on the foundations Board of Directors
  • Chairperson is elected by TSC using Condorcet or Single Transferable Vote
• Voting rules and consensus seeking model are identical except that a 2/3 majority is required when changing the TSC Charter and when adding/removing members of the TSC. In io.js all decisions when brought to a vote are simple majority.

  Project Lifecycle

• Lifecycle Ladder
  • In io.js there are two WG states: chartered and un-chartered. Working groups begin informally and collaborate until they are mature enough to write a charter which is ratified by the TSC.
  • In the foundation, working groups are "incubating" when they are working either unchartered or completely outside the foundation. When they write a charter they are in the "Proposal" phase until accepted and then are considered "Mature" which is identical in state to io.js' "chartered" state.
  • A final state in the Lifecycle is "Core" which has no equivolent in io.js. Once a WG reaches the core state they get a TSC seat.
• Multiple "core" projects.
  • Basically, this allows for another sizable project, like express or hapi, to join the foundation and get its own TSC at the same level as the Core TSC.
• In io.js working groups are chartered by the TSC at their discretion. While it is not done being drafted the review requirements for each state change will be documented in the lifecycle.

  Development Policy

• Guiding Principals is a project vision that is lacking in both io.js and node.js as formal documentation and is really only understood culturally.
• Collaborators
  • Describes the process: a new issue is created by a TSC member with recent contributors and the names can be challenged by other contributors the same way changes are reviewed to reach a consensus. This is the existing io.js policy but it is not formally document in io.js.
  • Explicitly states that TSC candidates be nominated from the pool of Collaborators. This has been the case in io.js but it is not explicitely stated.
• Accepting Modifications
  • Wide and well documented definition of "contribution." Similar if not identical to the io.js cultural definition but not formally documented yet.
  • All pull requests must be signed off by another collaborator. The io.js dev policy has an exception for "trivial changes" but in practice contributors (even long time ones) have been chastised for not getting a sign off. Note: the 48 - 72 hour rule still has an exception for "trivial changes."
  • Any PR that will bump the major version will be elevated to the tsc-agenda.
  • Exception to all processes for critical security vulnerabilities. Since the security policy responsibly discloses fixes they may need to be done outside of the regular public process.
  • "All Pull Requests that either fix bugs or introduce new functionality require at least one test case"
• master is the current branch. This differs from io.js' current policy but matches @chrisdickinson's proposed improvements to it.
• release branches (prior major releases) are owned by the LTS working group. io.js states that a future LTS WG will handle these kinds of releases but the branch ownership has not been addressed.
• Issue Tagging is formally documented. The tags and strategy match the current io.js practice which is undocumented.
• Release Branchs for LTS. This is totally new and has no equivalent in io.js at this time.
• Release Versioning requirements are defined for major, minor and patch. io.js simply states that "semver" is the policy without a greater definition.
• "Releases should not contain too many code changes and if the rate of code changes is high then it should correspond to an increase in the rate of releases." This matches io.js in practice but cadence is not explicitly documented.
• "Master must pass a full CI test run prior to release."
• Repository Reconciliation Plan
  • Obviously this has no equivalent in io.js because it addresses how io.js and node.js would be merged.
  • Versioning strategy would ensure that io.js and node.js do not have any version overlap.
  • A "Convergence Working Group" will define a more detailed proposal of how to merge the code and resources together.
• LTS -- TODO (I'm not familiar with the state of the LTS discussions Rod has been leading)
• Issue Workflow -- Still an open discussion, nothing concrete yet.
• Stability Policy
  • Mostly similar to io.js Stability Policy.
  • Much more attention paid to ABI compatibility.
  • Puts the ABI under the same semver major/minor/patch restrictions as the JS API
  • "Any Modification to the ABI, dependencies or Native abstractions that require a developer to modify code and then recompile is considered a backwards incompatible change that must result in a semver-major version increase." This Is not the current policy in io.js as it is currently documented but, in practice, the TC decided to float a small patch that broke ABI compatibility for a future major version release.
• Implicit vs. Explicit API Stability
  • This section describes and area that is not very well understood or documented in either io.js or node.js. The existing policies in both projects have been subjective.
  • Basically, they are trying to define what is internal API vs. external API.
  • There is also a lot of effort spent on defining exactly how many type guarantees the API is offering implicitely vs. explicitely because types are rarely if ever documented formally.
• Platform Stability -- In io.js we just sort of add platforms to CI and when they are green more often then not we start blocking releases on them. This section defines states the various platforms are in and what the stability guarantees are once they get a label.
• Dependency Stability
  • "Node.js will adopt new V8 releases as quickly as practically feasible. For LTS Releases, the version of V8 shipped must be fully functional with no regressions on all Primary Platforms." This is the io.js policy in practice but is not documented.
• "When new features in the JavaScript language are introduced by V8, there will be a semver-minor version increase." io.js has never had to deal with this, and I doubt it will ever come up because when v8 ads language features it's in a major release anyway.
• "With a few notable exceptions, the Node.js Core Library API is largely built around ES5 Language features. While there are currently no plans to do so, it is possible for post-ES5 JavaScript language features to be introduced into the Core Library API in the future." This is a little bolder than we've gotten so far in io.js, we've never actually exposed any ES6 usage, only used it a little internally.

  Other

  Trademark

Right now io.js has no trademark and as such it has no trademark policy. The foundation lawyers will be drafting a new trademark policy for node.js but it doesn't exist yet. Joyent's prior trademark policy will no longer exist.

Foundation Board of Directors

io.js is not a legal entity. Property is owned haphazardly between several individuals and a handful of companies. Such as:

• Domain name and DNS is owned by Fedor.
• Twitter is registered by Fedor but login shared with about a dozen people.
• Google Plus, Facebook, and Medium accounts by Mikeal.
• GitHub org by Colin.
• Build resources donated by various companies differing by architecture.
• Signing keys are from NodeSource (I think?)

A non-profit foundation is an actual legal entity and can own property. It is operated by the board of directors and elected executives. The board not only shares the task of administering the foundation but can, in some cases, be held legally and financially responsible for it.

In a foundation all the property is owned by the foundation (legal entity). The TSC is given autonomy to run the technical side of the project and do releases but the foundation sets the budget, administers funds, and handles all legal matters.

That means that if someone wants to sue the project they would sue the foundation, rather than Fedor (good luck he's Russian), or me, or NodeSource.

[trevordmiller]

So are io.js and Node.js going to merge? I would love to see that. I realize that io has had a lot more freedom and progression but we were just barely able to get "official" approval to use Node at my current company - slow moving, I know; Point is, the "node" name means a lot to the community and has trust and maturity behind it for managers and conservative leads; I'd love to see the innovation and contributors of io come back under the "node" umbrella to get the best of both worlds :)

[mikeal]

Ok, huge update with what I could pull out of the dev policy before I passed out :)

[mikeal]

So are io.js and Node.js going to merge?

That has not been decided. What we're trying to do here is figure out what that would actually look like and push it in a direction that is acceptable to everyone.

[rvagg]

"When new features in the JavaScript language are introduced by V8, there will be a semver-minor version increase." io.js has never had to deal with this, and I doubt it will ever come up because when v8 ads language features it's in a major release anyway.

Why is it necessarily a major release? I feel like I might have missed something about V8 bumps and major versions and was under the impression that we were only bumping major (2.0) for the next V8 upgrade because it seemed like a good chance to throw some of the semver-major changes in. But, a V8 upgrade, even introducing language features, should generally only ever be a semver-minor unless they really screwed something up. I think we've created an exception around the C++ API and Chrome isn't very likely to break JavaScript-land stuff.

[rvagg]

btw, thanks for this @mikeal, makes it so much easier to grok for those of us who are time-poor. Overall the list looks fairly manageable if this really is all there is to it.

[mikeal]

@rvagg sorry, I'll try to state that better. What I meant is, I haven't seen v8 add language features in a release that didn't break ABI from its prior stable release. The policy as stated actually says that we're only going to increase the minor on a language addition but I'm pretty sure that in practice we'll end up eating a major version bump anyway for other reasons.

[jbergstroem]

@rvagg said this makes it so much easier to grok for those of us who are time-poor.

Agree, so I apologise in advance if below should live somewhere else.

@mikeal said "Master must pass a full CI test run prior to release."

This needs to be improved:

• It limits when a release can be made since we're fighting longstanding test failures on some platforms. It additionally encourages hiding issues under the rug so a release can be made.
• It prohibits new platforms to be added to CI. We'd essentially avoid adding OpenBSD because it'd add 10 test failures that would in turn push a new release indefinitely.

Another small difference I've noted is that nodejs seems to prefer Reviewed-By as their first "meta" in the commit message while we prefer PR-URL. I would suggest changing the order in the document as well as stating order should follow the list (pr-url to reviewers to fixes).

Finally, I haven't seen anything about how different commits should land in different branches. For now, io.js handled it by PR'ed merge-commits but I doubt that'll scale. Labels could simplify the life of the person merging, but who decides what goes where and when?

[mikeal]

It limits when a release can be made since we're fighting longstanding test failures on some platforms. It additionally encourages hiding issues under the rug so a release can be made.

Is this still true in io.js? I was under the impression that on primary platforms all the tests pass.

It prohibits new platforms to be added to CI. We'd essentially avoid adding OpenBSD because it'd add 10 test failures that would in turn push a new release indefinitely.

The "Platform Stability" section tries to address this. Basically, you can add OpenBSD to CI, and it'll run regularly, but it won't block a release.

[jbergstroem]

Is this still true in io.js?

Yes and no. Jenkins tells us there's three failing slaves on the last run. Since some are only reproducible within a Jenkins environment it's arguably classified as heisenbugs. With language like that (even if platform stability addresses cases like new platforms) a critical bug fix release shouldn't go out even if the CI itself is to blame.

The bigger picture is great though. We're in better shape than ever and will soon be 100% green (jenkins-speak: blue) -- but I'd rather be slightly less strict than "break the rules" when we end up in that situation.

[mikeal]

@jbergstroem interesting, can you log an issue on the dev-policy repo about that.

[jasnell]

@mikeal ... heh, I just put a new PR that would update some of the dev-policy details (simplify based on feedback). It would likely reduce some of the deltas. Tomorrow I'll go through your list above in detail and see if I can call out the possible changes.

https://github.com/jasnell/dev-policy/pull/59

[jasnell]

The suggested edits in the PR simplify some of the platform stability issues by collapsing the notions of "primary" and "secondary" into just "supported". I think it's an improvement but I'm operating on little sleep so additional eyes on it would be appreciated.

[jakerella]

• Multiple "core" projects.
  • Basically, this allows for another sizable project, like express or hapi, to join the foundation and get its own TSC at the same level as the Core TSC.

I'm curious if there is any movement to include running automated tests on such "sizable" projects prior to a major or minor release (probably not needed for "patch")? Obviously the representatives of these projects could run them on their own, but would there be benefit to the community in providing automated test running for those larger projects? It wouldn't necessarily have to be blocking, perhaps just reported and available to any/all who might be interested in that. (Again, I'm thinking prior to a release, not post-release... By that time the projects should already be pulling in the newest and testing, but it's too late at that point to alter the release.)

[nmn]

All-around it all sounds pretty good. I'm slightly concerned about only two points here:

• Voting rules and consensus seeking model are identical except that a 2/3 majority is required when changing the TSC Charter and when adding/removing members of the TSC. I hope this won't be a roadblock. Maybe break the charter into core and other?
• With a few notable exceptions, the Node.js Core Library API is largely built around ES5 Language features. While there are currently no plans to do so, it is possible for post-ES5 JavaScript language features to be introduced into the Core Library API in the future. I think this only feasible if Node.js and io.js either merge completely, (I don't know why they wouldn't) or if the at least maintain some kind of API compatibility.

The future seems to be good for for node and io.js

[jasnell]

Ok, so if you go take a look at the updated dev-policy draft, I've refined and simplified the LTS language and took out the troublesome strawman LTS process. The overall document is much more straightforward. There are also edits to the Platform Stability and Build stability pieces.

[jasnell]

@jakerella there is work underway to add automated ecosystem testing in.

@jbergstroem as @mikeal suggests, it would be helpful to have an issue filed in the dev-policy issue tracker. It sounds like we may need to make some allowances for some failing tests but we'll need to craft some language around it.

[mikeal]

@nmn

I hope this won't be a roadblock. Maybe break the charter into core and other?

So, the io.js governance policy is intermingled with the dev policy and some other process definitions. In the foundation the TSC Charter is "as small as possible" because it's the only document that requires the board to approve changing it as a point of process. In a way, the charter is already "core" and everything else is in the dev policy (which is sizable) and can be changed more easily and under the normal majority voting rules.

[serapath]

In a foundation all the property is owned by the foundation (legal entity)

So all these "assets" will in the future be owned by the foundation:

• Domain name and DNS is owned by Fedor.
• Twitter is registered by Fedor but login shared with about a dozen people.
• Google Plus, Facebook, and Medium accounts by Mikeal.
• GitHub org by Colin.
• Build resources donated by various companies differing by architecture.
• Signing keys are from NodeSource (I think?)

In addition:

The TSC is given autonomy to run:

• the technical side of the project and do releases but
• the foundation sets the budget, administers funds, and handles all legal matters.

So not only will the foundation own the assets, the board of directors, which runs the foundation, will be able to change their mind in the future and lobby (using budget restrictions, their power through administration of funds) to disempower the TSC.

Cant the TSC be the board of directors and hire managers to do all the formal stuff with which the TSC doesnt want to be concerned? Also software to automate processes could be written so that makes the "boring administration" part as simple as possible.

Personally, by now I strongly prefer the name "iojs". A budget might have not been necessary in the past and in the future, efforts could be made to have a crowdsourcing (donation based) approach, where people can just donate for certain features or "github issues" to be solved.

Something, that doesnt formally empower people, but changes are being made because all sides agree.

[jasnell]

@serapath ... one point that seems to be confusing for folks is this notion that the board will somehow be able to use it's management of the foundation budget to somehow control the TSC's decision making. It should be emphasized that the operation of the TSC is, in no way, dependent on the budget. The budget is intended to be used for things like paying for marketing, infrastructure, conferences, etc. One could argue, I suppose, that the board could refuse to pay for some bit of infrastructure needed by the project but then the board would very quickly end up with a revolt on their hands, which helps no one.

It should also be pointed out that the board does not get a say on who is on the TSC or who gets to become a Collaborator. Those decisions are solely in the hands of the TSC itself. The only way for a company to influence the projects direction is to roll up their sleeves and become active Collaborators just like everyone else.

[serapath]

Ok, to put it another way. Way would you give some kind of board and funding EXCLUSIVE formal permission to decide whether they give funding to certain infrastructure or not? (Especially when the board or foundation will use their "exclusive access" to the TSC to lobby for the interest of companies or other particular interest?

I know, those "particular interest groups" will approach anyway, but it's not necessary to give them some special communication access.

Why not make the TSC and all its WGs something open, that anyone could approach in an indiegogo like approach or maybe pledgebank

The people actively engaged in open source development create something thats very beneficial to the community at large. Now some dudes surrounding joyent, the foundation and I dont know which particular interest, want an exclusive channel to have some power indirectly granted by all the open source developers that grant them this exclusive access.

It is nothing that I feel is compatible with the core values of iojs and things should be open, transparent and especially create an environment, in which everyone is equal, can contribute and try next to everyone else to succeed and create value.

We do not need certain people, many of them not even involved in creating open source code, to have exclusive access to those who are currently in "high demand" because of their exceptional skills and awesome contributions.

That's my opinion.

[jasnell]

How does the board have "exclusive" access to the TSC? I'm not even certain what that means. The TSC decides what tools and infrastructure it chooses to use based on the technical needs of the project. They send the requirements to the board if funding is required. The board could, I suppose make suggestions but it's up to the TSC to decide what tools it wants. And again, if the board ignores the TSCs request, they'd be facing a revolt so what's the gain? Furthermore, there are conflict of interest checks built into the governance process to help prevent mismanagement.

I'm not sure where you're coming up with this "special communication" idea. On Apr 15, 2015 2:16 PM, "serapath" notifications@github.com wrote:

Ok, to put it another way. Way would you give some kind of board and funding EXCLUSIVE formal permission to decide whether they give funding to certain infrastructure or not? (Especially when the board or foundation will use their "exclusive access" to the TSC to lobby for the interest of companies or other particular interest?

I know, those "particular interest groups" will approach anyway, but it's not necessary to give them some special communication access.

Why not make the TSC and all its WGs something open, that anyone could approach in an indiegogo http://www.indiegogo.com like approach or maybe pledgebank http://pledgebank.com

The people actively engaged in open source development create something thats very beneficial to the community at large. Now some dudes surrounding joyent, the foundation and I dont know which particular interest, want an exclusive channel to have some power indirectly granted by all the open source developers that grant them this exclusive access.

It is nothing that I feel is compatible with the core values of iojs and things should be open, transparent and especially create an environment, in which everyone is equal, can contribute and try next to everyone else to succeed and create value.

We do not need certain people, many of them not even involved in creating open source code, to have exclusive access to those who are currently in "high demand" because of their exceptional skills and awesome contributions.

That's my opinion.

— Reply to this email directly or view it on GitHub https://github.com/iojs/io.js/issues/1416#issuecomment-93571871.

[mikeal]

@serapath

It's quite easy to theorize new models for funding projects and compare those idealistic models with any concrete proposal.

We are not the first open source project to have these kinds of needs. We talked to many projects about how they resolved similar problems a year ago and found a model that is working for several of them (we also found a lot of projects that didn't like their arrangement and steered clear of those).

The TC does not want to handle marketing, legal, etc directly. I've been involved more directly in this stuff than anyone and the idea of increasing our direct personal responsibility in these areas is not something I would be excited about or recommend. That is not to say that the TC does not want any influence or participation in these kinds of decisions, they just don't want to be responsible for the directly, and this foundation model is the most preferable.

The Node.js Foundation's offer is compelling because it doesn't alter our current processes and lets us continue running the project as we've found most effective and brings the node.js assets to the table. The Linux Foundation has a lot experience doing "the rest" of the foundation work and they've put together something pretty good that we need to seriously consider and we aren't going to compare that against an entirely unproven proposal that requires we do a ton of extra work that takes time away from working and releasing the platform.

It's beneficial to rely on the foundation's proven, and well funded, approach to tackling legal and PR so that we can continue to be bold and iterate on new models of project governance, collaboration models, and community building.

[mikeal]

@serapath you may also be interested in a previous comment I made about board influence https://github.com/joyent/nodejs-advisory-board/pull/30/files#r27698737

[serapath]

I'm not convinced of the necessity of having a board, but I'm too far away to understand the details. If you say it'll be beneficial, then I believe that for now.

It's a bit sad, that the TC does not want to be responsible and lead and build the tools to automate the decision and management processes, but maybe that might happen in the future and for now it's nice to have the freedom to experiment a bit more and have a hopefully responsible board in the meantime.

In the end, what will happen is what you and the other current members of the TC agree upon. The rest of us will maybe comment or just silently observe. If it will work out it will work out, if not, things can be renegotiated and as long as it will continue to be possible to fork again, chances are everything will actually work out fine.

[mikeal]

I'm not convinced of the necessity of having a board

A board is a legal requirement for having a non-profit.

that the TC does not want to be responsible and lead and build the tools to automate the decision and management processes

This isn't a technical problem. If it were then LegalZoom would have a way for us to setup and manage the non-profit. Non-profit accounting and administration is somewhat specialized and the information not entirely accessible to everyone. This comes up whenever someone says "just start a foundation." It's not that simple, it's the opposite of simple, because the government really doesn't want people starting them.

By comparison getting a company and handling the accounting is quite easy and straightforward, I have an LLC that I use to run the conferences under and it's a fair amount of work but was something I could figure out and find a lot of relevant documentation on. I clicked some buttons on LegalZoom and had a license in a few hours and a bank account a week later. That's because the government wants people to start businesses. Unfortunately having a for-profit entity owning project assets is what got us in this mess in the first place so this isn't an option.

[serapath]

I know, I meant I'm not convinced of having a non-profit, but I understand. Instead of having a complex legal entity, each individual could be encapsulated in some standardized legal container and contracts could be used to have a more flexible composable way of structuring legal relations the way people want. There are many approaches towards "cryptocontracts", some are based on blockchains, (e.g. codius or ethereum, but it's easier to do the foundation now instead of figuring out how to do legal entities the node way and automate as much bureaucracy as possible.

What you are telling in regard to the LLC, I'm trying the same with an UK Ltd. right now, after deciding against the german "GmbH" (which is what people use where I'm from) - because of too many legal complications. I hope a Ltd. can be enough of a "standard vehicle" now, to start thinking about setting up an orchestrated network of contracts between them, accessible through APIs.

I don't understand the difference between "Non-Profit and For-Profit" anyway, feels to me like an accounting trick.

[serapath]

In UK there is quickfile and in the US you have waveapp. Both don't charge. Waveapp has plans to make an API but probably phantomjs could be used to get there in the meantime. Quickfile already has an API. After a lot of searching I found a couple of accountants in the UK that offered to take care of all the filing requirements for a flat rate of 20 GBP a month, but the accounting rules around certain common business models can be researched and open sourced and modules can be written to automate that too and connect to electronic government interfacces.

[serapath]

@jasnell

How does the board have "exclusive" access to the TSC? I'm not even certain what that means.

That just means, that members of the board or in general members of the foundation or that are introduced through the foundation can talk to members of the TSC and WGs more easily than some "random" person or organisation who approaches the TSC directly, just because through means of the foundation they will have more contact in general.

The TSC decides what tools and infrastructure it chooses to use based on the technical needs of the project. They send the requirements to the board if funding is required.

So they will do that instead of publishing it to everyone to get some funding from everyone who is willing to support it.

The board could, I suppose make suggestions

Yes and that is the exclusiveness that I talk about, compared to every other interested person on the planet that would like to make "suggestions" :-)

[rlidwka]

"Any Modification to the ABI, dependencies or Native abstractions that require a developer to modify code and then recompile is considered a backwards incompatible change that must result in a semver-major version increase."

This could be a good advice in general, but I'm afraid such exact wording in the official documents will only give an excuse to ship out node.js with 2 year old V8 engine. We've been there before.

[Fishrock123]

@rlidwka I'd agree, but as per yesterday's TC meeting, that is also the consensus for io.js, with the solution being, just do a major every v8, more or less.

[rlidwka]

@Fishrock123 , then it contradicts this clause:

"When new features in the JavaScript language are introduced by V8, there will be a semver-minor version increase."

If we do major every v8, all new JS features will be majors as well. You can't bring JS without updating v8.

I'm okay with switching to "browser versioning system". But updating v8 until it breaks ABI, then holding on that version several months/years until major release is really not cool.

[Fishrock123]

Nothing much was discussed last week. Re-add the tc-agenda label when more info is available maybe.

[Fishrock123]

Closing in favor of #1664 (progress yay!)