What We Owe to Each Other

Rate this content
Bookmark

Open source has won, and it's the center of gravity for our community. Whether we're contributors to open source projects, commercial product engineers, companies, developer advocates, or something else, we're all a part of this community. And we owe it to each other, and to ourselves, to leave the community better than we found it.


But how do we do that? What responsibilities do companies have to the community? Or developer advocates? Or OSS contributors? How are we failing those responsibilities, and how can we do better?


In short, what do we owe to each other? Let's find out.

24 min
05 Jun, 2023

AI Generated Video Summary

The Talk discusses building and supporting the JavaScript community, the role of companies in open source, the importance of time and collaboration, reporting bugs with kindness, the challenges of developer relations, the role of maintainers and documentation, the importance of inclusivity, embracing change in project development, supporting ourselves and the community, and finding hope for a better community.

1. Building a Thriving JavaScript Community

Short description:

Hi, JS Nation. I'm Brian Hughes, a staff front end engineer at Patreon. I've been part of the open source community for a decade, playing various roles and contributing to projects like Node.js. In this talk, I'll discuss how we can grow and support our community and what it means to be an upstanding citizen.

Hi, JS Nation. My name is Brian Hughes and I'm a staff front end engineer at Patreon. I've been a part of the open source community for about a decade now, which is kind of wild to think about. You know, I've seen this community grow so much during that time.

And you know, I've been fortunate that I've been able to play a variety of roles within the community. You know, I've started my own smaller open source projects. I used to be pretty involved in the Node.js project. I've also been working as developer relations in the community. I presented at lots of conferences, and, you know, I've used open source in my day-to-day work a lot.

And like over this time, I've thought a lot about like what it takes to build a good community and how we can help this community thrive because we really are independent at the end of the day. So I want to spend this talk talking about exactly that. How do we help grow this community? How do we help each other out? Basically, you know, what do we owe to each other?

So this talk is inspired by this book of the same title by T. M. Scanlon. Scanlon's a moral philosophy professor, wrote this book about 25 years ago. I don't expect many of you have actually read this book. Admittedly, I'm only about a third of the way through this book myself, but a lot of you have seen this show, The Good Place. So it turns out The Good Place is actually inspired by T. M. Scanlons book and it kind of has that philosophy at the core of the show and the show. I love the show so much because it's all about growing and becoming better than we were yesterday and how we come together, support each other. And it's, you know, through all of these characters growing closer together that they end up, you know, succeeding with all of their wild adventures they go on. And it's just all about community. You know, that's what they do is they form their own small community. And you know what? We're a community, too. It may not always necessarily seem like that, but we really are. Even if we're just using open source, we're still taking part in this community. And, of course, for all of you listening right now, this is a conference for us to come together as a community. And I think this is so important. And it's led me to ruminate on this question of what does it mean to be a good community an upstanding citizen in the JavaScript community.

2. The Role of Companies in the JavaScript Community

Short description:

This is a complicated question. And there's no one-size-fits-all answer to it. A lot of it depends on what kind of role you have within the community. I'm going to focus on three in specific: the role of companies, developer relations, and project maintainers. Companies stand on the shoulders of open source giants and benefit from open source. It's important for companies to give back by supporting open source with time and money. Companies and the open source community have a symbiotic relationship. A good example is Observable sponsoring the CodeMirror project, which improved their product and helped the project grow. Companies should consider contributing to open source projects like becoming members of the OpenJS Foundation.

This is a complicated question. And there's no one-size-fits-all answer to it. A lot of it depends on what kind of role you have within the community. And we could spend all day talking about there's so many different kinds of roles people can play. But we only have so much time together, so I'm going to focus on three in specific. I'm going to focus on the role of companies, focus on the role of developer relations, and on that of project maintainers themselves.

