Draft Node.js Foundation Technical Governance Documents

[mkdolan]

This is Mike Dolan and Scott Nicholas from The Linux Foundation and we've been working with Bert Belder, James Snell, Mikeal Rogers and TJ Fontaine to create an initial draft of Node.js Foundation's technical governance documents. We used our standard Linux Foundation governance templates for foundations we've setup and inserted the io.js governance terms. The io.js governance terms were a good starting point to begin a discussion for moving forward. All members of the Node.js and io.js community and the advisory board are welcome and encouraged to post comments, questions and suggestions here. Our goal is to collaboratively develop a technical governance model that works to bridge the communities today and also set up a framework that will help guide future members of the community decades from now.

There are governance topics and details we often address in our projects that were not explicitly covered in any existing Node.js or io.js governance materials. Examples include whether/how to incubate new projects, connecting the technical committee with the Foundation's Board, and a few other areas you're likely to notice as you read through the materials I've posted. You may also notice gaps or details that have been addressed, but which are not reflected in our documents. We often set up a structure to capture the elements that a Board would approve in the formation and allow the TSC to determine the operational and logistic details through a development process that would be documented for the technical community. This is a long way of saying the technical documents I've shared are the essential elements to address to setup a TSC under a Foundation and leave details best determined by a TSC to the TSC.

There are three key documents that are used to build our typical technical governance framework.

A. TSC Charter.

The TSC Charter (which the Board approves) establishes a Technical Steering Committee under the Foundation. This is a formal document approved by the Board to set up the TSC and make it an official committee. The TSC will also be addressed in the Bylaws for the Foundation but at a very high level. This allows the TSC to be updated later without the scrutiny required of a change in the organization's Bylaws. The Charter sets up the committee, identifies who is eligible to participate in the committee and sets a framework for what the committee should do and how it will govern itself. The operational details and logistics are left to the TSC to determine in a development process.

B. TSC Policy

The TSC Policy (which the Board approves) sets the scope of the TSC and sets principles that the TSC should adhere to or abide by in the technical collaboration effort. This includes high level principles the community will be expected to adhere to and follow. The Policy is important to capture the high level principles, but should not be too detailed and become a burden or micro-manage how the TSC collaborates.

C. Project Lifecycle

This is perhaps a new concept as it relates to Node.js or io.js governance though it seems a few members of the community have been thinking about models for how projects enter a Foundation, mature and eventually become part of the core Node.js release. There may also be additional projects that will wish to participate under the Foundation. You'll see our project lifecycle terms enter the TSC Charter and TSC Policy documents in various sections to segment how projects of various maturity are treated and to differentiate between core subsystems/modules and other projects that may wish to participate under the foundation. A critical goal of the Project Lifecycle is to establish a mechanism to encourage new, innovative projects that need time to incubate and prove their value while establishing a roadmap and path for those projects to mature within the Foundation and within the release process of the project. It also attempts to create a home for additional related libraries, modules, etc that are looking for a “home” for their project.

As I mentioned above, the documents being committed are a starting point for the discussion and we encourage everyone interested in this subject to contribute your thoughts and suggestions for how we could improve them. If you like them as-is and would like to just voice general support for the direction they are going in, a +1 would be encouraged as well so we can gauge whether members of the community like the approach.

[piscisaureus]

@mkdolan I would suggest to give all the files a '.md' extension so github renders them properly.

[Fishrock123]

So, do "Projects" replace io.js Working Groups?

The rules here seem very restrictive for those.

[mikeal]

@Fishrock123 the short answer is "yes," Projects should replace io.js working group definitions. That said, there's a lot of work to be done to reconcile this definition with the io.js working group definition, which I'll be working on soon.

The LF has a pretty standard document for projects under a foundation which they have adapted as close as they can do our needs here. io.js Working Groups have been formed and a somewhat formal definition defined in an environment where we have no institutional or financial support. In contrast, this definition comes from the point of view of an institution which has certain liabilities (legal and financial) over any work that happens under its "umbrella."

I'll be preparing a pull request to this document (after it is merged) which tries to reconcile the concerns of the foundation with the lessons learned in io.js about working groups which can be a charter that supports all the existing io.js working groups as well as future projects.

