How are you all doing today?

Jump up and down a few things.

Stretch a little bit.

High-five the person to your right because you can.

My name is Adam Miller.

This is OpenJS.

This is between you and me, we won't tell the panellists, how many people know what

the JS Foundations do, and interact with them a lot and should be up here on this panel?

I see a few hands.

Who knows that the foundations exist and kind of know what they do but really ... couldn't

give a talk on it or be on the panel here.

Here is, ""We're talking about foundations?

We're talking about open source, right, why is there a foundation involved?""

We've done a lot of work recent to merge together the Node Foundation, and the JavaScript Foundation

into the OpenJS Foundation.

It's been a ten-month process or more.

We are really excited to share with you what we've been doing.

There's an awesome panel of people here who are have been rocking it on the foundation

formation side, and I guess we will about down the line and do intros here.

>> You have a standalone full-screen experience from looks like any other app on the iPhone.

So it's basically a PWA.

Then you have - feature phones, I have this Nokia here with me, feature phones, non-touch,

they're supporting PWAs.

But it's not just on mobile.

On desktop you can go and install Trivago, Tinder, by the way, and you have a - that

works on Windows, Chromebook, Mac and Linux.

You can open more PWAs at the same time.

We have the properly, we just need to create really, really good experiences, and today,

let's say that I can say that maybe half of the PWA s out there on R offering a good experience.

The other half are away for offering a competition like the native apps, and so we will try to

see why, and what we can do today to improve that experience.

So, talking about the app cycle, okay?

So because we are creating apps, not just websites that will appear in the browser.

So, when you open a PWA, so if the d Platform.

I'm Google's representative as a platinum member board representative and the vice-chair

of the Open JS Foundation.

Before that, I was the elected representative on the board prior to the merger in the original

structure of the node.js Foundation.

There were three board seats that are community members.

Tracy had one of them, and I was representing the other group.

>> I'm Adam Miller.

In the daytime, I work on LinkedIn.

We can't talk to the future of the organisation without looking to the past.

I would like to get a tl;dr on the node Node Foundation and the JavaScript Foundation.

>> So a the although of people may not realise that the JavaScript community has had a foundation

working on behalf of open-source projects for a long time.

Back in the mid-2000s, we had the jQuery project that got wildly popular and we made a foundation

for jQuery that added projects over time which later merged with what was the Dojo Foundation

which had a handful of projects itself and just kind of that was about three or four

years ago, and so that was when we became the JS Foundation, and we've been rocking

along behind the scenes for quite some time.

>> And the Node JS Foundation was formed in 2015 to provide a future place where a number

of different groups within the node community could come together and work on figuring out

how to move things forward into the future.

There was a few sort of key things that were important, which I think we will see flow

through so what we see in the OpenJS Foundation as well as that neutrality, if they contribute,

they have the tools and the access that they need to make things happen.

That is something we will see reflected in what we talk about in the OpenJS Foundation

as well.

In September 15, we - we've seen consistent and reliable releases

ever since then.

I think it's a good sign of the stability and the ability for everybody to get in in

work together on that front.

>> Yes, I know early on when it was just in early discussions about the two foundations

merging, there was a good bit of uncertainty about whether it should happen, whether it

was the right time to do it.

I know a lot of you feel that a lot of those concerns early on, I was hoping you could

answer maybe why not, and why merge?

>> Can you repeat that one more time really quickly?

>> Why are we merging now and why - what is the reason for the merge?

>> It's been a long couple of days!

So there are a number of different reasons to consider merging foundations.

If you go and look at the bylaws of the foundation itself, right in there, we claim that we want

to be a centre of gravity for the JavaScript ecosystem.

Prior to there being one primary foundation, it wasn't really clear.

And it's hard because Node was the main project in the node.js Foundation, and joining something

bigger means giving some stuff up, and there's an anecdote I really like.

When I kind of started getting into the node.js ecosystem, when I had just moved to California,

I got - I got a free ticket to go to a conference called Node Summit.

This was right around the time of the fork, and they were talking about merging, and I

have no shame, so I walked right up to Scott Hammond at the time the CEO of Joyant and

asked him why would you put Node?

A foundation - in a foundation?

He said it's better to have a smaller piece of a bigger pie.

To me, when I think about these foundations, and we just had our summit recently which

was fantastic, and so many new faces in the room that weren't there before, we just massively

expanded the scope of the work that we can do, who we can work with, how we can work

with them.

We get to revisit all of these kind of preconceived notions when Node first went in the foundation,

it was very reactive.

We had things that we needed to protect and fix and now we can be proactive and start

thinking about what we want to build.

>> It made me think we all know we can accomplish a lot more than we could on our own as an

individual, so it's the same thing for a larger foundation.

>> And sort of wearing the Node hat, there was a lot of scepticism when we were talking

about a merger.

And not - I wouldn't necessarily say it was balanced.

There was a lot from the Node side, and, again, it was because we had experience going through

I think a pretty tumultuous foundation formation not too many years ago, and Node was finally