Let's start by talking about companies and the role they have to play in the JavaScript community. Because really these days, companies stand on the shoulders of open source giants. Every single web app I can think of that's out there today I'm sure has open source at the heart of it. How many web apps that companies have created are getting out there, getting customers and all of that, how many of those products are based on top of Node.js in the or Python or some of the other open source server runtimes? How many apps are written using React? How many are written using Webpack to build? How many use TypeScript? VS Code? All of these are open source. Some of these were created by companies, yes, but not all of them. But they're all open source regardless. And so, you know, the fact that we can build code so much faster, we can build more complicated apps faster than we used to be able to, even if it still feels like it's, you know, pulling teeth at times, there's so many options. We have improved so much because of open source. And companies benefit from this. And so, you know, I think it's really important for companies to give back. And the main way that companies can do this is supporting with time and money. And, you know, I know this sounds like, you know, companies should be altruistic, but it's not really the case. There's a symbiosis between companies and the open source community. And companies supporting open source ultimately helps them, too.

As a good example, I used to work at a startup called Observable. And we based our code editor on the open source project CodeMirror, which is a great project, by the way. Just a lot of great work from Ren, the lead maintainer, and everyone else who worked on it. And because we were using this as such a core part of our product, Observable actually ended up sponsoring the project. You know, donating money to it specifically so that, you know, all of the maintainers on the project could focus on it full-time. And by doing so, the project grew faster, it became more reliable, bug fixes, all of that that ended up helping us in return. We didn't have to hire someone to do it ourselves because we could, like, you know, enable the project to do it for us. It was a great symbiotic relationship between the two. I think all companies, at least if there's, like, open source was a really core part of what you do, if there's especially one or two projects that are at the heart of what you do, you know, think about how you can contribute. With the Node.js project, for example, companies can become members of the OpenJS Foundation, which oversees the project.

3. The Importance of Time and Collaboration

Short description:

Companies should give developers time to contribute back to open source projects they use. This strengthens the symbiotic relationship between companies and open source. It helps projects understand product usage and companies understand the open source world.

That's a great way to give back. But it's not just money. Money is important, but time is, too. You know, what I would love to see more of, this isn't very common, but what I would love to see more of is when companies give developers, you know, 5%, 10% out of the week to contribute back to open source projects that that company uses. This is another way to, you know, further enrich that symbiotic relationship between the two. Because, you know, whenever companies are giving back to open source projects, it helps, you know, the projects themselves have a better understanding of how products, or their projects are being used inside of products. But also the other way around is it helps companies to better understand the open source world and those open source projects. And being able to better plan around like how things move, how quickly or slowly things get released, fixed, and updated.

4. Reporting Bugs and Being Kind

Short description:

A role for us as developers is to report bugs in open source projects. However, when doing so, it's important to approach it with kindness and not take frustrations out on the maintainers. Many maintainers work on projects in their spare time or as part of their job, which is usually only part-time. We should be mindful of their limited resources and be considerate in our bug reports.

But, you know, a lot of us don't actually sit in a position of power such that we can make these decisions, you know. Where I see is oftentimes, you know, this is a little above our pay grade. But there's still a role for us, too. And that's that devs should report bugs. Whenever we encounter bugs in open source, which we all do, I have certainly found some. We should make sure that we're filing bugs for those projects, that we're letting them know, hey, we ran into this issue. But when we do so, we should do so with kindness. You know, I've also, like I said, I've been involved in open source. So, I've been on the other side of this. And unfortunately, one thing I noticed is that a lot of folks filing bugs feel kind of entitled, in a way, to immediate support. And I get where that comes from. Whenever we run into these bugs, you know, we're frustrated by it. And understandably so. These bugs are the things that's getting in the way of us, you know, shipping the features that we need to ship, especially when we're on a deadline. But we've got to make sure we aren't taking that out on the open source maintainers themselves. And unfortunately, I see that happen all too often. So, when we're reporting bugs, we need to remember that a lot of times these folks, they're doing it in their spare time. And even if they're doing it as part of their job, their actual paid job, it's still usually only part time. And, you know, these projects are typically under-resourced. So, we need to remember that and just be kind.

5. Developer Relations and Balancing Interests

Short description:

Developer relations, also known as DevRel, is a newer field that connects companies and the community. DevRel professionals attend conferences, give talks, and run workshops to help the community learn about the company's products. They also gather feedback from the community and facilitate communication between the community and the company. However, being a DevRel is challenging due to the need to balance the interests of both the company and the community. It's important for DevRels to be honest and transparent in their interactions with the community.

So, moving on. And now, I want to talk about developer relations. Now, you may not have heard of this before. This is a newer field. It's definitely much smaller. And it goes by a lot of names, too. It's also called developer evangelism, developer advocacy, technical evangelism. And, you know, these are just the titles I've had when I was working that job. There's even more of them out there. But it's a really important part in a big part of the community these days.

So, what DevRel does, which we call it DevRel for short, developer relations, is it connects companies and the community to each other. The idea is that when someone is working as a developer advocate, we're going out into the community. And this is attending conferences and giving talks, it's running workshops, it's all of these things to help the community learn more about the products that the company is offering. And usually, DevRel folks are attached to a specific product or a couple of products in the IOS area of expertise. And it's also what they're trying to get folks in the community to use. There's a bit of a sales aspect to it. I don't think that's actually a bad thing, though. I think sales oftentimes gets a bad rap. Who thought I'd be standing up for sales in this talk today? But that's only one part of what DevRel does.

So DevRel also takes feedback from the community back to the company. And so there's this two-way street between the community and the companies that DevRel facilitates. Well, at least in theory. Unfortunately, what I've seen in practice is not that. It's really hard to be DevRel and to really balance things such that the work that DevRel does helps both the company and the community. And there's a lot of pressure on DevRels and also a lot of incentives that aren't great. But this is where, as a DevRel, this is where we do have some influence. And this is where we have to make sure, when you're a DevRel out there, that you're being a good community member. And the first and most important thing to do is to be honest and transparent about what you're doing. So, if you're giving a talk at a conference, running a workshop, anything like that, be open and honest. Say, I'm a DevRel at this company.

6. The Role of DevRel and Feedback

Short description:

I'm here to talk about supporting products as a DevRel. It's important to be open, honest, and transparent. DevRel should not be exploitative. Some companies may try to leverage friendships to change detractors' minds. DevRel organizations heavily track public data but should push back when crossing a line. DevRel should ensure a two-way street for feedback, especially regarding products that may be detrimental to the community.

I'm supporting these products, and I'm here to talk to you about them today. This doesn't have to be a bad thing, but we have to be open, honest, and transparent about the work that DevRel is doing. And specifically, as part of that, is don't be exploitative.

And in a way, I can't believe I even have to say this, but in my experience, it has to be said. It's very easy in the position of DevRel, at least from a company incentive perspective, to try to go for the short-term gains for the company, and this often comes at the expense of the community. Back when I was working at DevRel at a certain company that I shall rename nameless, they tried to institute this program where they were looking at who were the biggest detractors of the products that we were working for that were out there in the community and had some amount of followers, notoriety, whatever it is. And then they looked to say, which one of us as DevRel were actually friends with these folks, and they wanted us to go leverage our friendship in order to get them to change their mind. And we weren't allowed to tell them we were doing that. And we were even supposed to track private conversations in all of this stuff without the knowledge or consent of the people involved. Of course, we threw a huge fit about that and we managed to get them to cancel the project, but this kind of stuff happens. And something just for the non-DevRel folks to be aware of is that most DevRel organizations, they are heavily tracking everything that people say online on Twitter, on GitHub and various other open source places. You're running sentiment analysis and things like that. This is all public data, so I suppose we shouldn't be too surprised. Pretty much any org that's at least a little bit salesy is doing this. But, you know, just something for everyone to kind of remember. And there will always be some of it.