[Qard]

Certainly the tracing working group doesn't really fit well in the boundaries of a project. We're very research-oriented currently, and don't have a clearly-defined task beyond "make tracing better".

The way "projects" are currently defined is not really conducive to research-oriented work or any forward-thinking effort, like NG that has no set "shipping" criteria.

[Fishrock123]

I'll be preparing a pull request to this document (after it is merged)

@mikeal does the document being pulled in have any significance to anything? I'd think those changes should be made here?

[mikeal]

@Fishrock123 my expectation is that this PR will be merged shortly and that there will be a period of time where we all make comments and alterations to those documents before they become official. That's why there are giant headings at the top of each document stating that they are drafts for public comment. As a practical matter it's easier to merge this and then discuss additional pull requests here than to send changes to a fork.

[ghost]

I couldn't find one "open governance" once in this page. Did I screw up or did no one really mentioned it?

[Fishrock123]

I'd like to also see how the Board's governance will run, although I suppose that may come in a separate PR?

[mikeal]

@Fishrock123 I've seen the foundation membership agreements before, they were worked out before the announcement at Node Summit although I don't know if/where they are posted publicly. It's a pretty standard open source 501(c)6 where corporate membership is set at 3 levels, the top getting a board seat and the other 2 levels electing a certain number of board seats to represent them.

[mikeal]

@mrseth the TSC charter describes an open governance model, it probably doesn't say the words "open governance" because it would be redundant.

[mikeal]

@Qard yup, I'll be working on a big PR to revise the project life cycle so that it can work for our existing io.js working groups as well as future projects/wg's we can imagine wanting to house in the foundation.

[mkdolan]

To the point about stating "open governance" explicitly, our projects at the LF normally assume that to be the case. We have in Section 1 what I have considered to be a statement of operating under an open governance model. I understand this community may be operating in a different political context at the moment, and while I personally think it's redundant given the terms in the document define the open governance model, we could insert the words explicitly in Section 1 if it's helpful to people.

[mikeal]

I've got a draft of a new Project Lifecycle off in a branch. I'd like to send it as a PR as soon as this is merged but until then:

https://github.com/mikeal/nodejs-advisory-board/blob/new-lifecycle/governance-proposal/TSC-Project-Lifecycle.md

The biggest change is to the incubation and proposal phases. Basically, "Incubation" has two paths, either "bootstrapped" (inside the foundation) or a project matures outside the foundation to a significant point and then would like to join. In both cases incubation happens before a proposal or charter is defined. This allows us to experiment and create projects with less barriers but keep them at arms length (provisional status can be shut down at any time, no monetary or legal resources committed) and allow them to mature before we write the charter.

In the io.js working groups we've found that it's best to remove barriers to people forming groups and getting work done and that it's much better to have groups write a proposal/charter after they've been doing work successfully.

This change to the incubation phase actually reduced the number of levels and reviews, simplifying the process quite a bit.

There are some other smaller edits and changes in the review processes that are trying to bring it more in line with the working groups we have in io.js which aren't strictly code projects with their own releases.

[ghost]

What will happen to current Working Groups?

[mikeal]

@BenjaminProgram

I'm working on a PR to this that brings the Project Lifecycle in-line with Working Groups enough that we could migrate them over under that structure.

[piscisaureus]

I've merged this PR so people can propose more updates as individual pull requests. For those who are not so familiar with github: a list of open pull requests can be found here

[luke-john]

These are starting to look good @mkdolan. Thank you for working with the various groups to help make this happen.

I have a few questions;

Is it possible for the bylaws to contain a provision that allows the TSCs board representative to veto any motion that is at odds with the Technical Community?

Would it be possible for control of the brand and any copyrights to be held in such a way that if the TSC decided to leave the foundation they would remain in control of them. Requiring the Foundation to re-brand itself.

Will the foundations bylaws be made public in the same way as the other draft documents for community feedback?

[ghost]

I can't believe how bad this is looking for io.js.

[jasnell]

@mrseth care to explain your concern?

[ghost]

