Proposed Node.js Foundation Mission, Structure and Strategy

[rvagg]

Not for merging, this PR is for discussion purposes only

@nodejs/tsc @mikeal

This is a Markdown version of the slide deck you can view @ https://www.dropbox.com/s/c1molh928bdpga3/Node.js%20Foundation%20Mission%20%26%20Structure.pdf?dl=0

Alternatively, look at the rendered version of the Markdown @ https://github.com/nodejs/TSC/blob/Foundation-Mission-Structure-and-Strategy-Proposal/Foundation-Mission-Structure-and-Strategy-Proposal.md (there's some perdy graphics you'll miss if you look at raw MD)

Next week there is a Board meeting and my primary concern is that we don't have a shared sense of mission for the Foundation which is leading to each arm of the Foundation executing on different priorities in different directions. We're doing our own thing, the Executive is doing its own thing and the Board is wondering what we're all doing and why. We're also having difficulty pinning down the why of what we are doing, witness the flailing we've been doing over the umbrella strategy which we've all been lukewarm on from the beginning and now can't really fully let go because we want to leave our options open.

I'm asking the TSC to +1 the proposal I'm presenting here so I can use it for dialog with the Board. I'll also be sending them an advance copy of this as well as I promised to keep them in the loop on developments prior to the Board meeting anyway.

The key things being addressed here are:

• Mission: a basic thing we can stand on that has enough room for constructive disagreement about exactly how to achieve that mission (a healthy thing)
• Structure: this isn't new but it's clarifying how we are set up at the moment so we all know where everyone is and what zone we're supposed to be operating in
• Strategy generation: not strategy itself, that comes later, but how do we get to strategy? the proposal here has 3 areas for strategy that align with the mission: core, open source ecosystem and commercial ecosystem.
  • The TSC (within what I'm calling the "Technical Executive") takes core and has independence there like we've already established. We are responsible for developing and executing strategy there that aligns with the mission.
  • The commercial ecosystem is taken by what I'm calling the "Business Executive", where @mikeal and the other paid staff are, they develop and execute strategy there in consultation with the Board, that strategy has to align with the mission.
  • The open source ecosystem is shared by the Technical Executive (us) and the Business Executive and also requires consultation and sign-off from the Board and has to align with the mission. The key point here for the recent discussions we've been having is that if we want to expand the scope of our technical activities beyond core then it requires a conversation with the rest of the Foundation and sign-off from the Board. The option is open for us to expand in to new lands and bring on new projects, but it has to have agreement. We don't get to have independence here like we do with core, scope creep is too important an issue to leave to a group that doesn't have direct accountability to the Board.

I know this is really late notice and we have a meeting in a few hours (I haven't slept yet!), I'm very sorry, I really wanted to do this weeks ago but have had trouble prioritising it.

[rvagg]

sorry @nebrius, I don't think we have you on the TSC team yet for the @-mention, also @williamkapke you'll probably be interested in the structure chart in there at least

[orangemocha]

Suggestion: consider "promote" or "encourage" instead of "increase". "Increase" to me sounds like growth is the only measure of success. So if one year the adoption doesn't grow, for example because of changes in the technology landscape, will have the Foundation failed its mission even though it continued to promote adoption?

[mhdawson]

Along the same line of thought I wonder if adoption is just one measure of success. The mission could be:

"The Node.js Foundation exists to make Node.js the best runtime for development and deployment of applications with one measure of success being the level of adoption in open source and commercial communities and its market share relative to other runtimes"

[rvagg]

Coming out of discussion in the TSC meeting:

"The Node.js Foundation exists to increase the adoption of Node.js and increase participation in the Node.js project."

[nebrius]

Thanks for linking me in @rvagg.

I hadn't heard the term "Technical Executive" before, and at first I was confused over whether this was the TSC, the TSC's representative to the board, or something else. Then I saw the diagram at the bottom and it made sense.

What do you think about moving the second diagram higher up, possibly right after the list of three groups?

[williamkapke]

@orangemocha You might be right on the changes of the word "increase" you mention... however, I want to point out that I THINK (@rvagg correct me if I'm wrong) that the key here is that this is background info to lead into 2 future TSC action items:

1. Reach agreement on a basic statement of mission, upon which all strategy can be tested and justified
2. Agree on a strategy generation and execution structure, and the relationship between the main bodies within that structure, that can best achieve the mission of the Foundation

I think^†, then, if today's meeting shows interest in this topic, 2 separate PRs will emerge for TSC consideration/vote and those PRs would be best suited to debate each keeping the discussion focused.

_{DISCLAIMER: I am often wrong ... and if I am here, then please consider this for the workflow :P}

EDIT: Hm.. re-reading the OP, it seems that @rvagg is trying to get this in before the next board meeting. Understandable, but maybe too rushed IMO.

[nebrius]

What about via a seat for a TSC member? I kinda read this as saying "there is a seat on the board for a nominee to the TSC", when I think the intention was "there is a seat on the board for a member of the TSC, who is nominated by the TSC (or board?)"

[nebrius]

hmm...on second thought, my comments may be a bit too bike-shedy. If so, feel free to ignore them :)

[mhdawson]

I like that this calls out the 3 areas separately as it helps to identify that we are interested in all 3.

[rvagg]

Pushed updated in 4a7781f that address most (all?) of the feedback here and from the TSC meeting, I also added a new graphic to the deck. Will be sending this out to the Board as it is now and let you know how the discussion goes, cross fingers!

PDF version here: https://www.dropbox.com/s/c1molh928bdpga3/Node.js%20Foundation%20Mission%20%26%20Structure.pdf?dl=0

Rendered Markdown version still here: https://github.com/nodejs/TSC/blob/Foundation-Mission-Structure-and-Strategy-Proposal/Foundation-Mission-Structure-and-Strategy-Proposal.md

Thanks all! I'm really happy with the status of this and that we seem to have a general agreement on the basics here. I just hope we can find common ground with the Board (and also @mikeal's team) so that we finally agree on exactly what we should be focusing on. If all goes to plan then the result from this for us will be to (1) consider strategy for Node core, how do we make a strategy and what do we document? And (2) work with @mikeal's team on creating a strategy for "fostering a healthy open source ecosystem" and propose that to the board. This is where Express, "incubator" and "mentorship" come in, the board will need to sign-off on this so I expect there will be some work to do with them in the process. It may be that we only come up with a short-term strategy and revisit it in 6 or 12 months.

[mhdawson]

lgtm from my perspective

[jasnell]

LGTM

[indutny]

LGTM

[joshgav]

A few suggestions to achieve greater clarity:

"Executive", "Technical Team"

Can we use the terms Business Office and Technical Office instead? Parallel titles will make understanding assigned roles more intuitive at first glance. Also "Office" connotes more significance than "Team", and "Executive" connotes too much independent significance IMO.

Slide 1: "Node.js Core"

Add Builtin Modules to the domains of the Technical Office, i.e. fs, http, net, everything in ./lib and their native dependencies.

Add Runtime or "Core Runtime" to the domains of the Technical Office, to include src/node.*, BaseObject and *Wrap, streams (?), tracing and diagnostics (?), etc.

These would allow removing the "* Dependencies" domains. Responsibility for dependencies will be easier to define when they can each be related to a proper core domain. As such:

Remove "External Dependencies" and perhaps replace with "Build Tools" or "Tools". (Also IMO NAN is most relevant to VM APIs.)

Remove "Internal Dependencies". http_parser should be part of "Builtin Modules" (i.e. http) and "libuv" should be part of "Runtime".

[Fishrock123]

LGTM

[nebrius]

LGTM

[Trott]

Nit: One of the diagrams uses i.e. ("that is") a lot but you almost certainly mean e.g. ("for example") there.

Meh, I see a mix of the two so you probably meant "that is", so uh, yeah, never mind.

[rvagg]

@joshgav thanks for your suggestions, the naming of the branches was kind of difficult to arrive at with the TSC and I'm not convinced that "Office" helps a whole lot. However, I'm sure the Board will have suggestions of their own here so we'll leave it open.

Regarding built-ins & runtime vs dependencies, I think you're getting to some important points but perhaps digging in to too much detail for this slide? We do need to have a discussion about what "core" means but I'm not sure that we need to have complete clarity on that just yet. Also, the dependencies story is a lot more complicated than just talking about "built-in modules" because http_parser and libuv are distinct projects, in exactly the same way that OpenSSL and even V8 is, yet these are depended upon and we have zero ability to manage OpenSSL and V8 while we have more ability to interact with and manage (or influence, or guide, or ...) http_parser and libuv.

[joshgav]

Thanks for the consideration @rvagg, glad these are on your radar. I brought up those domains of Core here only to ensure we didn't understate Core's technical responsibilities, agree these details aren't that important here.

The value of x doesn't particularly matter, but I do believe symmetry between Technical x and Business x will be intangibly helpful in the future.

[williamkapke]

With the new mission statement, was amending the Certificate of Incorporation discussed with the Board?

The current mission statement is:

The primary purpose and mission of the Foundation is to: (a) enable widespread adoption and help accelerate development of open source, scalable network application technologies that run across distributed devices (the "Platform"), (b) promote the Platform worldwide, and (c) undertake such other activities as may from time to time be appropriate to further the purposes and achieve the goals set forth above.

[jasnell]

Closing due to lack of forward movement on this. Can reopen if necessary