As DevRel, it's important that you push back whenever things cross a line. And the last thing that I think is important for DevRel to do is to ensure that this two-way street is actually two-way. A lot of times, you know, it's of course very easy to get out into the community and to talk about what the company wants you to talk about, that that's what they hired you for. And that's, you know, very much— that makes the company happy to do that. But then there's that other piece of taking feedback from the community back to the company. And that's where I often see things falling down. This of course can be like bug reports and like the typical kinds of feedback, right? Hopefully DevRel has good channels for that. But where I see this fall down the most is at a higher level. And this isn't like, oh, this specific feature in this product is a little wonky. It's more of things like, this product you're selling isn't good for the community. It's encouraging bad practices, it's encouraging lock-in or any of these things. I think we all kind of know those products. Those ones that feel a little predatory, let's say. And what I've noticed and what typically happens, unfortunately, is that whenever that feedback is happening from the community to DevRel, DevRel will return it and it just falls in deaf ear.

7. The Role of Maintainers and Documentation

Short description:

So as DevRel, it's important that you do whatever you can to make sure that your employer is actually listening to that feedback. Maintainers make the web happen. Without maintainers, we don't have open source. And without open source, we don't have the modern web. Open source projects are more than just code. Documentation matters more than code. It is so important to the success of a project.

So as DevRel, it's important that you do whatever you can to make sure that your employer is actually listening to that feedback.

All right, so now on to project maintainers and collaborators of open source projects. And collaborators are an important part of this, but I'm mostly gonna focus on maintainers for this part of the talk. So maintainers make the web happen. Maintainers are so critically important that, you know, this sounds like a grandiose statement, but it is true. You know, without maintainers, we don't have open source. And without open source, we don't have the modern web. Simple as that. And I know this is kind of an obvious thing to say, right? You know, if there's no one to develop open source, there isn't any code. But I feel like we tend to take that for granted a lot. We, being companies, developers working there, we just kind of, open source is so common now. We almost can't imagine a world without it. So we don't think about what's often at stake. And so maintainers are just so, so critically important.

And so from the role of a maintainer, there's a couple of things that I think are really important for maintainers to do to make sure, on our end, that open source projects keep running. The first thing to remember is that open source projects are more than just code. Something I've always liked to say for a long time now is that you can write the best code in the world. It can be performant, it can be scalable, extensible. It can have an incredibly elegant API design. It can have all of those things. It could be the best thing out there. But if it's not documented, might as well not exist. Because the truth is like, documentation matters more than code. Which I know it can be kind of hard to hear. Most of us don't like writing documentation. I certainly don't like it. But it is so important to the success of a project. And you know, we need all kinds of documentation. You need to have those API guides that have, you know, the reference of like all the nitty-gritty of how it works. We also have to have the getting started guides, you know, the tutorials.

8. Importance of Documentation in Open Source

Short description:

We need change logs and upgrade guides for our open source projects. Without documentation, it's difficult for users to understand what changes have been made and what may have broken. Documentation is crucial for onboarding users and ensuring their satisfaction. The goal of open source is to share code and have others use it.

You know, we also need, you know, change logs and upgrade guides and things like that. And it's amazing how many open source projects I've come across that don't even have a change log. And so I see there's, you know, a major version upgrade. I have no idea what broke unless I go and read through the commits which sometimes I do, but sometimes I just give up and use another project or something else like that. So it's important that we have that documentation for our projects so that we can bring people into our projects and, you know, get them onboard and using our projects and being happy with them. You know, and at least hopefully, you know, that's the whole reason we even created this stuff as open source to begin with is to share our code with others so that other people will hopefully use it.

9. Importance of Inclusivity and Welcoming

Short description:

Being inclusive is crucial in open source projects. It goes beyond welcoming people of different genders and races. We should also consider inclusivity in terms of time zones. By accommodating different time zones, we can involve more people and benefit from their contributions. Inclusivity leads to more developers working on projects, which ultimately makes them more successful.

