Thank you!! It wouldn't have been possible without your enthusiasm and encouragement!
I think a lot of people are interested in making cool things but bridging the gap between looking at the project from the outside and actually doing something can be scary, especially for people who are contributing to open-source projects for the first time. For people who are extremely new, it helps a lot to either have direct guidance from someone with experience ("synchronous" due to timely feedback) and/or reading/video educational material ("async" due to something that can be created once and used multiple times after its creation). With regards to Pion, I was lucky to have both kinds: constant feedback from Jo, plenty of material to read via https://webrtcforthecurious.com/ , RFCs, the countless issues in SCTP; it felt a little bit like I stumbled into a lab with all the tools at my disposal and all I had to do was put the pieces together, come up with a plan, and go for it.
Also the https://github.com/pion/webrtc/wiki/Projects-Worth-Doing wiki page was very helpful but this could also be something that we can improve on: having a better understanding of what we want to get done and when we want them to get done (roughly speaking) is good. Updating it can be a bit of a chore though so I wish there could be a more efficient way to keep track of things while getting things done. I didn't struggle with it as much myself but that was mostly because Jo and I were working together nonstop for the last few months, but I can see how it could potentially be confusing for newer folks. It would also be good to mark which issues/features are blocked by others, which is something that I added in SCTP's readme, which has been nice. One thing I wonder about is whether the older parts of the codebase are daunting, but our efforts to put together resources regarding what RFCs are relevant has been great. I wonder if the video streaming world could have some sort of public tracker for different tools/technologies for people to learn about. I feel like that might be the biggest bottleneck for us, especially compared to other specialized software fields.
As for technical things, there are definitely a couple: learning that Windows' networking doesn't play as nicely as Linux's has been a bit of a nightmare, I'm surprised it even works at all haha. Another is how little attention RACK has received; the dissertation (https://duepublico2.uni-due.de/servlets/MCRFileNodeServlet/d...) doesn't seem to have garnered much attention despite having a really big impact. I also think that it's really surprising to be able to sit down and deal with packets and remember that everything is just a bunch of packets and the way we keep track of things we've sent or received is entirely governed by whatever rules we come up with. It feels oddly primitive but very valuable to be able to learn about why and how we want to track whatever heuristics we come up with!
I'm happy to hear that you were encouraged by my story :) It can definitely be scary to begin with contributing to open source projects but I would recommend trying to find a place to start that 1) has an active community with people you can actively talk to and 2) find a project that you find interesting enough to care about.
An active community is really important: just a year ago Pion had very little activity until Jo picked it up as a maintainer and was an incredible person to talk to, including countless questions about almost everything. I'm really not exaggerating, I was able to do this with almost 0 prior knowledge on Go and video streaming. Part of working with open-source is luck based though; not all projects make it, and people are working on things in their free time. I would try to see how active people are and also how nice they are, because if the maintainers are toxic then realistically speaking, you probably wont be working on the project for a long time even if you found it interesting.
Honestly my strategy sounds really simple, it's basically saying "just do x", which is half of it. My mentality going into it was to try something. If I didn't like it, I would just drop it and move on, but if I did like it (for example, finding a project interesting enough to help out with, or a fun group of people to work with, or just a place to help with small things outside of work) then I would tag along for the ride. Another way to look at it is that by contributing, even just a little bit, you don't have to be responsible for an entire project. Being able to make tiny changes can still be meaningful because it forces you to have to understand the other parts of the codebase, as well as why the changes are necessary in the first place. And if you're ever unsure about either of those, that's where the community part comes in: asking questions is key!
It's important to remember that most open-source projects are just things that people work on in their free time. While it is fun, sometimes people get busy, which is why it's nice to have multiple projects to contribute to. It also gives you a chance to meet new people, that can be from joining whatever chat they're using (like discord), making posts like these to show off things that you've made, requesting reviews from maintainers, etc.
Luckily for me, Pion ended up being a place where I found something to do and was given the time and tools to make something cool!
I think a lot of people are interested in making cool things but bridging the gap between looking at the project from the outside and actually doing something can be scary, especially for people who are contributing to open-source projects for the first time. For people who are extremely new, it helps a lot to either have direct guidance from someone with experience ("synchronous" due to timely feedback) and/or reading/video educational material ("async" due to something that can be created once and used multiple times after its creation). With regards to Pion, I was lucky to have both kinds: constant feedback from Jo, plenty of material to read via https://webrtcforthecurious.com/ , RFCs, the countless issues in SCTP; it felt a little bit like I stumbled into a lab with all the tools at my disposal and all I had to do was put the pieces together, come up with a plan, and go for it.
Also the https://github.com/pion/webrtc/wiki/Projects-Worth-Doing wiki page was very helpful but this could also be something that we can improve on: having a better understanding of what we want to get done and when we want them to get done (roughly speaking) is good. Updating it can be a bit of a chore though so I wish there could be a more efficient way to keep track of things while getting things done. I didn't struggle with it as much myself but that was mostly because Jo and I were working together nonstop for the last few months, but I can see how it could potentially be confusing for newer folks. It would also be good to mark which issues/features are blocked by others, which is something that I added in SCTP's readme, which has been nice. One thing I wonder about is whether the older parts of the codebase are daunting, but our efforts to put together resources regarding what RFCs are relevant has been great. I wonder if the video streaming world could have some sort of public tracker for different tools/technologies for people to learn about. I feel like that might be the biggest bottleneck for us, especially compared to other specialized software fields.
As for technical things, there are definitely a couple: learning that Windows' networking doesn't play as nicely as Linux's has been a bit of a nightmare, I'm surprised it even works at all haha. Another is how little attention RACK has received; the dissertation (https://duepublico2.uni-due.de/servlets/MCRFileNodeServlet/d...) doesn't seem to have garnered much attention despite having a really big impact. I also think that it's really surprising to be able to sit down and deal with packets and remember that everything is just a bunch of packets and the way we keep track of things we've sent or received is entirely governed by whatever rules we come up with. It feels oddly primitive but very valuable to be able to learn about why and how we want to track whatever heuristics we come up with!