 Why don't you all give a quick introduction on who you are and why you're here? So hey, everybody, Matteo Collina, part of the NodeJS Tech and Castilling Committee, board member of the OpenJS Foundation, co-founder of this company called, what is it, platformatic? New sweater, so thank you, Luca, for the new sweater and also author of a framework called Fastify and a bunch of other stuff. So if you're running JavaScript, if you're doing any software development, probably your software, my software is on your computer. So I'm, you know, that level of penetration. So, you know, donations are fine and useful. Thank you. Coffee works too. Hi, everyone. I'm Christian. I am working as funding engineer at Stateful and involved in the OpenJS Foundation as a contributor to the Reptaro project, which I have been maintaining for, I think, over eight years now and seeing the project grow over time and, you know, trying to build a community around it has been interesting and challenging at the same time. There we go. Okay, so I think maybe a lot of us know what community is. I'm just wondering, all of you sitting here, do you all think you belong to part of a technical community, any kind of a community? Yes. Anybody not feel like they're part of a community? Who's not involved yet? So, so we can kind of skip over that because I feel like we sort of all kind of have that grounding on what a community is. So when you all, for your projects, think about a community, what are the goals for you on building a community? Okay, I'm taking it. So they there are two kinds of essentially open source projects, probably more, but two major, two major families of open source projects. One are essentially company funded open source. So it's a way of distribution, essentially, and the company retains all the governance of the project. The other ones are the ones that adopt an open governance setting where you essentially the ownership of the project and the way the project is run is shared across multiple individuals, typically volunteers, typically spread across the community. Well, this is the typical, more of the typical vision of what we collectively think as open source, but you can totally be an open source project and not have an open governance or possibly also vice versa. So I just wanted to clarify that because a lot of the things that I'm going to talk about, especially on the concept of a community, are on the idea of an open governance project, which most of the projects that are open source foundation are. So the catch is what's the goal of having a community? Well, the problem is if you are a maintainer that creates this open source project and you release it to the world, it's the state, the fundamental problem is you want the goal for you should be to remove yourself from the project and the project to keep you running. And this is ultimately the like if the project can outlive your interest in it, then you have somewhat succeeded. Also, because there's a lot of influx of bugs, requests and things. And if you don't, if you are alone, you will burn out. And it's full of stories of burnout in open source. And then when somebody that happens, the project stagnate and the more the project stagnate, the more you burn out. And at some point, the project dies. Or if it doesn't die, it creates problems down the line for all its users that you nurture, that you care about, and then you feel horrible about it. I speak for experience. So essentially, you are at this state of more or less tension if you are alone. So if you're not alone and you're not part of a company that's funding the operations, what do you do? While you need to involve others to collaborate and work on your project? Well, and ultimately, the goal is to spread the load of maintenance. So with great powers come great responsibility in that sense. And if you're spreading the load of maintenance, you're also spreading the fact that you need to also spread the governance of the project and give you know, something away to some extent, and which is good though, because it's, you know, you want, usually if more people, more diverse people are involved in the decision making process of a project, the actual outcome is going to be better. That sense. So that's, so ultimately, the goal is for the community to some extent to take over in running your project, at least in open source. I want to add something to that. I totally agree with Mateo's view on that. Another value that a community can bring for companies adopting open source projects is security, right? You know, with company or corporate driven projects, you know, if the corporation A doesn't pay maintain a B anymore, the project is likely to die. And a lot of companies out there, they seek and look out for open source projects that are community driven, where they have some sort of security that, you know, when maintainer A disappears, there's a maintainer B that takes over. And that is a big value add that, you know, with community driven projects that comes with it. And we have other communities too. In JavaScript, we have the OpenJS Foundation communities, right? So Mateo, you're on the board and Christian, you're on cross project council, you're cross project, cross project council talk about the importance of building a community across projects. And why is that important? I think generally, we all, you know, work in the same field, we all work with JavaScript. And it's just great to have people, you know, to listen at the call up summit to people to the note community, and and see what they're gonna be up to. So I can know as a, as a user of Node.js with my framework that, okay, these changes are coming up in order to prepare my project for success in long term. Those are the changes that I need to prepare to put into the project. So the challenge in so why the CPC exists or why the OpenJS Foundation to some extent exist is there are a set of challenges that running open governance open source projects, poses to the maintainers. And most of the, a lot of those things are not really are not really in the skill set of the of the of the maintainer themselves. So because of that, group like the cross project council and the foundation and the board and all the things that touch so it exists. And it provides great services on the projects. It's, to some extent, the way I see it is is worth that needs to be done. To some extent, it's, and it's great that that is, or I didn't know that was, I think it was Sarah chips that mentioned it's the bureaucracy of open source projects or something. The bureaucracy of open source and, you know, and it's great that people are really wanting to get that bit done, because it's actually, it's actually hard. Okay, like, and from help in, you know, conflict escalation and moderation and all sorts of things are very hard. And a lot of time, it's a different skill set compared to what we usually do. So Yeah, there's all kinds of communities. I mean, I built my career on community engagement and marketing. There's a big legal community in open source. Now I have my executive direct direct director community at the Linux Foundation. So you do learn a lot from each other. And just, yeah, and yeah, you just learn and can apply a number of scenarios. So let's talk specifically about web driver and maybe fastify on how the community has what sort of what are some concrete things that you have done to build community and what are the the direct benefits that you've received from the community. So one of the things, you know, there are different times of contributors, right? The people that pass by and post issues, the people that maybe do some regular commits and contributions and then the core people. And in order to kind of like, increase contribution from all three sectors, you got to kind of like build a funnel, how can get more people in these in these buckets. And one of the things to get people interested in contributing is like, and at my, that works at my size for WebDivio, is like, provide open office hours and invite people, hey, if you want to work on a pro on an issue, particularly, I'm going to help you, you know, conquer the code base and in, you know, win with your first poor quest and contribution. I set up a chat system or like it created discord server for people to join where, you know, I can see what the pain points are for the people that I cater to and, you know, see what they want to see from the project and to understand what needs to be built. And there were various of other things that, you know, can help to build communities around the project. So for me, this was actually like part of Fastify and the decision that we I have made in creating when I started to think about starting this project where very deliberate in what were the values of that specific community. So where came from to be honest, specific planning phase or a specific looking at the status of the other projects and what what was what was the problem there and why major projects in the Node.js ecosystem had essentially close to no maintainers on on them very small teams. And how could you start to build a community where, you know, it's everybody was chipping in and collaborating to maintain, maintain the framework. So what we have done was so the first thing was, well, I'm just going to start building that this new technology, if I can convince another human being to build it with me. So this is that I started with one person, I mean, in order to do this, I need to convince another person to build it with me. Okay, this is the and from there, which is the entities of a lot of our other open source projects are born. Okay, I have an idea. I sit down and code it and build it. Now, this was if we want to build this, this is going to be way too complex, require me way too many people. I don't know many of us so Fastify is an HTTP framework for for node in order to implement this kind of stuff, you need to know the HTTP specs in and out. And it's actually a lot of plus a lot of JavaScript. There's a lot of API design, interesting problems to solve over there. So anyway, what I've done is, and then, you know, create another point come from an previous experiences where, you know, I was always tried if somebody opened an issue to answer that issue for them and solve that problem and put a fix. And instead here, I just decided, nope, I'm not doing any of that. I'm just saying, look, if you want, this is the commons. Okay, so it's your house as much as mine. So if you complaining that there is a scratch, you need to take your you know, is the paint, go, go paint a scratch. Okay, I'm not going to I'm not going to do it for you is your house as much as mine. And if you have this problem, you know, it's the toilet is broken, you know, it's, it's everybody's responsibility to fix it, right? So that's the reaction has been fantastic. Okay, and enthusiastic or not, in the sense. But that's the interesting part. I was not caring at all of, at least at the early stage, in attracting the people that didn't want to be part of the active community of maintainers. So this is the most important part. You want to cater for that specific block of people that are going to sustain the project long term, especially at the early stages. So and keep growing that group of people all the time. It's expectation setting, right? If you if you at some point, if you just, you know, fix it back for yourself, every again and again, then you you you create and you create a like, surrounding where it's like, okay, it's that's a service I can go there, fix a file back and people will fix it. But if you create a clear expectation of like, here's a bug, you filed a bug, that's good. Here are the ways how you can fix it. People are incentivized to get back. And I tried that in my project where it was like, instead of going about myself and fix it back within, I don't know, an hour or two, I gave people exact directions. Here's the file that you need to look into. And people were field empowered, and they're like, okay, cool, I can take this on. And, you know, this saves me time and makes people feel empowered and do their own changes. So it's not just lofty words and, you know, on setting culture, like just some real specific things that people can walk away with on on building community. Yeah, I would love to see in open source in general, more incentives where maintainers go out and provide people clear direction is like, where you can contribute, where can you provide value because there's so much we talk about, you know, open source projects always about code contribution, but there's not there's like so many value streams that open source project can, you know, receive or want to receive. But often there's just a missing documentation where it's like, what do we want? What do we need? And communicate this clear to the audience and to the community so they can feel empowered and to contribute back. Let's talk about the stages of contribution. I mean, I think one of the misconceptions I hear when I speak to maybe if you don't speak at an open source conference, you speak at just a regular tech conference, people think you need to show up to a project with 10,000 lines of code and solving a huge problem that no one else has figured out. So talk to me about the stages of contributions. I think we have one, for example, of Claudia, right, he joined the new chairs community, making great conversation to, to, to the documentation system and then, you know, you know, become more experience of where the community needs help. And I think that's where everyone can just go about if they have an open source project that they like, just join the community, look in and, you know, just by even like helping other people to succeed with that tool is already value enough to, you know, start, start with that. And then, you know, you work your way up. I think that's a, that's a great way to do that. Yeah, but I tend to see four stages in the of somebody, of people, you know, using open source. The largest group is what I call them, the lurkers, which do not, the passive consumers, or putting it in another way. You are passively consuming open source. We are all passively consuming open source in one form or another. I am a passive consumer of the Linux kernel. I'm not contributing. I'm not opening issues. I did in the past, but that's a long, a long time ago. Okay, I decided not to, it's too much work. But it's, it's a great project to contribute to if you like that kind of stuff. But the gist is, these are the passive, you know, the passive consumers. Then you have more active people that can, you know, open issues, provide reproduction, maybe every now and then on the issue tracker, you can see their name. And some of these is, these are value substages. There is the first one that just pop an issue and then disappear. And people that come in regularly and you want to be them, you make, want to make them regulars. Okay. And you want to nurture them. Then you have people that start to produce code and contributions and non-code contributions too are valuable. Anyway, help the project. And ultimately, then stuff is people, oh, this guy or this gal, they've done a fantastic good job of maintaining the providing code that I want to bring them as part of the maintenance team. And then this is, to be honest, it's a funnel. Okay, you need to think of it as, to be honest, it's a funnel. And you need to think it that way and see that you want to help people. You need the end, you need people at the end of the funnel to make your project sustainable. And these needs to have value for all the actors involved for successful, for a successful open source project. So, and they're great tools that help you to create those funnels. I use a tool called orbit and they provide free services for open source software. And I see when someone is not engaging within two weeks and I go back to them and nurture them, it's like, hey, I check in with them and say, hey, what's up? Everything okay? And should we work on something together? So, they're tools that help you to create this, to build these funnels and categorize your members of your community. And what other, how else are you using data to measure your community engagement? Thinking about from your small projects to maybe some of the larger projects that node. I mean, are you regularly, is there a gut check on that? Do you notice patterns? I have to admit that I open NPM stats almost every day for the last six years. Seeing the stats going up is like, for me personally as a maintainer, exciting to see. But yeah, to come back to that, I have been playing with a lot of dashboard tools for open source in the past. And so far for whatever I've been settling with orbit, they provide you great, they give you all the list of members, they give you information about how active members are. And it's have been really helpful tool to categorize your community members and the organization behind that and see how they engage with your project, not only on the GitHub, but also on Twitter, Discord or YouTube. That has been a great tool for me. Apart from download metrics, which are very, very helpful, it's something that is even more, to some extent, it's on when growing a community you typically need to, you have a few bits that are fantastic. So when you, for example, you need to use a chat system. And with chat system, you can always, if you're not having a chat, it's a massive problem for open source projects. So you want, you really want to have some level of a chat, so that you can very quickly talk to somebody without thinking, oh, how can I find, how do I find their email address? And this is very simple thing. So you have your GitHub, you give your chat and with your chat system, then you can ping them, but also you can see how many people are online. And when you ever start having a nice of a little bit of a community inside the chat, you are at a point where people start helping each other. So if you look into the Fastify Discord, it's basically, essentially, self-serve. Like, we need, most of the, like, only a few members of the team are there, but most people just help each other. So, and that is super helpful, most of the time, for them. So you reach that stage where, essentially, you have, the community is helping each other. So it's not relying on you for help, which is the, to some extent, that goal of it. So it's great to see. So we've talked, you talked a little bit about different types of open source projects. They're company-led projects. There's community-led projects like Node. There's still community across both, but how would you, I mean, what are the differences from community building and participation? Yeah, I would add two more types, which is, like, the solo projects, right, the hobby projects that people have on GitHub, and the so-called monarchist open source projects, like Python, would be a good example. All these different kind of types of different incentives and different interests of how to build a community. For community- driven projects, especially, is like, they live based on the community. All their value streams come from people that just have fun contributing to the project. And, yeah, for that is particularly important, for those projects that are pretty important to build out this community that provide value to a project. When it comes to then corporate projects, you know, the values, they are not that much interested in building the community because they have the company A that is funding. And, you know, that works. And for, I think, the foundation based projects, GraphQL, as an example, they have an impact enough that there's enough interest that companies fund the project with people and money. So, when it comes down to community building, those community-led projects are most, you know, affected by that. Yeah, it's the growing, I, you know, at this point, I'm part of, I'm doing a startup. So, in open source, our main product is open source. And we are essentially doing it again, essentially building a little community around this. And you can see the difference that there is a fundamental difference and fundamental different expectation of what a community for, for a project that's essentially run by a company versus a community that is born out of, that is an open governance community. Okay, there are two fundamental, there's two fundamental difference. And in one it's, you know, you are, in one, you need to help the people using your stuff. Okay, because you are creating the community, you're going in the community to, for them to make it easy for them to use your product and so on. On the other end, you're doing it to survive. So, it's kind of different. And it's both ways, because you don't want to, if you're building a corporate community around a product, okay, you are, you're building it for, and, but you don't want to transform them into mindless fun boys. Okay, if I, you know, somebody's laughing because I, this is probably a reference to a few things that are out there, but it's, you know, there is, I'm pretty much skeptical when somebody's just super becomes a zealot of certain, certain way of seeing the world. So, and I still, you still want to be in a place where you value critics, you value, you get there, they can still be part of the decision-making project, the process of, of the product, but it's, it's a slightly different dynamic, as I said. Interesting. Okay, so if someone out here is, you know, they're, they're here at the conference, and they want to become part of a different community, this community seems great. What should they do? They would go out and see projects that they find interesting, and I think it's all, you know, having engagement comes out of personal interest, mostly, and every community often is welcome enough to just, you know, have people looking around, and then provide them ways to contribute to their community, and like, I can just re-emphasize what I mentioned before, it's like, I try to, everyone who joins the Discord channel, I'm like, I want to check in with them, and be like, hey, where do you want to contribute, where do you want to, what are your projects and your fields that you're interested in, and I hope that every project has something like that, and if not there's, you know, as someone who joins the community, it's definitely not wrong to create an issue and be like, hey, I have these skills, how can I help you, you know, with the, in the project? They can do that, yeah. Awesome, I love that idea. It's amazing. Works very well, yeah, for, for Fastify is mostly on the, on the issues, so, you know, it's, at this point, it's, it's, it's very, it is becoming more, a little bit of a meme to some extent, it's Matteo asking, somebody asking people, hey, you know, it's a good, this is, thanks for reporting, can you please send a poor request and remember to add unit tests, and this is the, it can be a meme at this point, you know, it's been, been asking these people all the time, all over the places, and, you know, it's, well, you know, the answer there is either you're a member of this community or you're not, and it's, you know, it's, it's what it is, so a few people have said, no, I'm not using your stuff anymore, and this is the answer that I got a few times, and I said, oh, good, that's my, the answer is, yeah, great, it's, it's one last thing to, to support at least, that's, you know, you don't want to engage here, so you're, you're, you're basically self-selecting at this point. One concrete example that I've recently experienced is, Augustine, he chipped in the call-up summit, he created an issue and said, like, I would like to see the WebDive ODocs translated in French, I'm like, okay, let me revive my engagement in, like, with crowd-in and connected docosarrows with crowd-in, and I hired people on Fiverr to kickstart the translation and translated, like, the documentation into Spain and Hindi, cost me 800 bucks, I translated German myself, and then I released about the website in three different translations, and that has kickstarted, so many other people will be like, wait, we can help translating the website, it's like, that's awesome, and then people now, we have this issue for translating the documentation, people go there and be like, hey, I can translate the website in, I don't know, Tamil or other languages, and I'm open in the language for them, and they just go ahead and translate it, that's like, I find this awesome, and one of the examples where it's like, someone comes there and be like, hey, I can provide translations, and, you know, you help them be successful contributing to the community. Do we have any questions from the floor? Claudio? Yeah, the first question that I have is, it's related to mental health of maintainers across, for example, internet can be very non-forgiving, right, at times, how you deal or how you should at least have dealt with the unfortunate moments where the community at large isn't really nice with the maintainers, how do you keep the cycle of them feeling motivated to keep contributing to open source even when the community is at their necks, you know? I have a long answer here, so if you want, I'm sorry. I can just answer from my point short, when I get fed up or when I feel burnt out, and I see there's so many things coming at me, I see that at myself by not being very kind in my answers, now we're going to become short, and I see that and then I step out for a day or two, be like, that's enough, and then I come back and see things with different eyes, and especially when, you know, other people's posting issues or answering to your issues don't answer with the nice set of respect, I just step out and come back and then the world sometimes looks different, and then move on. I had some pretty bad burnout, experiences where I stopped maintaining projects, as you know there is a few of mine, I have a few graveyard projects or putting projects in the graveyard that they left out there, and look a few of them are still, I don't know, a million downloads per week or half a million downloads per week or something that makes, you know, why the heck you abandon this or whatever, comes from multiple set of the toll comes down to what I call there is an imbalance between the number of the community expectations and the number of maintainers to support those community expectations, okay, so it comes from this imbalance, and you need a certain, you need a ratio, but this is different from each project, but you need to have a level of representation of these amount of maintainers are needed to, for this large, at large community to exist, and if things are not meeting those expectations, if things are not matching, you got this situation of burnout or frustration, and it can be good at times, so you can, you can have a peak of things, a peak of influx of new members of the community of users of your, of your open source project, which makes it enlarge the community, so makes more bugs, more things, then it goes down, because for some reason you cannot service them, and they just, no, I'm fed up, I'm going back using Python, okay, and not using Node anymore, okay, and Node does a lot of surveys and collab summits to prioritize. Yeah, pretty much, so again it's, so to be, this is a good example, thank you Robin, so essentially it was a few years back, there was this perception in the community that Node was stagnating, and Node was not following what they, where the need of, of the community, okay, and I remember being in, in a collab summit between 2017, 2018, something like that, where I, I laid out, I don't know if you were in the room with another time, or at this point, but I laid out a plan, or an aspirational plan to ship fetch in Node, like the thing that everybody was requesting in Node.js was, let's say we need fetch in Node, and, you know, I was discussing it, and it was, I laid out this, it's still online by the way of the presentation, and I laid this plan to ship, to ship fetch in, in Node, and it only took, I don't know, maybe four years to get there, it's, you know, I said, with a lot of meme, we made fetch happen, okay, it's, you know, but it's, because those things take time to move, okay, from time to time, it's not just as simple as a lot of people would, would think in the community to the two, make something like that complex to actually happen, but eventually we started back listening to what the community wanted to say, was saying for to us, and then we started adding those prioritizing, we started a group called the next 10 years group to decide of the technical priorities of the project, and some of those are still, were, were those things, and some we shipped, like every single body, every single one, the top most needed thing that everybody's telling to these days is, oh, you should get better typescript or more tight typescript integration. Now, this is a massive amount of debate in the community on how to do that, and a lot of very interesting discussion happening all the time, but this is essentially part of, of the process. But again, listen to your community, your community more or less will ask for what they need, and from some of that group, there are probably also potential people that can help you do those implementations. Otherwise, it won't be, it won't happen. So yeah, that's, I hope I answered the question. I think so, priorities. We have one minute. All right, Sameer. Thank you, Robin. Great topic. My name is Sameer Johola. I'm the executive director of Agstack, which is a project of the Linux Foundation AG in agriculture. My question to you is, how do you, what tools and processes have you used to found to be useful to engage the community to solicit the topics themselves, the questions that are worthy of a community, so that it's not just the loudest voice, one or two people who kind of are interested in coordinating, but they sort of drawn out the quiet voices. As an example of that, in our community, we have a really interesting problem. The tech people don't really understand agriculture, and the agriculture people don't really understand tech. And so we really, when we ask the tech people, what are the questions they want to answer, the results are completely different and irrelevant to the agriculture people we ask them, and they ask, give questions about the topics that are totally, you know, go over the head of the tech people. So this may not be a direct translation to what you guys have been doing, but how have you found to be successful convening of questions? What are the questions to ask the community about, so that not the loudest voice always wins? That's a good question. Trying to translate this to my use case or enterprise demands on projects. So from my, so typically what the way I have approached this and helped in that decision making is first thing you need to, this is Brutal, try to gag the loud voices. This is as bad as it sounds, but you need to create a place where the quiet people can talk. And from time to time it means pushing out somebody that is very loud, very opinionated, and does not leave other space to express themselves. Or most of the time they don't even realize that they are doing it, and you just need to tell them, oh please let the other people speak, okay, or and so on. They are considered, especially in open source, that is, and it's a phenomenon that I've seen multiple times happen in the North community, is people that engage in wall of text to prove their point. Okay, and it's, somebody knows what I'm talking about. So if you want to stall an issue, you know, progress in open source, you just keep writing long and long pages of text to, to block it essentially. And you are filibustering, this is the term that you as people use as, you filibuster the issue up until the other person give up. You know, this is what, this is, and at some point, if you are on the leadership of the project, you might need to intervene to essentially stop that. And your community needs to be able to stop that specific part. Now, if you can stop that and allow everybody to contribute, this is the first step to answer that, to go into that direction. Okay. On how do you get to ask the question, you, the way you, the way you're describing it, you have a community that is true-sided and those communities that are true-sided are, are created around a few special individuals that are part of both worlds. And identify those special individuals, the people that are able to, to keep one fit in one, in one world and, and in another and they can help you create those bridges. And those are the people, and typically they're very quiet too, most of the time. So, but you need to get them to speak and that will give you the answer. And otherwise a project like, like yours, there are already because the project otherwise will not exist without them. It's just identify them and let them. What are the questions that, you know, let them speak essentially. So, I hope I, I give. Yeah, I, I second that. It seems that your community is kind of like separated with two groups that have different desires and pain points. So, one way could be that you cater your community engagement to these different groups individually and filter out the responses and be, then be able to connect the white people with each other based on the responses that you get. Like it's, I think it's hard to cater a single value stream of content to both when they have both different pain points and desires right. So, separate them and like look at them from a new individual perspective and then connect the dots based on the responses that you get from the community. Well, thanks everyone. I just want to close for folks who are watching this online. There's a number of ways to get involved in the community. Hi, Mom. We have a lot of us publish our calendars of our meetings on our websites. We have one at OpenJS, the Node Project Web Driver. You have it as well. A lot of the calendars are on GitHub. So, yeah, find us. We also have YouTube channels. We stream most of our meetings live on YouTube. So, if you want to see what it's like you can go check them out and join us. Thanks. Thank you all. Thank you.