And the next thing is to be inclusive because it's really going to help you out if you can be inclusive and welcoming to new folks to your project. And I know this is kind of like a subject that's been talked about a lot. Some people may think too much, but I don't think it's fully really sunk in yet. Like inclusivity is so important, and I do mean inclusivity in the classic sense of like, are we welcoming to folks of different genders, people of different races and things like that? There's other parts that I feel like are even less talked about in open source that are just as important. And for example, how inclusive are we for time zones? For the kind of project where, say, once a week we all hop on a call, which, you know, this is pretty common. Let's say we're a North American centric project. What times are we holding those calls at? Are we making sure that we have times available for folks in Europe such that they're not having to hop on these calls in the middle of the night? Or what about folks in Asia where they have not hop in early, early in the morning? You know, it's important that we think about how can we bring in more people? Because at the end of the day, being more inclusive and welcoming means more people helping us with our projects, right? I've never seen a single project that I'm aware of that has too many developers. Too many developers and not enough work to do. It's always the opposite. There's always so much more work to be done than there are people to do the work. And when we focus on inclusivity in our project, it means we get more people to do the work, right? And that helps our projects out. It helps the projects be more successful.

10. Embracing Change in Project Development

Short description:

Embrace change as the best way to run a project evolves over time. Initially, it's just us coding on our own laptop, committing straight to main, and publishing to NPM whenever we want. But as we bring on more contributors, we need to establish a pull request process, document it, and delegate decision making. Adapting the project as it grows is crucial to prevent it from becoming unmaintained.

And the next thing I want to recommend is to embrace change. Like, the best way to run a project changes over time. When we start off with that project, it's usually just us. We're coding on our own laptop. We're committing straight to main and pushing up. You know, we just publish to NPM whenever we feel like it. And that's great in the early days. It allows us to move fast. But as we start to bring on more contributors, that becomes less true. You know, then we have to start thinking of, like, well, what's our pull request process and things like that, you know, making sure that's documented. And then as that continues to grow, then we have to start thinking of, well, how do we delegate decision making? Do we have to start thinking of coming up with something like, you know, the big projects have, which is, you know, usually a technical steering committee, and then a bunch of working groups below that. You know, the way that we approach work and who we bring in to become collaborators and what that process looks like needs to change over time. And if we're not adapting our project as it grows, then that's a pretty good way to make sure that it's going to become unmaintained later because it, you know, collapses under its own weight. You know, sadly, there's some really big projects I've seen that have done this, some that are sometimes even some of the most popular open source projects, you know, in their area.

11. Supporting Ourselves and the Community

Short description:

The incentives in open source software are inhumane. We contribute a lot, but companies make all the money. Open source maintainers and DevRel professionals are burned out. We need to work on fixing things and supporting the community better. It's important to recognize the signs of burnout and understand ourselves to contribute effectively. Sometimes we need to delegate work or bring in other maintainers. DevRel professionals may need to change teams or companies.

And so I kind of want to end this talk by refocusing a little bit on like what we owe to ourselves. How do we support ourselves in this process? Because, you know, the unfortunate truth is that right now the incentives in open source software are inhumane. It's bizarre to think of, you know, we spent all this time, you know, contributing and, you know, just to turn out and see our projects being, you know, used by companies who make all this money when, you know, especially for folks who are doing open source full time, you know, can be really struggling just to make ends meet. And you know, again, like I was talking about with filing bug reports, there's a lot of vitriol. There's a lot of angry people. You know, it's kind of those things where, you know, the unfortunate reality of open source is if we do the absolute best job we can, no one will notice. People only notice whenever we make mistakes. And since we're humans, we do make mistakes. And it's hard and brutal. You know, everyone is overworked. So many open source maintainers I know are burned out. Just things are not OK in the open source world. You know, it pains me to say but it's true. Like we really need to work on fixing things. We need to work on supporting this community better. And, you know, and it isn't even just with, you know, open source maintainers who are struggling. It's dev rel too. You know, like I was talking about, it is really hard to be an ethical dev rel these days. Like things need to change. But, like, so what can we do about that? Well, you know, the answer has in a way been around for thousands of years. You know, the classic saying of know thyself. You know, I mentioned so many maintainers and dev rel folks I know are just burned out. You know, they're done. And I think one of the things I've noticed is so many of them don't even really know they're burned out. So I think one of the things that's really important for all of us to learn is to recognize, you know, the signs of burnout or to learn and recognize when we're doing work that isn't sustainable for us or doing work that ultimately doesn't bring us fulfillment. And so it's all about understanding ourselves because only once we understand ourselves can we start to think about how we can contribute better and how we can actually, you know, become more sustainable and more effective and help the community as a whole. You know, sometimes it means we have to rethink how we stay involved. You know, maybe we need to start delegating some work to other folks. Maybe we need to, if we're open source maintainers, really start prioritizing bringing in other maintainers at the expense of doing new features. Sometimes in DevRel, maybe it means we need to change teams or change companies to continue to do it.