@jasnell It restricts way too much the developers while offering nothing that io.js is lacking at the moment. People are promising funds, power, users but NONE of that made a difference for node.js. It doesnt matter how many money and users you have if you are being smothered by clueless C level executives like the node foundation is going to do. On the meanwhile 1.7 was just released, io.js keeps increasing the distance between it and node and shows no signs of slowing down.

[mbonaci]

I agree with @mrseth. What does Joyent bring to the table except few enterprise customers (no, this is not a rhetorical question, I'd really like to get an answer in a form of bulleted list)? We are all aware of their "Node stewardship" track record.

I also cannot fathom why is IBM given a board seat (don't tell me node-red or AIX)? I was unfortunate enough to be working with IBM products (from the Collaboration and ECM portfolios, e.g Datacap, FileNet, Domino, WebSphere, DB2, ...) for a few years and let me tell you, the products are nothing short of a terrible bloatware, all closed/proprietary (of course), licensing is incomprehensible unless you have a dedicated person that deals only with that. Vendor lock-in is the phrase they like the most. What can we learn from IBM? Let's face it, besides couple of worthy efforts (Navigator (Dojo), Orion) it's a dinosaur.

Don't get me started on their release cycles. E.g. this shameful document: ftp://public.dhe.ibm.com/software/java/docs/IBMSDKforNodejs.pdf is IBM SDK for Node.js v1.1 documentation (from 02/2014, with apparently no new versions). TLDR; inside is this. And they have the nerve to sit on the board.

IO.js track record is impeccable. Versions are flying out, V8 is finally caught up with, new language features are here, working groups turned out to be so successful, that they are becoming a new model for large-scale modular software development ("one thing and one thing well"), @rvagg's "give ownership"-style package management is spreading, ...

Given all that, IMHO, in order to buy into foundation the model would have stay exactly the same as it is (at IO.js). The board would have to be under TC, not the other way around, with only one goal: to serve and support TC. I don't care what those bodies are called or what Linux foundation's rules say, this is how it's supposed to be. Reconciliation terms are upside down.

@mikeal, in my eyes you are the primary reason for IO.js success and the whole community has faith in you. Please don't let these corporate-style paperwork-bullying make you ease up on your principles. Don't back off one bit from the original requirements for going into foundation.

Also, the way @tjfontaine is downplaying IO.js made me a bit uncomfortable. Like "We were going to do the foundation thing anyway". And again, selling the "stability story", which couldn't be further from the truth.

[mikeal]

I'm working to ensure that the progress we've made in io.js is preserved in the Node.js Foundation were we to decide to move there. There's a lot of documents that define the policies for the foundation and for io.js so I've been working on a better summary that diffs the proposed policies of the foundation with those of io.js.

https://github.com/iojs/io.js/issues/1416

As it stands I can't find a difference between them that is objectionable. In fact, this whole process has lead to a lot of existing io.js' practices being documented and more well defined.

We've wanted a foundation and have been actively pursuing it for a year. In fact, we advocate for a foundation structure this way and bootstrapped with the help of the Linux Foundation. It exists now, and it has the node.js IP in it. Now what we need is the policies, practices and governance that allow us to run io.js successfully and, so far, that's what we've been getting.

[jasnell]

@mbonaci and @mrseth ... I'm not going to bother attempting to change either of your minds here... but, I would just point out that the IBM SDK for Node.js is simply IBM's straight port of Node.js onto Z and Power systems with a very small amount of additional debugging mechanism bolted in. It's currently on v0.10.38 (http://www.ibm.com/developerworks/web/nodesdk/). Our team has been working with V8 first to ensure that V8 will run on System Z and ppc systems. We use it directly within our BlueMix environment which is, of course, based on the OpenSource CloudFoundry and OpenStack projects.

Perhaps a more productive question for the two of you (and others) would be: do you see anything particularly troubling in the draft documents themselves? Specifically, things that would be actively harmful or disruptive to the node.js/io.js community as a whole. So far the drafts have been reviewed by members of both project TC's but community review is absolutely helpful.

[Burstaholic]

As long as the foundation's board has legal responsibility for the project, it has to be the final authority. That's just the way the legalities work. It's not feasible for the board to be legally responsible for something it has no authority over (i.e. the TSC).

You could argue against the whole idea of a foundation, but I think that has been pretty well hashed out.

I agree that strong community representation on the board is a good idea for many reasons, including counterbalancing specific corporate interests, and discussion on how exactly to ensure that needs to move forward.

[ghost]

A recurring argument that I read is that io.js would be benefited, despite the compromises, by a reconciliation.
That it would increase adoption, because it would then have "legitimacy" in the eyes of managers taking decisions that are unable of mathematical and logical thinking. Because if they were capable, then it wouldn't be necessary to hide behind names and say "b-but all the big kids are doing it", we have the data to prove the superiority of io.js. Adoption that didn't keep node.js from becoming stagnant and causing io.js to born, mind you. But have these same people tried to actually fight for these changes in these companies that they don't even own? If they care SO MUCH about the technology being adopted, have they stood to what they believe to be the best course of action and put themselves in the line? Have they considered looking for a new job in a company that isn't stuck with dated technologies? Have they considered starting their own companies? No, of course they haven't. After all is much safer to just sit doing nothing and wait while others bend to the will of the ignorant and the coward until the tool is nothing but a shadow of it could have been. What is the meaning of adopting a technology if you have corrupted and damaged it for doing so? Why must everyone suffer from one's lack of spirit for promoting what is right and not what is acceptable in the eyes of the ignorant? Io.js' development proved time and again that it just doesn't need whatever a reconciliation has to offer, that is a fact. Why must it have it's wings clipped for those who can't just accept how better it is and adopt it? If you care so much about it's adoption then fight for it, don't ask for it to be brought down to it's knees.

[Morgul]

@mrseth Your position seems rather clear; you feel the compromises being made are to the detriment of io.js, and see no value in the proposed benefits. Is that an accurate summary?

While I personally disagree with your arguments against the benefits (your proposing the sisyphean task of changing a prevailing corporate culture; one I've never seen changed at any of the organizations I've worked for, despite numerous attempts to do so) that argument is actually besides the point. I'm more interested in engaging you on the position I summarized above.

Can you elaborate more on what you feel the negative compromises are, and how they harm io.js? Please, be as specific as possible. A general "have it's wings clipped" won't help drive changes to the proposal; can you break out your concerns into a point by point list? (Even better if you have suggestions for how to improve or change those!) I'd love to understand your concerns more in depth.

[mbonaci]

@Morgul I onced asked for a point by point list

What does Joyent bring to the table except few enterprise customers (no, this is not a rhetorical question, I'd really like to get an answer in a form of bulleted list)?

I think that foundation proponents should bear that question, not the other way around. Since we do have a bad experience with Joyent (some of us with IBM also, not to mention Microsoft) and IO.js is functioning great, the first question should be "What do we gain by joining?".

Then, and only if we're happy with that answer, should we ask "What do we lose by joining?".

So, with good faith, let me start:

• communities would reunite
• corporate clients would get reassured about the future of the project
• "a lot of existing io.js' practices will be documented and more well defined" (by @mikeal)

@mrseth as per the second bullet: I know, you're right, but this is the world we're living in.

Anyone care to add a bullet or two?

EDIT (2015-04-25): No? You see, it's easy to hide behind pages and pages of paperwork, but not so easy to boil it down to a simple list. Or you think this is not a legitimate question? It's the ultimate question!

[sandro-pasquali]

One of the best ideas to ever come out of the Node.js community was to aim for, and stop at, a tiny STDLIB. You might say recognize the compact, unique revolution that Github + npm + OSS + Javascript represents and stop creating new features ad nauseam. Does this foundation aim for a similar goal? I anticipate forking the new Node.js (again) whenever this boss becomes the same as the old boss.

[mikeal]

@sandro-pasquali this is addressed in the Development Policy

https://github.com/jasnell/dev-policy#guiding-principles

"[..]keeping Node.js focused on providing a minimal kernel of core functionality while deferring, as much as possible, additional capabilities and features to add-on modules or applications."