feeling like a stable place sort of firing on all cylinders, we were working together

in the community, and the TSC, but I think as part of that, we ended up seeing how bringing

in the up stream components in the JS ecosystem, that, like, we were stronger when we were

doing that together, and so by focusing on these sorts of things that we had already

learned, transparency, including not - not just including - giving autonomy to the project

members so they could run and host these meetings, we ran weekly meetings when it came to the

merger discussion and planning so whatever wanted to drive the planning from particular

initiative phases of making this merger happen, it was only going to happen if people showed

up and did the work, and that is from the project side, not from the board side.

>> Yes, I will add that on the .just Foundation side, we immediately you a the benefit of

possibly merging with the Node ecosystem because all of our projects really rely on Node.

At the same time, there was fear and uncertainty because there was a lot of historical drama,

and energy from the community which may be disruptive to what was otherwise fairly stability

projects.

So, you know, with that optimism, but cautious optimism in mind, everybody got really excited

about the possibility of collaborating more closely with their peers on the Node side

through one umbrella, and I think that's kind of what put us over the edge.

>> And one of the things that building on what both Tracy and Jory was saying, from

the get-go, we approached this from an egalitarian mind set.

We made the doors open, like we tried to be hyper inclusive as much as possible.

If you are a member or a committer, and even then we weren't that picky, like, if you wanted

to show up to those meetings and you wasn't being disruptive, you had a voice and a seat

at the table, and were participating.

I think that was really important to make sure that this could be successful.

>> I was going to say, we looked at the governance for a number of the different projects, for

the Node Foundation, Kubernetes, and I'm happy that we ended up with something that is the

most, has the most opportunity, and hopefully the best place where people will want to come

and will attract a lot of good people through that.

I'm happy by looking at that, we ended up with that open and really nice governance.

>> I think in all of this drives home the value of this work is always project-driven,

and that's the point of the foundation, is to help empower and give autonomy to the projects,

and get sort of the crap out of the way for them to be able to do their good work.

>> I think what I've heard on that front is we talk about great projects and the focus

will be on those great projects, not the foundation itself.

>> So let's dig into some of that nitty-gritty.

Almost everybody in the room here is an engineer, and I have always held the opinion that governance

is just coding but with words!

It's really what it has felt like over the past ten months, and we have a visual aid

here as we talk about it.

Let's dive into some of the more nitty-gritty details here of under the hood of what is

kind of making this foundation, new foundation tick, and we can talk about some of the back

story, and reasoning behind these sections of the foundation.

Yes, so, I mean, let's take it from the top and go OpenJS board and talk about their functionality.

>> To start out with, I talked about the governance.

We have multiple levels so there are observers.

Any who wants to can come up and participate in the meetings.

We want to get as many different ideas to come to the best answers.

We have regular members who can actually, people who in my mind who said I'm making

a commitment to be involved regularly and they can they can be recognised for that.

Again, both observers and regular members are involved in all of the work that goes

on.

And then finally, we have voting members where in the rare cases where we need to actually

have a vote on something, it's that subset who will do that vote.

Now, our experience in the Node project at least has been that votes are very rare, we

follow a consensus-seeking approach, and really it's going to be all of those members who

have ownership and who push things forward, and so it should not really matter which level

you're in, but we have just to have the different levels for the contingencies.

>> One thing that I can add, a mantra I would tell myself, was that we wanted to create

structures and hierarchies of responsibility rather than power.

So there isn't fundamentally a major power balance between any of the members of the

any of the projects, being a voting member just means you're more responsible.

You need to be showing up.

You need to make sure that things are getting finished but you just don't get to shut down

another person's voice because you have that responsibility.

>> The governance is really written so that all the responsibilities of the CPC are the

responsibilities of all the members as opposed to anybody in particular.

>> I want to talk a little bit about the projects if we can, the staging, because I think for

me, this was a big bringing all JS Foundation projects on board, and important they had

a voice in the project, and where they were going to derive value and get value and services

from the organisation, so we came up with this proposal that was loosely based on the

CNCF model of impact projects, growth-stage projects, and what is not pictured here is

there a project which we have six projects that we deemed, and the projects themselves

opted into this stage, functionally complete.

We recognised and thanked them for their contribution they made to the comment but we're not really

encouraging people to go and contribute to those projects or adopt those projects now.

We have five impact projects which are sort of the projects that are a real kind of need

to have some resources and support on a very active basis from the foundation.

They're used heavily in enterprise, and they need that backing.

We have six growth projects and that stage is for projects that have a specific objective

in mind, like there is a goal.

I need, I want to grow my contributor base.

I want to increase the number of implementations.

I want to put on an Yvette, or something like that.

They have some specific goal for which they need extra resources from the foundation for

a short period of time, growth stages for those projects, and then we have 15 projects

that are projects that are fine, they're kind of doing their thing, their resource needs

are pretty set, and we don't have to do too much to support that.

>> One thing I can add from the At Large is the Node Foundation, that was the only project.