12. Leaving DevRel and Finding Hope

Short description:

I left DevRel several years ago because I couldn't balance my work at the company and be an ethical member of the community. I've mostly left open source as well, except for personal projects. Burnout makes it harder to be kind as maintainers or push back as DevRel. However, I'm hopeful because I see more discussions about burnout and ethical practices. By supporting and helping each other, we can create a better community for everyone, including companies.

But you know, at the same time, sometimes the best thing is just to leave because the truth is I left DevRel several years ago and I'm never going back. I was actually at another conference, one that was really important to me and I had this light bulb moment where I realized there was no possible way for me to do the work at the company I was working for and be an ethical member of the community. I was always having to fight against the two. And so the best thing for me was to leave.

I've mostly left open source as well. I still do some personal projects, but I left an OJS project. I'm not involved in the day-to-day at all. In any form or fashion in that project anymore. I certainly still stay in touch with folks. I love talking to them, but I'm not involved anymore. And that was the right decision for me. That was such an important growth area for me and I'm a lot happier and healthier now because of it. But that sucks. But open source should be a part of our life and not all of it. It's all how do we find that healthy balance? Because if we're burned out, if we're barely hanging on, we're not doing anyone any favors, including our projects. If we're burned out, that makes it so much harder for us as maintainers to be kind and gracious in bug reports. If we're burned out as DevRel, it's that much harder to make sure that we're doing the right thing and pushing back against our employers when we need to be.

But for all of this negativity, I'm ultimately still hopeful. I am starting to see signs of this changing. I'm seeing burnout being talked a lot more with open source maintainers. I'm starting to see more talk about with DevRel and how do we do that ethically? And the reason I am seeing this happen is because we're talking more with each other. You know, we're starting to support each other more and help each other out, and I think that's the way out. So I want to end with a quote from the good place again by Thierry Hennigan, who said, why should we choose to be good? It's because of our bonds with other people and our innate desire to treat them with dignity. Simply put, we are not in this alone. I think that's the key. When we remember that we are a community together, if we can help each other out, that is how we get our community into a better and happier and healthier place overall. And it helping everyone out, you know, including companies.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2022React Advanced Conference 2022
16 min
How to Build Your Own Open Source Project
We all used open source projects every day such as npm packages, editors, web applications, and even operating systems... Have you ever thought of building one of your own? In this talk, I will share my journey building jest-preview, from when it was just a vague idea, to currently a well-adopted library to help frontend engineers write tests faster. I will share with you how to come up with an idea for a project to work on, what is the struggles you have to overcome as an author of an open source project, how to manage time efficiently, and how you get attention from engineers around the world.
Vue.js London 2023Vue.js London 2023
11 min
The Hidden Cost of Open Source
There is a cost that many companies don’t consider when using open source. It can cost a lot of money and time to keep upgrading sunsetted versions.Open source is free for companies to use until the author sunsets a version.These are some best practices that we we recommend when considering open source adoption:        - Who is the author? Do they have a strong reputation that is going to be around for a long time? Do they have the resources to support an enterprise library?        - How much online support is there in the community for this library? How many dependencies are on this library?        - Does it have an end of life policy? What’s going to happen when they rev on a version? Will companies have an option to stay on older versions for a long time?        - What should you consider when migrating to a supported framework after a version has been sunsetted?
TypeScript Congress 2022TypeScript Congress 2022
30 min
Lessons from Maintaining TypeScript Libraries
Maintaining widely-used JS libraries is already complicated, and TypeScript adds an additional set of challenges.

