 So, quickly, I'm Robin Ginn. I'm the executive director of the OpenJS Foundation. Again, for your anniversary, they're about... I'm Josephi. I'm chair of the cross-project council. Who's now? Who's this? Anyway, and I also do open source at IBM. Cool. Just a quick reminder, on the Code of Conduct, we all want to have fun, be respectful. If you see something, say something, reach out to me or any of the event staff, and we'd be glad to help you out. Okay, so let's just jump right in. Some of you have seen this stat. I love to use this stat. Almost 2 billion websites. Almost everyone is using a JavaScript in one way or another from IoT to TVs. A lot of you know that we use it in space with NASA. And, wow, so this is like big, you know, right? And that's just the web. So, JavaScript, it's been around for 27 years now. So, is it still relevant to emerging technologies? It's still quite relevant. And in fact, I'll try it, yeah, I'll talk in here. Yeah, it's funny that Robin pulled this quote, because I used to work at the New York Times, and we rewrote the platform to serve the website. And there are a number of us who were pushing for it to be written in Node.js. This is a few years ago, 2011 or so. And they had a bunch of PHP developers, so they decided to do it in PHP. But within a year, they started rewriting it in Node.js. So, it's funny that the New York Times is up there. But, you know, like the quote says, everybody's chasing kind of the new shiny stuff, but like Robin was saying, JavaScript's been around for a long time. Yeah. In addition to all the shiny stuff that people are chasing around, there's still a lot of people debating, what's the next big thing in JavaScript? Which project has better performance? Does this sound familiar? Which is easier to use? And I pulled this mission statement, if you remember, you were in Vancouver at the Collab Summit. I think Darcy asked Joe, like, what's our mission statement, essentially? None of us could really remember. We wrote one, it was just the last one. Exactly, it's the bylaws. And essentially, Joe sort of nailed it. We're here to support the entire JavaScript ecosystem. We love all 40 of our projects. They're near and dear to our heart, but we're really here to sort of, support sort of that connected ecosystem in JavaScript. And I think an important thing to remember is, in doing so, OpenJS Foundation does not pick winners or losers. We're neutral, we're here for everybody. And essentially, as a neutral party, a foundation like ours, and most folks at the Linux Foundation, we hold the copyright and trademark. So then that really ensures that it stays open for the long term. And it also protects maintainers, perhaps from some maintainers' companies. So foundations play a role to protect open governance and communities from what some might say are potential, hostile takeovers. Yeah, I think this is important to talk about. There's been a lot of conversation online and I think some misunderstandings about how foundations work and particularly how open governance works. And so I think this is a great conversation to be having. So open governance is like a manual for how projects operate and how decisions are made in a clear and transparent way. They contribute to a positive place for collaboration by setting some structure and accountability to the process. And it's an umbrella organization. And the projects operate independently. And I think that's really important to note. I saw some people talking about companies pay foundations and foundations pay developers to build Node.js. And that is absolutely wrong. So we're a great neutral home. And another person talked about why doesn't some big company just send a bunch of developers in to set the roadmap and build the features. Again, that's not how it works. Open governance, we have lots of rules in place for avoiding those sorts of things. Next slide. And so this is kind of how the structure is broken down. We have a board of directors. We have the cross-project council, which is kind of our top advisory committee. And then we have the projects and the developer communities. And there's really kind of a wall between each of those, you know. And frankly, the real work that happens that drives the foundation is happening at the cross-project council, which is open to everyone to get involved. And we'll talk a little bit more about how you can collaborate with us. Yeah, I like to say the CPC is the tail that wags the dogs. Yeah, exactly. Boss. Okay, I think, there we are. So let's just give, just a quick step back. We do love our 40 projects. So OpenJS Foundation, as many of you know, is the merger of the Node.js and the JS Foundation. Almost five years ago, we have a number of projects being in small. We have Appium, Jest, JQuery, Node.js, Webpack. Many more that almost everybody is using in some sort of dev environment. And one thing I love to do is just to highlight a few wins. I just picked a few projects that we love to celebrate every month. Node has been really just crushing it on the security front with the Alpha Omega funding from Google and Microsoft. So really appreciate the work that's happening in that security working team that shipped 19 and 20 big releases. And a new website's coming out. WebDriver, big version eight release and doing some great translation. JQuery also had some security funding as well and lots of work to shore up and modernize the infrastructure as well as work on a sort of a consumer education campaign to upgrade a lot of folks on JQuery. 77% of the world's websites are still using JQuery. Electron, yay, Eric, Tierney. 10 years has come by already and V24 shipped. ESLint ships all the time if you're interested in participating and contributing, that's a great place to start as well. But the one thing I would like to just share that there is a lot more to contributions than code. I got my start in Node years ago working on the marketing side and there's a lot that the community does within the communities and there's a lot that we do at the OpenJS Foundation with the support from the Linux Foundation to really make a project successful. Training certifications, program management, marketing, all kinds of great things to really help grow adoption. And so we've been talking about how JavaScript is pretty much everywhere and with JavaScript everywhere we need to be concerned about security everywhere and the cross-project council operates in a better together kind of way and last year we launched the OpenJS Foundation Security Collaboration Space. The foundation we have this concept of collaboration spaces they're like working groups and SIGs but we particularly trimmed it that way and structured it that way because it's really meant to bring other folks into these groups whether they're in one of the projects or not it's meant to bring folks in from the community to work together on this. And so these are some of the wins that we have going on in the foundation right now. Robin was just mentioning the jQuery work which is great, the sovereign tech fund which is a huge win, nearly a million dollars to work on security in the JavaScript space and our focus is to make impact across the community not just for our projects so that's really important. And it's also I think maybe the first time that a government has invested in open source in this way so it's a really huge win for that one. And then like Robin had said the work in the Node.js space around security has been huge with the Alpha Omega project and you can read more about all of this on the OpenJSF blog. Great, so just in this annual report I do just want to really thank the community who really brings it all together and makes it happen. Folks like Joe at IBM and others and I thought I'd just let you kind of share a little bit why IBM lets Joe spend so much time. Yeah, thanks for the quote from Dr. Max who's our new board director from IBM. But yeah, we invest in open source in a variety of ways because it really serves our interest. We use a lot of open source we build our products on top of open source and it makes sense for us to be engaged in those projects when we need some sort of feature or are concerned about security. We are directly involved and so we heavily invest in open source and we encourage other companies too as well. Yeah, and we do have a lot of other companies and really we couldn't exist without our foundations. They fund us, that is how we operate. We have some training certification budget or revenue that you'll see but really the majority of our programs are funded through these wonderful companies. Google, IBM, joint, Microsoft, the Sovereign Tech Fund. Yeah, MetaGoDaddy Netflix. So really thankful for those folks. And also thankful for our leadership. We have the coolest board, I think. Dr. Max is here, Paula's here, who else is in the audience. But yeah, we have a wonderful board. It's very interactive and actually a lot of these board folks are really participating deeply in the communities as well which I think is pretty unique for us. Yeah, and Robin mentioned the trainings and certifications and this is a great service that the foundation builds and provides. So, and it's also a great resource for engineers and companies looking to find folks to join. And 60% off, I don't know what's the timeframe on that. The whole month, right? The whole month, okay. Check that out, it's a great resource, I highly recommend it. We promote it internally, we get a discount as well, not as good as that, so take advantage of that. And it's actually applies across the entire Linux Foundation Catalog, so you can do Node and you can do any other technology that you can do. Yeah, there's a lot of courses and certifications from LF. So, love for you to all to participate. We operate in a, we call ourselves radically transparent stream, yep. Yeah, absolutely, and if you go to that link, you'll find a number of ways to get involved. Our calendar is public, our meetings are all public, they're all, there are Zoom links that are in the calendar invites. We stream to YouTube, the invite for Slack is there, our GitHub orgs are there. We try to do as much work as possible in GitHub so that it is open to everyone. And it's not only for transparency sake, but it's for people to be able to get involved. They can go and look at what we're doing, see what might interest them, and find ways that they can get engaged. So, I encourage you to take a look at that link and see how you might be able to get engaged. Awesome, yep. Great, thanks. All right, well thanks everyone for the San Diego Report. Now I have the pleasure and honor of introducing the very cool panel today. I'm gonna introduce Paloma from Sauce Labs, Bethany Griggs from Red Hat, Eric from Slack, and come on up and I'm gonna let you all take the show and just see some of how our folks govern in real life. Well, thank you everyone and of course, thank you Open GS Foundation for this opportunity. This whole started for volunteer work that I do for Pie Ladies Berlin, which I'm one of the co-organizers, and we have been running for the past two years exactly this kind of work. It's putting big projects, open source maintainers from the mostly Python community because it's Pie Ladies with people that has never touched the code and I'm really impressed to see, for me, that was very impressive because it was like, it is a gigantic project. Like it's not like you can touch it. It's like a broadcast television. How will you deal with it? Because you don't touch it. So I had this great opportunity because I'm actually a JavaScript developer, not a Python developer, to ask the maintainers of those big projects what's the deal with it and why they look so afraid to deal with it. There was a little introduction about why the stock. So it's this opportunity for us to get to know behind the scenes of contributing to a big project. And here is the people who will give you all the knowledge, Beth Grekes and Edith Zhao. I would like to start with you presenting yourselves starting with Beth, a little bit about you and which project are you a maintainer for and I don't want to take for granted that everyone knows what Node.js is. So could you please talk a little bit about the project and yourself? Sure, yeah. So hi everyone, my name is Beth Grekes. I'm at Red Hat and mostly most of my open source work has been around the Node.js project. I have one of the kind of more rarer entries into open source where the second I left university I was hired into a team where contributing to Node was part of the scope of the role. So kind of stacked in slowly started doing some documentation and test PRs. And then what really kind of helped me and lifted me up to make contribute a lot more was one-to-one mentoring from great releaser Miles Borins. And he spent like six months one-to-one with me teaching me how to do releases. So then I got involved in a release group and from there I kind of stepped into a few more areas and was able to get to grips a bit more with the project. More recently kind of any sort of paying it forward. I also mentored some other people into the release group as well because I think there's no guarantees we're all going to be around in the project or have a job that lets us do it forever. So really paying it forward just out of courtesy and also for the sustainability of the project. And more recently I'm kind of interested in supply chain security and how that's going to impact the new project specifically. And what about you, Eric? Hi everyone, I'm Eric, I'm based out of Vancouver, Canada. And I have been working with Electron or maintainer for Electron for the last four years or so. Electron, if you don't know is kind of a fuse of Chromium and Node.js and allows JavaScript developers to build desktop applications. And initially I kind of got in almost the same way as Beth where I was an intern on the core team at GitHub at the time. And from there I kind of after I graduated I started working at Slack, which is an Electron app and my team right now spends maybe like after time maintaining Electron so we're pretty big presence within the maintainer space. And what I focus on mostly in my day-to-day is developer tooling, documentation and community building, yes. So it's quite interesting because you started basically recruited from the university inside of the project. How was the difference in between what you were studying and someone opening the door intended for the open source world? How was the difference between what you were doing there in the classroom or with yourself and then exposing yourself globally? I can try that, at least in the context of Node. So the reason I ended up in the Node team at IBM is because I mentioned I'd built a few little apps with Node and it was building some web servers and things. And then when I went in, I was like, oh, I'm gonna be doing Node stuff. And it was kind of a surprise and a shock to be like, oh, you're not gonna be building apps here. You're working on Node here. And I guess that's kind of what a lot of contributors feel as well. Like, I'm sure there's many, many JavaScript developers and no developers using it every day thinking, how can I contribute? And there is a bit of a like, oh, wow, this is completely different going in and actually working on the runtime itself. So yeah, it was a bit of a shock and a bit, you know, intense steps. Was it that experience for you as well? It was definitely different from what I expected from school. School, software engineering in Canada, I don't know how tailored the programs are supposed to be for industry because I ended up doing a lot of circuits and signals and electrical engineering stuff. So it's very broad. They don't really teach you the specifics of, I guess until you get to your upper level classes, you don't really get that hands-on experience with software development. And at the same time, you also never really touch a project on the scope of what electron or node are. So it was definitely a shock coming in. But thankfully, I think the internship program they kind of put kid gloves when handling you and you're like kind of eased into the project, you know, onboarded and everything. And you're allocated this like time from someone who's experienced and I had a mentor who could one-on-one help me out with everything. Yeah. This is kind of a draft what we kind of plan to talk today, which is a little bit of behind the scenes, a little bit of why we're saying to you users, well, you should get involved and some closing thoughts. But this is quite not that a big of audience. So please jump in. If you have something to ask, this is a great opportunity for you to ask your questions, those that you never know want to ask. So kind of trying to follow this trajectory here. I want to understand how it is behind the scene because and I think that's a kind of a hard task because you're being involved with the project for so long but trying to put yourselves in baby bath and baby Eric when they were just starting to contribute. The projects, if you didn't have a chance to look at their documentations, it's pretty impeccable. And that was behind the scenes question, like how is it being part of a foundation or a big project? It is actually involve or change the project because the first thing that stroke me is that you have a very clear governance model, which is you go to the page and it's super clear like how can you contribute? It is already laid down. Did that impact your choices? Of course, you mentioned a lot of the mentors you had but how having this great structure and governance model helped you choose in your path in the projects. Tell us a little bit of behind the scenes of getting started. So node's massive and like if someone came in and was like, I want to contribute to node, it's like the first question is, what's your interest, what part? Because trying to keep on top of all of it, like I think we all give up on like all the notifications and things, it's huge. So I think the structure really does compliment helping people get their step in the door because it's broken down into teams and working groups. So if you are new, you can go to look at the list of teams and the working groups and be like, oh, hey, there's a smaller group here. It aligns with my interests or something. I just think sounds cool. And then you can go work with that group. And I think that breaks the barrier a little bit because rather than walking up to a project with like a hundred collaborators or something like that, you can all jump on your PR and review it. It's a bit kind of intense. If you can go to a smaller group that's got maybe like five to 10 people meeting, talking about a very narrow goal and a very narrow topic, I think it's an easier way in because you know who to ask for help and they're probably a smaller group of mentors. And it's just about confidence as well, I think really, just you've got a small group of people and you can build out from that. For Electron, we are a pretty used project, but I would say that our maintainer base is relatively small. I think in terms of like core governance members, we have somewhere between 20 and 30 at the moment. So it's just a bunch of engineers wearing different hats. It's, and I feel like it's the working group model is very useful to compartmentalize kind of like what your responsibilities are. And if you have like rotations regularly, like for example, we have this upgrades working group that's specifically dedicated to upgrading versions of Node and Chromium to keep up to date so that we get all the latest security releases and performance boosts with each major version of these two libraries. So essentially we're, it's very helpful to say who's responsible for this and who's responsible for that, rather than just having, I think initially, what was happening was that there was like people who had right access to the repo and people who were core maintainers on GitHub. And like it was really hard to find the delineation of like who's responsible for things, who should have access to other stuff. And right now, I think one thing that's trickled down from this governance model is that we have a lot of automation around like, who has permissions to certain repos, who has admin superpowers just to make sure that, you know, we can't just, someone's GitHub account gets compromised and then like the whole thing blows up. And that's one of the things that we're pretty wary about as, you know, we do have a lot of downloads on a monthly basis for the library, yeah. I wanna break it down here because there was a lot and it was one of those things that I understand you take for granted from your, this is a daily experience for you, right? But putting yourself in the eyes of someone who has never contributed to open source, who doesn't know where to start. And you're talking about a working group and a very organized structure, but different tiers, right? This is not like your actual job. Your resume, you have actual jobs. And how does it work for you to trust this structure within your volunteer commitment and how much that affects the project because of where I wanna get here is, we take for granted SNODE, it's there. It's a big, gigantic structure. But how much you play a role and how much that can be fragile because it is an open source project. Yeah, I can speak to my experiences in the release working group. So I am fortunate that Red Hat and IBM think, for node to be a success and for us to be able to build products on node, it needs to have regular releases. So we will find someone to go and help out with releases. On the other hand, we have volunteers in the release group, they're great. They do a lot of great work, but it is very hard to, when people are volunteering their time to say a security release, we need to get one of those done or we need a bug fix release at the last minute. It's very difficult to get people who are not paid to essentially be on call and drop things and just go in and fix it. Fortunately, we do have some folks who do that. And we also have some folks who sign up for like rotation. So we try and spread the workload a bit more these days, but it's difficult. And I think it's those kind of, the kind of key infrastructure, key releases, the reactionary things that we kind of struggle with like everyone wants to work on a shiny new feature and contribute to code. And you get that nice kind of like, hey, I just built this thing. It's really cool, but you know, hey, I just fixed this build machine that's broken. It doesn't get the same, and I think I could rant for a long time because I think this is a symptom of like the tech industry in general, caring more about shiny new than maintenance, but yeah, it is a challenge. Fortunately, we've got some support from APJS for infrastructure and security. So things are, you know, being recognized and we're getting better with rotations and things, but yeah, it is a challenge. For Electron, I would say that we do have a sizable amount of volunteers, but also an equal amount of people who I guess contribute on behalf of their companies as well, mostly just because there are a lot of enterprise apps who use Electron. And even though, even though we have like this open governance model, we do end up having people who are thankfully like very on top of it for releases, for upgrades, for security, and so on and so forth. But at the same time, I feel like there is this kind of bus factor with how we operate, where like, you know, if suddenly five, six people dropped out, then you know, the project would definitely be scrambling. So I think the governance model definitely helps offload that kind of, that kind of harm that can happen because like, you know, everyone has like their own role and all the workload is divided between groups of people. But at the same time, I think it definitely takes individual, like a lot of people going above and beyond to keep the project going as well. And so where is the, if we are talking about first of all, right? If you think about, oh, it is a gigantic, it's massive. So there's this big difference and maybe contrasting between being so big and so complex, but also going along with having a great structure that helps you on board. Am I hearing correctly? So why should people fear not to contribute and to get started? What are the benefits that has brought you as your professional career and maybe your personal existence in the earth to being part of those big projects? I think one thing for me was like, no, it has very, very mature contribution guidelines and processes and things. So like, I know now from working in no project where they will say, we want your commit messages to look this way. We want you to run this lintel. We want your PR to look, you know, tick these boxes. It's very prescriptive to process, which has really helped me going into any other project because now I instantly think, oh, maybe they've got a contribution guideline process that I need to read before I open my first pull request because it can be a bit demoralizing if you open your PR and people are like, hey, you didn't follow this process. It's just kind of instilled the methods. I think it would be harder if I came from like a started contributing in a very more relaxed kind of open source project with much less processes because then when those processes get on you, you'll be like, they're kind of getting in the way. So I feel like going into the process and then seeing the benefits helped. Yeah, I can definitely echo that. Electron also has pretty good developer documentation on how to get set up and get building. Unfortunately, I think one of the realities for that is also that it's really compute intensive to build Electron locally and contribute back to the core framework. But I guess moving on to like the how it's, I guess made me better. I think it's been good to help me contribute to other open source projects. For better or for worse, everything in JavaScript is a package and has a GitHub repo and you're gonna make a pull request somewhere. And being, I guess, a good citizen in open source makes it a lot easier to get your contributions upstreamed and merged in. And I think maybe that's also part of what's helpful in OpenJS is like you kind of have these connections with other people from other projects and you're able to, like for example, if you need to talk to them about something in their library, then it's a little bit easier to reach out. And I had three different questions in my head and trying to put them in order right now. But first, just one question because I kind of got lost on track of time because I have something running here, but I'm kind of, oh, I got lost. Oh, damn. So... Jumping maybe to our conclusion pause. So what is how rewarding it is and what would it be the closing thoughts about to call in to say, hey, you can be the one to save the day, but you won't save just for the community. You will have a lot of big earnings from yourself, for yourself, like what would be your closing thoughts for those folks that want to step in but they're still a little scared? I just kind of echo, like try and find a small group and or a small thing that you think sounds cool or interesting and try and step in that way because it's smaller group, like narrow goals, it'd probably be easier. Reach out for help, like most folks are completely willing, but also kind of a call for maintainers because if you are a maintainer and you're part of a working group and you've been doing that role for some time, maybe take the effort to try and mentor someone else into the role as well and kind of like pay it forward because as I say, we may not all be around in the projects forever, we might change roles, change life, anything may happen. So I think it really, how when you become more senior at work, you kind of delegate some work and you focus on boarding, I think that approach really needs to happen because new people, new ideas, it helps the project evolve over time. I think the mission of Open Source is really cool and contributing, even if I wasn't paid to do this job, I think throughout my contributions to other Open Source projects that every, like it just feels like you're contributing to like a common good for the field. So it feels really good. And I think, as I guess it is an advice to people who may want to think about contributing, it would be really helpful to maybe just immerse yourself in non-code contributions at first or sometimes I feel like it's easy if you have something in mind, like a bug fix that you're running into and you kind of know how to solve, that's easy to just kind of rock up with a code contribution. But if you're unfamiliar with kind of the inner workings of the project, sometimes test fixes, documentation improvements and whatever can help you really onboard into a project and do self-learning in that way. And sometimes don't be afraid to ask me to teach stuff. I think that's also something that is pretty key, this kind of interaction between community and the people who have right access to the repo or whatever, who can maybe help you guide you along the way. And yeah. There's also one more thing that I particularly realized that I would like to have your takes and like a tip for people that want to contribute, that is usually newcomers, especially when they're starting to code, they come like, I want to change the world and change everything with a full of ideas. I want it to be super hands-on on code, but especially big projects and especially when they're open or open standards, they are on purpose, they are slower in the process. Any tip for people to still maintain this energy and enthusiasm to stay, but really commit to stay because I believe that would be my personal tip. I don't know from you, like when you decide it, take your time to choose a project, but stick to it a little while because it takes time for you to take a relationship, right? You don't jump into it, it goes slowly and then you build a nice good relationship. But what is your tip for new contributors on that day for this energy and commitment? I think it's important to not burn out, definitely. You don't need to hop in right away and make a million contributions and make your staff on the project or whatever, just easing in is good. And I think also being mindful, especially if you are more of a drive-by contributor where you want to contribute a feature, for example, make sure that it's also maintainable as well. I think that's something that people don't necessarily consider like, hey, this works for me on my project and on my pork. And sometimes it's hard to get merged in because of XYZ concern. And with how stable I feel the electron is nowadays and how we have very regular releases, it's hard to, it's not really the Wild West where it's like, okay, we're gonna yellow merge this feature because you need it for your app. So sometimes things move slower and that's also okay. Yeah, just really to echo like small and regular, I think. Just start small, maybe change one small thing or a small thing you want to improve, maybe the docs or something, like some specific thing you care about and do that little and often, I think. And then on the topic of burnout, I think when you're starting to feel burnout, like you were probably doing too much like a month before that. So you're already at that point, so really use back, so yeah. So perfect, I thank you both. I thank you OpenGS and our lovely audience. Thank you. Thank you.