 Hello, everyone. Thanks for joining us at OpenJS World 2021 for our keynote, Open Open Source, and making great places for collaboration. My name is Joe Seppi. I am an open source engineer at IVM, primarily working in the Node.js space and at the OpenJS Foundation. Beth? Hi, everyone. My name is Beth Briggs, and I'm a senior software engineer at Red Hat, where I spend a large portion of my time contributing to the Node.js project. And I'm Michael Dawson. I'm the Node.js lead for Red Hat and IBM. That means I get to spend a lot of my time working in the community, various working groups, the technical steering committee. But it also means I get to work with great teams within Red Hat and IBM and people like Joe and Bethany in the work that we do for the Node.js in the Node.js space. So we're here to talk about open, open source. And I think the reason that we're talking to you is because we're all have been very active in the Node project. And the Node.js experience is where we've seen that sort of approach really proved out and some of the advantages and some of the challenges that we see. Some of the key elements are that no one company has control. You see a lot of projects out there where they're open source, but usually they're sort of led in the direction set by a particular company. Node.js has no one company doing that. It's really a group of companies who come together. And interesting sort of go ahead, Joe. Yeah, I was going to say there are rules in place to kind of prevent that too, which is great. But one of the things that I love about the work that we do in the Node.js space and the way things are set up is that everything is really transparent and accessible. We try to do all of our work in issues and pull requests and working groups and things like that. So the barrier to entry should be the doors are open, I'll say. Yeah, certainly that transparency and the work that we do to make sure that anybody can come to the project and work on that level playing field is sort of a key component. It's that if I'm invested in Node and I want to depend on it, me as an individual and certainly organizations want to have confidence that they can get involved and move the sticks forward in the areas that are important to them. And that open, open source approach allows everybody to kind of work on the different areas that they think are important and have the whole project move forward much faster than I think projects that are driven by a single company because there's only so much that one person can kind of stick into their head and keep on top of and this sort of distributed approach really lets us move forward in all sorts of different ways. Yeah, I certainly think that's probably one of the most surprising things people find about the Node.js project is that because we are open, open source and everyone comes in with their own ideas, we don't have a roadmap. We do have initiatives and ideas and plans, rough plans in place within the working groups about what we might like to do, but there is no, we want to deliver this by this day. I think people do tend to find that surprising but it is an outcome of us having not one single company or organization driving the project. Yeah, and certainly what seems to come out, what comes out in a release is what people have decided is important and worked on and it's sort of an amalgamation of that all of the across the way. And you mentioned we don't have a defined roadmap. That doesn't mean we don't have plans and goals and things that we think are important. The working groups and teams are bringing together people who are working on areas that are of interest to them. So the people who work on the build side of things, the people who work on say new HTTP clients. So there's lots of people who come together with sort of a vision of where they think they want the project to get to but we don't necessarily have that as a top down driven effort. It's more of a bottom up here, the people coming and I think that's actually one of the really interesting things about the sort of open open source approach and what makes the note experience really interesting to me anyway. So yeah, people are very surprised that they can just turn up to the project, contribute PR, start participating in issues or start joining our meetings. All our meetings tend to be open for everyone and to join you can find the calendar and just join them. And I think people do find that surprising. They need to know that the project's open in that way for anyone to turn up and join and that does come with the challenge of making people feel comfortable and we have worked hard to train, level the barrier to entry so people are comfortable in doing that. Yeah, I know I often get that question, like, well, how do I join the meeting? And the answer is there's a Zoom link, you can show up, you can participate just like everybody else, but sort of making sure people are comfortable and then comfortable to speak up is an ongoing effort within the project. And then similarly, sort of, people being comfortable that they could lead a particular area. So the project, we have some really good experience in NodeCore, but it actually covers a very broad range so people can come to the project and have some domain experience which is really, really useful. And in fact, they may know more about that particular area than anybody in the project and making them feel comfortable enough to bring that experience and share it is one of the things that we need to continually sort of work on and remind people that they can do that. One of the things that worked well within the release working group which was one of the working groups I'm particularly active in is we set up some mentoring sessions. So in the calendar, we blocked off an hour every couple of weeks where anyone who had an interest of joining the release working group and maybe eventually helping to produce the releases of Node could join and just shadow the process, ask questions, learn about how they can pick it up and pick up the release. And we found that worked really well. I think we onboarded around about three new releases from those sessions and it's not an easy task to grasp. It's not something you can just read a doc and then get on with it. So I think it was really valuable and it was really great to get new people into the project and help out. Yeah, it seems that that particular efforts was very successful. I've seen the release team grow and that's really fantastic. And the mentorship program overall in the Node.js space has had other successes as well. I know, Michael, there's a recent mentee for the Node.js. Yeah, and that's something where that helped them feel comfortable to come in and work with us. I know they'd have people who would talk to them and it makes me think that we try and do everything in GitHub as much as we can to be transparent, to let people participate across the time zones. But at least for me, that sort of personal touch of being able to talk to people sometimes is invaluable in making somebody comfortable and being able to ask the questions in a little bit maybe more comfortable situation than putting them into it to GitHub. So I think that that part's the key thing that we'll need to continue to work on. Yeah, that's a good point. I think that there are lots of ways to get involved whether through GitHub and the issues and such but also like you said, the personal touch stuff with Slack and in the meetings as well. I guess the flip side though of making, bringing more and more people into the project and making them comfortable to speak up which was what we want is that consensus can actually be hard sometimes. The more people we get involved, the more different views there are. And so sometimes that actually can be a bit of a challenge for the project like how do we get to an answer when we've got lots of different views. And my personal view is that sometimes it should be hard. If we're making a big decision, it's better to have that stretch out a little bit longer to factor in all the different views and often I've seen that result in a better decision in the end. I'll admit it can be quite tiring and that's one of our challenges is how do we find the right balancer because we don't want people to be so exhausted from the discussions that they don't want to contribute anymore. But at the same time, I think we need to not rush some of these discussions because we need to get everybody's input and see if we can find something where there is a consensus. Yeah, I think balance is the key word there for sure. And I think, you know, in terms of getting people's input, a good example is the surveys work that we've been doing, you know, with the next 10 effort and the unhandled promise rejection work. Those are really great ways to get people's input. Yeah, and that's like not necessarily a survey to decide the question, but to give us some additional input and contacts for how we try and, you know, come to a consensus within the project itself. And the project's structured in a way that when it comes to it, we have the technical steering committee that can vote on particular issues, topics, PRs where consensus hasn't been able to be met for a significant portion of time. But we do try to avoid that. We hope that consensus can be resolved out in the community amongst the wider collaborator contribute base rather than being elevated to make a decision. But obviously in some cases, if it's gone on for a few months, you do want that kind of escape hatch to make sure that things can move forward and not just indefinitely blocked. Yeah, consensus can be challenging, but I think it's definitely a feature. And, you know, when we merge the two foundations together, the JS Foundation and the NodeJS Foundation to form the OpenJS Foundation, we took a lot of the learnings that we had in building this open, open source space in the NodeJS Foundation and tried to bring that over to the OpenJS Foundation, which I think has been successful. Yeah, I think it, you know, and one of the reasons why that makes so much sense is that the project, the NodeJS experience, it embodies a lot of those things that are important for individuals and companies who want to rely on, you know, packages and products and projects in their production environments. It has that, you know, sort of open and level playing field where, you know, if you come in, you can contribute, you can move things forward. Your voice is heard. We take everybody's views into the consensus versus, you know, if you have a project which is predominantly run safe by your competitor, you may not be nearly as comfortable as depending on that as one that would be under this kind of model. And the OpenJS Foundation is a great place to sort of foster that experience because if you move from, say, a single company, you know, supporting the open source project, you need somebody else, some other organizations to step in and take up some of the pieces that they would have done, you know, providing the things like Zoom accounts and emailing lists and just sort of the basic resources that are available within a company but aren't necessarily freely available to an open source project unless they're part of a foundation or something like that. Yeah, I agree. It's like, it's a single home for, you know, the JS ecosystem to be, you know, stable and, you know, growing well, you know, and especially for companies who want to support that work. But like you said, it's a place to grow that work as well to have the support from the foundation, to do things like the surveys, the package maintenance work. And there's, you know, there's so much stuff that we can do to really support the community at the foundation level. Yeah, and the other thing I'm kind of excited about, I'll just quickly mention is like the collaboration spaces. So the foundation, you know, from the beginning has supported projects and collaboration spaces are another way where we can support discussions, initiatives, which are not necessarily a project but are also very important to the ecosystem, the Java ecosystem overall. Yeah, and we can talk a moment too about like why people get involved. And I think, you know, that collaboration space is a great place to get involved. But like, you know, in my experience, working at companies that use open source, you know, you want to get involved in the project and help, you know, fix bugs, keep things stable. You may need features, you know, there's so many different reasons why you would want to get involved in open source. Yeah, I find, oh, sorry, go ahead, Bethany. Yeah, I find maybe folks at smaller or medium-sized companies sometimes struggle to get their employers to appreciate why they should contribute to open source. And I've found over time, the best way of it being framed is if you're consuming these projects in your company and consuming open source and using it to stand upon and deliver your service by allowing your employees to contribute, you're actually helping manage the risk because if someone stops maintaining that dependency or the open source project you're using, you're gonna be rather stuck and you will have to invest that time. So why not upfront try to invest some time spread out across, you know, your development year to just help keep these dependencies stable? Yeah, and I guess in terms of the risk is like I often see issues which are like, hey, I'm having this problem and then you can see people are getting frustrated in those issues because somebody doesn't immediately answer them, but like the reality is you're using a project, you're not paying anybody to support you for that project. So if people are helping you, that's because, you know, they're volunteering their time, they think it's in the project's overall best interest, but you shouldn't depend on somebody else necessarily being able to have that time for you when you need it. And by letting your employees be involved and help maintain the things you depend on, you can help yourself and that's really the position you wanna be in, you know, to either work with a partner who will help you or to be able to help yourself in those projects. So it's important to contribute, you know, either directly or indirectly to the open source projects that are really important to you. Yeah, I think too, you know, at like a personal level, you gain amazing skills in working in open source that are valuable to a company, being able to work well with others and find consensus and, you know, work through certain issues that come up often in open source. It's definitely a skill to appreciate. And then also, you know, it's a great place to hire too. Previous company I worked at, we did a lot of work in open source and we hired a couple of really great people through that and I got to see them go on to do really great things in open source through that work. Yes, certainly the skills that you grow, you learn in an open source project, apply to working in a larger company at least, where, you know, you're trying to get things done, you don't, can't necessarily tell what people want to do when you have to work together in a collaborative manner. I mean, I think you gotta do that in any kind of company. So they're really great skills to learn. Yeah, it's a really great way of building, building your personal kind of brand around the work you're doing. And I've seen so many people, unless resumes and CVs just saying, calling out their open source contributions, which is great to see. It's great that you can do the work in a place where the broader community can see what you're doing. And yeah, that's a really good note. So that's kind of why to get involved. And there are some kind of key ways you could start to get involved with the OpenJS Foundation and the projects within the foundation. So first, it's worth looking at all the projects in the foundation at this around 30 or so, and seeing whether there are ones that you use, you're particularly experienced with, or maybe just have an interest in that given area, and maybe look at that project and see if they have good first issues or things like that. And particularly if you're looking to get involved with an OpenJS project yourself, we do have the structure within the project with the teams and working groups. And I find a good way to find to get involved is to look at the list of team and working groups. And again, if there's one that particularly resonates with your interests or your area, check out their GitHub repository, join their calls, which will be on the OpenJS Foundation calendar. And all the calls are open to everyone. You should be able to stream on YouTube going back to the open open source. And we try to stream all of our meetings so all of our decisions are there for everyone to see. And yeah, so everyone's welcome to join the meetings, joining events like OpenJS World is just a few of the ways you can get involved. Yeah, as we said before, it's a great way to make the personal connection, those teams and working groups. The other thing I'd recommend is like, try and work within your company to get them to actually support your work, to make it more than just your side job because we're lucky IBM and Red Hat are very supportive. We have a portion of our time to work in the community and that actually makes it a lot easier to contribute. So working within the company to help them understand that you're actually reducing their risk and that you'll be there to help fix issues, identify issues in some of these key components that they're depending on, I think is also a good component in terms of like how to be able to contribute in a more sustained and sort of long-term manner. Yeah, I'll reiterate, I feel very fortunate that IBM and Red Hat supports the work that we do and really I think they see the value in the work that we do and contributing to open source as it pertains to their business. But we to kind of get back to the whole open open source thing and to just sort of reiterate what Beth was saying as well, there are lots of ways to get involved. Again, issues, pull requests, openjsf.org slash collaborate will give you a bunch of resources in terms of joining the Slack and the calendar, nojs.org slash calendar is where all the nojs calendar lives. And again, just you can join a meeting, you can join a Slack, start talking to people, even if you wanna join a meeting and just kind of hang out and see what's going on, that's fine too. Just get involved and see where your interests lie and start looking there. I guess at this point, that's probably all the time that we have, thanks for coming and watching our keynote. Hopefully we've given you a little bit of insight into the open open source approach that the Node.js project has, some of the things that are going on and have sort of inspired you to get involved if you're not involved already. And we hope to see you in GitHub and across the projects. Thanks, talk to you later.