Join Redux maintainer Mark Erikson for a look at some of the unique problems TS library maintainers face, and how the Redux team has handled those problems. We'll cover:

- Tradeoffs of different ways to define TS types for a library
- How to target different versions of TS, and considerations for determining the supported version range
- Migrating existing JS libraries to TS
- Differences between writing "app" types and "library" types
- Managing and versioning public types APIs
- Tips and tricks used by types from the Redux libraries
- TS limitations and possible language-level improvements
Vue.js London 2023Vue.js London 2023
24 min
Patterns for Large Scale Vue.js Applications
What is the best way to structure a Vue.js application so that it can scale to meet all your users' needs? There are multiple patterns established by the Vue community and the programming community at large that can be adopted in order to make your codebases more predictable, maintainable, and extendable.
Vue.js London 2023Vue.js London 2023
31 min
Nuxt 3 Modules and Open-Source
Nuxt modules are the de-facto way of extending our Nuxt applications with new behaviors and functionalities. Have you ever built your own? Why would you bother with hundreds of modules already out there? Let's answer those questions together and see why making your own modules in Nuxt 3 can both help you have a deeper understanding of how Nuxt works while also paving the way for you to get into open source!
React Day Berlin 2022React Day Berlin 2022
8 min
Making an Open Source Library Financially Sustainable
React Flow is an open source library used by thousands of developers and hundreds of companies. How do we make sure it stays alive, and also free? I’ll share some insights along our journey from open sourcing React Flow to passing the “black zero,” including findings from our user research where we spoke to some of the people who support us every month.

Workshops on related topic

Node Congress 2023Node Congress 2023
85 min
Node.js: Landing your first Open Source contribution & how the Node.js project works
Workshop
This workshop aims to give you an introductory module on the general aspects of Open Source. Follow Claudio Wunder from the OpenJS Foundation to guide you on how the governance model of Node.js work, how high-level decisions are made, and how to land your very first contribution. At the end of the workshop, you'll have a general understanding of all the kinds of work that the Node.js project does (From Bug triage to deciding the Next-10 years of Node.js) and how you can be part of the bigger picture of the JavaScript ecosystem.

The following technologies and soft skills might be needed):
  - Basic understanding of Git & GitHub interface
  - Professional/Intermediate English knowledge for communication and for allowing you to contribute to the Node.js org (As all contributions require communication within GitHub Issues/PRs)
  - The workshop requires you to have a computer (Otherwise, it becomes difficult to collaborate, but tablets are also OK) with an IDE setup, and we recommend VS Code and we recommend the GitHub Pull Requests & Issues Extension for collaborating with Issues and Pull Requests straight from the IDE.

The following themes will be covered during the workshop:
- A recap of some of GitHub UI features, such as GitHub projects and GitHub Issues
- We will cover the basics of Open Source and go through Open Source Guide
- We will recap Markdown
- We will cover Open Source governance and how the Node.js project works and talk about the OpenJS Foundation
  - Including all the ways one might contribute to the Node.js project and how their contributions can be valued
- During this Workshop, we will cover Issues from the nodejs/nodejs.dev as most of them are entry-level and do not require C++ or deep technical knowledge of Node.js.
  - Having that said, we still recommend enthusiast attendees that want to challenge themselves to "Good First Issues" from the nodejs/node (core repository) if they wish.
  - We're going to allow each attendee to choose an issue or to sit together with other attendees and tackle issues together with Pair Programming through VS Code Live Share feature
    - We can also do Zoom breakrooms for people that want to collaborate together
  - Claudio will be there to give support to all attendees and, of course, answer any questions regarding Issues and technical challenges they might face
  - The technologies used within nodejs/nodejs.dev are React/JSX, Markdown, MDX and Gatsby. (No need any knowledge of Gatsby, as most of the issues are platform agnostic)
- By the end of the Workshop, we'll collect all (make a list) the contributors who successfully opened a Pull Request (even if it's a draft) and recognise their participation on Social media.