 All right. Thanks, Tristan. Well, welcome, everybody. We have a topic that hopefully raises a lot of discussion. I promise you no death by PowerPoint. There's only about a dozen or so slides on here. And I've left plenty of time in for Q&A. Both at the end, but also feel free to interrupt as I go. I think it works better if we get to the questions live as they are in context. There is zero danger of me running out of time on the slide, so don't feel any need to hold back on that account. This is not intended to run you guys over with content. So the topic is, how do I get started? And this is something that, you know, we obviously hear a lot that the next foundation I use the analogy to Rapunzel's Tower. You can kind of see where you want to get, but it's not clear where the door is. And some of that has to do with the nature of tech in general, the nature of software in general, and some of it with the nature of open source. So we talk about some of those things and what some of the strategies and tactics are to address them. All right, let's jump in just a little bit on the agenda. Topics I want to cover. My name is Clyde, Chief of the head of the training and certification group at the next foundation. And our mission ties in very well to the topic today, which is providing training for folks coming into projects or a lot of entry level skill building awareness. I have a ton of free courses. I'm just trying to ensure that there are ample ways for people to discover the entry ways into open source I've been doing education of one sort or another for about a dozen years now. Open source has definitely been a an interesting change of somebody who came into it from outside. So I had my newbie hat on when I joined LF a little over six years ago. So I definitely there's a little bit of personal experience being brought to bear on on what it's like to onboard into that open source community. I will talk about some of the resources and the strategies and tactics but I want to spend the next few minutes, just on some context setting. So I think one of the things that, you know, is tricky about a session like this is you're never going to be able to cover sort of every eventuality. And every tool or tactic that somebody might might want to use, but it is helpful to kind of step back and think about the context of trying to enter community. And so we spent some time on that. And then we talked through, you know, the resources and some do's and don'ts and then hopefully plenty of time at the end for Q&A. So with that, let us jump in. So there's a series here on thinking about kind of what's unique about so when you're thinking about jumping into an open source project. What is the context in which you're getting yourself, you're trying to enter. I think that's really helpful if you think about and make sense of the experience that you have as you come in. And I want to do this in layers and try to create some structure to how to think about it. And so there's a couple of slides, this and the next couple that kind of progressively drill down into more specifics. So this first one is about, you know, what's unique about the tech industry in general, and this, you know, obviously would be more relevant to those of you who maybe are coming at this session from outside of tech and interested in getting more involved. And so a few points to highlight, this is not meant to be an exhaustive list, but as I was preparing for the session, I thought, okay, what are the most interesting components that might strike folks as different. And I'm going to remind folks to just hop on mute and unless you're asking a question. So first off, it's this idea that it's an orchestra, you're not a soloist. And of course, what I mean by that is, in tech in particular, there's no such thing and certainly no such thing anymore as kind of a lonely genius right everything you do interacts with people systems processes. And into, you know, I tell people that you know when I came into LS, I still had this sort of mental image of, you know, sort of the coder in her basement kind of doing her thing kind of oblivious to the world. And then I realized that that might be true while you're writing code, but it's actually not true. Once you start to put that code out there to the world and interact with all the other systems and processes. So there's definitely a component of of interconnectivity in the people side on the tech side on the tooling side that, you know, I think when you're on the outside looking in, maybe isn't as clear. This next point to the concept stolen from Alice in Wonderland, and this idea of the Red Queen effective that, you know, the Red Queen has a line where she says, you know, it feels like I have to keep running faster to stay in the same place. And what that speaks to is this whole idea of sort of the acceleration in tech. So you obviously don't even have to be in tech to realize that this is happening right just think back to, you know, how recently some of the big tech companies I saw this morning in a Slack consult of $27 billion that didn't exist six years ago. Things move fast. And, and there will be something that we come back to a few times in the course of this discussion this idea of things move fast and accelerate because it speaks to what's required of you in terms of mindset to be thinking of yourself as on a lifelong journey of skill building. And then you will never get to a point where you where you can say okay I know everything I need to know now I just need to only focus on execution. There's just always going to be more new technologies interesting concepts and it's important to recognize that as sort of an existing pre existing condition if you will. It's global in nature. Right. And this is true for a lot of other sectors. It's not unique and these are to tech but I can't think of a single project or for that matter single company that is exclusively operating in one jurisdiction. And so now you're talking about time zone differences, you know, native language differences. You know, cultural differences. And this is back to this idea of the connectivity right that you are entering a, an environment that is complex and fast moving and interactive and collaborative. So even when you're developing code on an open source project, it's a it is a fundamentally collaborative exercise where you're submitting those requests having people review them putting them back in where you're looking at other people's code right and trying to understand how different parts of software work. And then you're going to have questions. So it is a collaborative process. And, and this final point is something that has really become more and more prominent here in the past couple of years of what people care about. And in tech in particular is the results you can deliver more so than what I call pedigree which is you know do you have a degree or not where did you go to school. One of the really great things about tech and software in particular is, you know, if you do great work. It's obvious the people that you've done great work they can, they can see your work product and that's what they value, but it also means that contrary to I think what maybe some sort of popular wisdom is. If you've got an aptitude for the sector and you come in you start finding that you enjoy doing code and you enjoy solving these types of problems. Nobody standing around asking whether you have a degree, nobody standing around asking you know what sort of apprenticeships you did. It is really true that there is a disproportionate amount of focus on show me what you can do. And I think that's really liberating when you're thinking about entering one of these communities to know that, you know, in that sense it is very much of a meritocracy. Alright, so that's tech sort of super high level. If we drop down kind of one more level to what about the software component right so yeah you know hardware networking software there's always different components. When you get the software layer is picks up on the point I was making before of, you know, your code is your resume. Where you build your brand your personal brand your reputation is by the work you do when people can see the work you do, especially when you get into the open source which is the next slide and the code is available through GitHub or get lab. And again, that can be really refreshing because you're judged on what your output looks like. And, and that's, you know, often not true if you're in the traditional type work environment where a lot of the other factors get get get brought to play. And they, you know, your code ready in some sense speaks for itself and that can be a really liberating pleasant experience. Now the flip side of that, and this term switch grid is from my old economics days, a search grid is simply one way you can tell ahead of time. Exactly what it is you're buying. And so there's some different concepts is like things called experience goods which you kind of think you know but you don't really understand what you got until after you bought it and there's other goods that you never really know, like lawyer services until after you even after you experience it's just really not sure how great it was. The code is a search grid, right. The code does what it does. The lines of code are visible people can can be bug it they can review it they can comment on how elegantly it does what it's supposed to do. They, but you know, it is by definition, you know, a deterministic process when you write code so when you put code out there. People are able to evaluate it and decide sort of doesn't do what it was supposed to do. And again that can be that can be quite a positive thing if you're writing great code because people are able to assess what assess it sort of on its own merits. You know, I visited this idea of dependencies, you know we talked about collaboration on the prior slide but there are a ton of software dependencies and the reason I wanted to raise it here is that not just dependencies when you're thinking about your your code base and how you're kind of working with it. It's also the fact that no software exists in a vacuum. I know in our case and the foundation training we have periodically we have examples where something stops working and we sort of scratch your head and feel nothing different than yesterday and it worked yesterday so how could it have stopped and not it's something like, you know, a package that got deprecated or removed, right, the reality of software today is it's all interconnected and it's built on top of multiple other packages and, you know, it's interesting for us at the Linux foundation just how true that is because the network itself is now tied into and packaged into so many different computing systems. And so I think, you know, that idea that that, you know, your piece of code can be great and can be elegant and can still end up not getting done what you need to get done because code built and so it is important to kind of remember that the code does not exist in a vacuum. The fellow point originally I was using this term called yak shaving is exploding school. So you, you, this is true particularly in software where you have a clear task and you think okay, I'm going to do this I'm going to try to accomplish, you know, X type of output. And you realize that you want to get X done you need to get a done but before you can do a to have C in place and before you have C in place you need to, you know, figure out how to get B into your data tables. And before you know it you're shaving a yak in Siberia. It is a classic and it can be frustrating to people when they're new into software this idea that the scope you thought you had, you know, clearly articulated early on, just kind of keeps exponentially growing. But again, because of the dependencies and this the nature of the collaboration. It is often true that you do have these sort of exploding scopes and you need to stay patient with it right because it's not a sign of a defect in how you're approaching the work it's simply a sign of the world is complicated and sometimes things that you assumed are going to be there aren't there or you have to build a service you have to build a connector. The scope just explodes. It's the sort of the nature of reality and it's something that you're going to have to get comfortable with as you work in software. And then I do want to revisit this point about lifelong learners. It's really, I think this is probably true in a lot of other industries as well but it's particularly true in tech and within that particularly true in software that your skill set just has to keep evolving. And, you know, new web languages come out new frameworks came come out new popular, you know, computing languages get popular. Sometimes they go back and get re popular. So, you know, I remember a time when C++ was sort of a, you know, people thought it was kind of a dinosaur language and now C++ is very much back. But I think the implication if you're thinking about a career in code is that you have to have this mindset of lifelong living that there's just, you know, maybe not daily maybe not weekly but I can guarantee you quarterly and annually you're going to have to add new, you know, weapons to your arsenal in order to stay effective. And, and you need to be mindful that just sort of the state of play and you have to be kind of get yourself mentally ready for this idea that you're on a journey right you're just constantly going to be learning adaptive and having to enjoy that challenge of figuring out how you add more pieces to your skill set in order to ultimately be successful. I'm going to stop for a minute and just see if anybody has questions because this is a pretty long monologue so far. I'll just say again don't be afraid to interrupt you free to jump in at any time I'm going to move on and talk about so we talked about tech we talked about software and we just kind of come down the funnel to our final destination and in addition to right so what's true of tech is also true of software what's true of tech and software is also true of open source, but there are some unique components open source to be mindful of the first is just the volunteer nature of it. All right, people get passionate about projects and start experimenting with them and eventually start issuing pull requests on them for as many reasons as you care to count, but what's fundamentally true in all of them is that they are doing it out of passion for the project we're all volunteers in that they could be doing other things and the whole structure right the whole review structure and maintain a structure that you see in open source projects where pull requests get pulled in at the bottom and then you have these peer review processes and you have these maintainers that look at what's coming up the chain and maintain I will approve something to go in and then it's kind of fooled its way up the chain it you know it looks very hierarchical and that sense it looks like a what you would call think of in a traditional sort of organizational structure, but the key difference is that these people are being driven by passion they are volunteers it is a volunteer and so when you see a lot of passion and sometimes that passion can come across as enthusiasm and energy sometimes that passion can come across as people being brusque I think it's useful to remember that people are in this they're bringing a lot of passion to the game and sometimes that comes off the energizing experience sometimes that can be a little bit off putting but generally speaking it's not intended to be personal so good to remember just slide this is Kristen just wanted to let you know you have two questions in the Q&A box all right let me have a look here oh sorry Harry I'm looking at your question here I think it was posted a while back oh okay I'm just going to try and answer it Harry you want to maybe give me a little more context I want you to conform the question about galore and then the other question is how to select a project to work on I'm going to come to that the short answer is find the thing that you're really the most passionate about you know I think a lot of times people try to think about you know which project is going to be the biggest or which one has the most adoption or which one seems the sexiest and the real answer is in my perspective and you know I'll ask Shua to jump in as well Shua Khan who is a fellow here in the next foundation who's been doing a ton of mentoring I tell people go find out what your passion is about and start there absolutely Clyde that's the right answer because sometimes you know you want to jump into a project where you feel like you can contribute or you learn as well looking it back to what continuous learning and lifelong learning you want to pick a project that you're passionate about want to contribute and also want to learn about the project so I would say picking the project you're passionate about keeps you in the project longer as opposed to something that you are not interested in yeah, thanks Shua I want to move on and I'm sorry on the chat Harry if you could not fully understand your question about what you asked me to elaborate on so I'll keep an eye on the chat here if you want to clarify a little bit this next point is something that was interesting it was something that I didn't know and appreciate when I came into open source is this idea that you'll get handled right so I'm making the assumption here that everybody knows what I get handled as maybe I should back up so there's most software, certainly most open source software software currently gets hosted on public repositories so GitHub, GitLab, there's a couple others and the way that you contribute code is via a profile so you have a profile and you have a handle which is basically a username in most cases you have an avatar and that's what people know you as right so if you go in there with a handle of you know applied one two three that's your get handle people are going to talk about Clyde one two three's request and remember that this is happening mostly at a distance right and so people are collaborating in these repos and you may eventually connect with these folks in real life or electronically or at a conference or a meetup but there's going to be a period of time where you mostly know each other and you yourself are mostly going to be known by that get handle and I find that is you know for folks who are coming in, especially if they're coming in to tech from maybe a background where it's not sort of what you would old school think of as traditional with a comp side agree it can be quite liberating because you know they're you know they're seeing a get handle with no context around where you're from what your gender is what your age is and all they see is your code and what you're pulling in and that is a really powerful way to get introduced into the into a new community and the analogy I give folks is you know a lot of orchestras in the US and globally had issues with diversity and many of them have switched to what's called blind auditions and the only difference on the old edition is they put a screen up so the musician walks on stage and plays but the panel evaluating them doesn't actually see them so the only experience they have of you is your output in that case in the orchestras case it's it's it's the music that you play and what they found was that when they started doing those blind auditions they started getting a more interesting diverse mix of people accepted in to the seats because a lot of biases that get applied when you're you know when you're seeing the person don't get that don't get applied when all you see of them is their work and a similar thing is true in open source right they see your handle they see your work they're evaluating you based on on what you're putting forward and when I hop back to the Q&A for a second here so in what sense there are dependencies so yeah I don't mean dependencies in terms of your participation the question I think I think everybody can see the Q&A panel if you want to play along at home it says I meant to ask in what sense there are interdependencies in participation to an open source project yeah it's not so much dependencies on you as an individual Harry it's the dependencies in the code that you know the piece of the code base that's talking to the database or the piece of the code base that's talking to the networking infrastructure the if you've been around tech for at all for the past few years the Hartley bug with the open SSL security layer is a great example of a dependency that was hiding in plain sight and basically the whole internet based on top of it and then one day it turns out there was a bug so there are dependencies in the sense of the code base I'm just looking at the chat here question about can you give us some pointers on how we can participate on the Linux kernel project and the subsystems you can contribute to I think this kind of hops back to the earlier discussion we had that you know find the piece that you're most interested in and passionate about and if you're not sure yet what that might be you know go have a look at the different you know sort of components of the software and how you know the different kind of maintenance areas and see which one you think is most interesting or we know which subsystem kind of speaks to you that maybe seems familiar or intriguing I don't know that there is a good roadmap on a cheat sheet on finding sort of the best fit for you I think doing a little bit of research on how the code base is structured and I'll make this point in one of the following slides as well right that you know don't be afraid to start small now just pick one piece of it pick you know fix a bug you know I think one of the things that folks sometimes feel like you know you got to make your name early on by sort of putting out sort of a great new feature and it's just not the case you know if you even fixing a small bug right the reason the small bug exists is that nobody who came before you found it and fixed it and so every contribution you make is a unique and valuable contribution so I talked about the good handle I talked about this next point is a phrase I've seen around in some of the literature and it's actually the literature on how basically answering the question why are people mean on the Internet and in the case of open source some of those same lessons are true because most of your interaction is happening through a get help through a get lab at least early on hopefully you start to get as you get more embedded and you take advantage of some of the opportunities to get to know people that starts being less and less true but what this associative anonymity just simply means that people are tend to be meaner to people when they have not met them and especially if they have no prospect of meeting them and so it's just this idea that it's not universally true but there are there are going to be times if you're in open source long enough where this tendency of people to react much more strongly and sometimes it can be react strongly positively sometimes it can be react strongly negatively but all of you I'm sure have been on the Internet right so this is not a unique phenomenon to open source but it is true of the broader sense of human dynamics in systems where you don't necessarily have personal relationships or even awareness right of the people that you that you're working alongside to just be mindful of that that's you know that's more of a comment on sort of human nature I'm just looking at the Q&A any recommendation on quality control on code contribution from volunteers all open source projects have inbuilt quality control in that they have review hierarchy so patch requests get reviewed they get accepted they get sent up chain to a maintainer and so you know there's a built-in meritocracy of review I might pull Shua in again sorry Shua but I know you're on to speak to sort of the Linux piece of this but you know code gets submitted as you know I think of it almost like a submission to a publishing house right you're proposing a piece of code and then that gets reviewed and maybe Shua if I ask you to talk about that a little bit and talk about how you can check your own code before you put it in as a pull request absolutely the Linux kernel development happens on mailing lists and we have several mailing lists with each one of the subsystems so the general advice I give people is that if you are new and you want to get started pick a subsystem that you're interested in and then watch those mailing lists and see how the dynamics between people, maintainers and developers, contributors and everything and if you do have a patch you send a patch each change is a small change so you will send up a patch, send to the mailing list and we also have a maintainers page that lists all of the maintainers who do you send the patch to right that's the question once you have the patch ready you test it and who do you send it so the kernel repository has get maintainers script that will tell you exactly who the patch should be sent to and you send the patch and you address any reviews that come up is that kind of answer you're looking for Clyde for this question? I think the question really is about quality control right so there's a quality control built into that patch review process but any tips for individuals before they submit their patch their own personal quality control maybe before they submit correct so yes that is part of testing the patch itself and also making sure that the patch itself passes all the compliance, code compliance and there are several scripts in the kernel that can do that for you in addition to the testing you're doing obviously because if you are fixing a bug you're making sure the bug is actually fixed and that you're not introducing any problems cool interesting question just in the Q&A box from Pascal and it is I have done some contributions on some open source projects and I would like to continue but I sometimes hesitate to work on an issue because I'm afraid I won't find time to complete it any piece of advice on how to tackle the situation you know that's a good question Pascal sometimes life gets in the way that is true what I encourage folks to do is remember that just because you're working on an issue it doesn't mean that you've taken sole possession of it right multiple people can choose to work on an issue in parallel and so if you start working on something in the open source context and you don't finish it you're not you know the community is not any loose off right the community benefits if you finish the work and submit it but you know the fact that you're working on something doesn't mean that somebody else has chosen not to work on it so I would definitely encourage you to if you find something you're interested in work on it right and if you can get it you know ideally you get it done you know within the time frames that you like sometimes it might take a little bit longer sometimes it might be true that before you're done working on it somebody else comes in with a solution that gets accepted that maybe takes in a different direction and that will be an interesting learning experience for you but because of the distributed nature of the code base you shouldn't be worried about taking on something and not necessarily being able to finish it because the project won't you know by definition these projects don't stop to wait on individuals finishing work so the distributed nature of open source in that sense does make it a lot more creates a lot more windows of opportunity than it would be in a traditional sort of proprietary software mode where that's your module and you really are being counted on to get it to get it fully developed that's another question here what scope is there for contribution by non-programmers is the pool of projects available such contributions smaller than for coding contributions that's a good question we've been talking about this in terms primarily so far of the programmer aspect of it and not everybody is a programmer or interested in programming in fact I would say that you know from the if you look at the Linux Foundation training catalog that my team works on a lot of the training is actually for users and so you don't have to be a programmer to participate and contribute right when you're looking at you know when you start deploying a piece of software you start tying it into other pieces of software you will start seeing things you start seeing potential bugs that you can report and so you don't have to be a developer to report a bug anybody can report a bug in fact that's how a lot of bugs get found or you can suggest enhancement that you want to suggest right that maybe it's not you maybe it's somebody on your team or somebody in your circle that you want to suggest an enhancement to or if you want to get plugged into some of the mailing lists you know identifying bugs suggesting enhancements figuring out new and interesting ways to use these projects so for any of you who followed the container revolution in operating systems and cloud computing you know what Docker which is really the first container company to popularize use of containers that was built on a foundational concept in the Linux kernel that was there keep me on assure you know I think at the end of the end we're there from the beginning and it's just that the Docker team realized hey if I take this I can actually make one machine behave like many machines so I guess the short answer to the question is you don't you don't have to be a code developer to participate you can you can find bugs you can find enhancements you can find interesting ways to use features that maybe the developers haven't necessarily thought of at the outset yeah absolutely there are lots of different ways to participate even including if you want to do testing of these for example or look at the documentation and see if the documentation user documentation makes sense to you there are man pages for example on how to use command man pages so you're using a command line argument say in the Linux and then you go this particular document doesn't really you probably didn't get updated or it hasn't been fixed or there are problems so lots of different ways to contribute yeah I love that documentation point fixing and finding documentation is hugely valuable because it's one of my pet peeves it's you know it is a volunteerocracy but not a lot of people volunteer to fix documentation couple of the points here opens up to asynchronous right so you submit a pull request it could be an hour it could be a day it could be a week and that's an interesting sort of state of being why you wait for feedback right but it's just the nature of how the pull request process and some of the collaborations with they're not always synchronous and then the last point I want to make on this slide and I'll talk to you see a couple more questions in the chat you know you get more you know there's a lot of dopamine more dopamine pull request and this ties into the fact that we talked about sort of looking on stuff that you're passionate about I think one of the things that I find really interesting about open source is that they you know they are extrinsic rewards you know people get you know hired and promoted and you know the career side formal career side of your brain if you will but there's also a lot of intrinsic rewards of just seeing your work and getting that full pull request you know that first you know I can imagine the sticker that you never forget your first pull request accepted there's a lot of intrinsic reward that comes from contributing to an open source project whether it's a pull request whether it's fixing the documentation whether it's finding an interesting way to use the project because you know that you're contributing to a community of folks who are doing this coming from a place of passion I'm going to click to the next slide I'm going to toggle to the chat here so Teoman asked can I use open source projects to learn Java or any other new languages should I contribute projects written in software languages where I'm experienced so definitely number the second one's true if you know the language so I'll pick an example you know Linux is written in C Kubernetes is written in go you know I think to the earlier questions about figuring out which ones you know which projects you want to contribute in obviously if you have pre existing language skills and that's helpful although you might also want to challenge yourself to learn some new languages right and kind of break out of your comfort zone a little bit so it might be an easier spot to start off is to look for a project that is based on a language that you're familiar with and it's a great way you know and we certainly say this you know at Linux Foundation training that the best way to learn is by doing and so if you want to learn you know if you want to learn a language whether it's Java go see whatever the best way to do that is to give yourself a little project and a great way to get a little project is to take on something like a feature enhancement or a bug patch and just kind of work your way through kind of a small piece of it I mean that's part of the beauty of how open source code gets compiled right as you can grab like a fairly you know easily manageable piece and just to work on that and then test it make sure it works with everything else and sort of push it upstream so you can pick small pieces it's not like you know you've been assigned a whole module of software that you then have to go independently to work on there's another question in here my team at CERN is developing a few projects very few of which are open source there's no good reason to not open source these projects it might be legit one of them so far that open source in projects require more effort because you have to make the project very genetic any tips on how to encourage open source culture in teams that's a great question and it's one that comes up as you might imagine very very often I think part of it is a little bit about demystifying for folks what it means to open source a project you do not have to make a project very generic to open source it in fact usually what would happen is you can if you've got an interesting project and it may be it's specific initially but if it's interesting to people because they can see the potential that's exactly what you get by open source in the project because people take that code base and they start contributing to it and saying hey you can use this to accomplish x you can do you can go in direction y you can take this and sort of repurpose it to a whole new sector so I think it actually opens the floodgates to getting other people to take that code base and build it out in new and interesting areas versus you have to take it and build it out now there are some things that you have to be mindful of in terms of the code base in terms of the license that you're going to pick and there's some you know some education that you might have to do for your team around you know the different types of open source licenses are available that are available and how you go about using them, how do you pick the right one or the same ones that you have so there's definitely some of that there's a fair amount of materials that the next foundation provides I think there's a slide at the end we can look at where that can help you think through that, help you identify what some of the issues might be and think your way through how you position that discussion for taking a project and sort of adding it into the open sourcing it and dispelling some of the myths that are out there I'm just going to scroll down here with the presentation and slides be available. Oh that is a good question I'm going to ask Kristen what, well I know the presentation will be available because we're recording it Kristen do you make the slide packs available as well I guess people can just grab the slide view you know these are not wood heavy slides so Yeah, no thanks so yep so as Clyde said it's going to be recorded and posted on YouTube and we'll also distribute the slides separately so you'll have a copy of those as well so you'll get a thank you note in the next day or so with all the information All right, so we talked about context right of you know how these, at the tech sector level software sector level open source sector level. I want to toggle now to what are some of the resources that you can use and I have this in two different buckets the first one is about people based resources and the next one is about documentation based resources Local meetup groups. I have been stunned and pleasantly so that at the extent to which local meetup groups exist for just so many projects and I think it comes back to this idea of the passion that people feel There's a pretty good chance that that there's a meetup group within sort of reasonable commuting distance from where you are on just about any of the certainly any of the larger open source projects and it's just a great way to start to establish community and connectedness to others in the sphere especially if you're getting in as somebody newer and they know they're not super formal for the most part you know they they often happen at at you know community centers or you know people get together in a bar now probably have a little bit less meeting up with the pandemic going on right now but as that seems definitely a great resource is to get involved in those meetup groups to just be able to connect with others that are that are in the space and get to know them get you know suggestions like you know with subsystems you know if you're not already familiar but it's a great resource I think it's one that people maybe aren't as aware of because there's no they aren't great they aren't analogous concepts in a lot of other places or industries right this sort of meetup group culture really doesn't appear to be most heavily active in open source so that's at the organic sort of local level but of course there are just conferences right so certainly for all the Linux Foundation projects we have conferences usually multiple times a year different locations and those are a great way to kind of take it up one level I get a lot of broad perspective with you know dozens of different speakers talking about their specific topics ton of networking opportunities they call the hallway track where you can just meet people informally over coffee breaks over lunch just a great place to you know it's great learning at the session that's also fantastic networking opportunities especially because of the nature of open source where a lot of your work is happening at your computer submitting requests updating documentation you know reviewing things it's a great way to complement that and sort of scratch your social social itch you know learn about things but also meet people and and then I would also just encourage folks to find mentors right you know whether it's through one of the venues we talked about above or just somebody that you know you know you went to school with or that you see in the community open source folks in general are just super helpful and you know if you can establish a good relationship with with someone who can be a mentor and somebody that you can turn to for advice and guidance that is super useful we have a whole mentorship program at LF which is one of the things that she works on and I know we've had sessions on that that are available you know recorded but you know finding that small group of you know one or two folks to help them to you is super valuable probably everybody knows that you know there's often hackathons on all kinds of things there's yeah maybe not quite as many hackathons as there are meetup groups local meetup groups but definitely it's a great experience it's a great way to just get yourself into the groove of actually working on code and just trying things out just kind of putting yourself into that situation where it's structured it's a given number of hours or days and it's a great way to kind of get out there and kind of almost force yourself to start doing some coding Stack Overflow for those of you who aren't familiar with it it's just a website just literally stackoverflow.com unbelievably helpful resource there are others I just I highlight Stack Overflow just because it's such a broad resource you know you can get on there and ask questions about nude or Java or Linux or Kubernetes or you know just answer just like the whole range of technologies and it's astonishing how many people contribute and answer provide great quality answers on that site so it is a fantastic mechanism for getting feedback on problems big or small so if you haven't ever done so go poke around Stack Overflow it is an unbelievably valuable resource when you have questions and it's a way to get input from people that you never would otherwise meet right so you can put your question out there and then folks will will will respond to the blog style and then the last one is is Wikis right so many maybe not all certainly the vast majority of open source projects have Wikis where you can get on and and oftentimes you can interact with folks and and you know submit questions or notifications and get feedback and so this is again not meant to be an exhaustive list but it's a good sort of starter path for thinking about how to get yourself plugged in and interacting with the people who are sort of further up the living curve than you are on a particular project. I'm going to toggle over here and look at a couple of these questions. First one is I am in an open source project that is in great need of volunteer developers any advice on finding the volunteer developers to contribute to cool list serves etc. List serves are great if you have good list serves that you can reach out and find kind of make folks aware that that's certainly helpful just be creative right you know I think again with the pandemic these you know not as many conferences are happening I know a lot of people have a lot of success giving presentations at conferences or get-togethers or webinars like this one just finding more opportunities you know the one thing I will say about list serves is they're great for reach and they're super easy to use it might be sometimes a little bit harder to sort of stand out from all the other messages flying around and so it is a heavy lift to have to put time into doing a presentation or giving a webinar or you know visiting a college campus to give a talk but I suspect you'll find that there's pretty good payoffs from going pressing some buttons that aren't just the sort of send out an email and getting engaged in communities that aren't on the list there because that is one of the big challenges right is and that's one of the things that you know I know at LF we try to always focus on is how do you get more people into the tent because you know mailing lists are great for the people who are already on the inside but really what helps all of us is to get more people into the tent and the way to do that is to find creative ways to reach out to an audience beyond the list serves so it's not always and you have to do both but you know given talks giving interviews you know thinking about what where are the tools of people that you would like to volunteer where you most likely to find them right are they at conferences in an adjacent space are they on college campuses are they you know just really challenge yourself to think about the people who aren't yet involved in your project what's the profile where they most likely to be found and then in trying to find ways to kind of get in front of that audience there's another question here on how to find a tech mentor is it okay to ask someone randomly to be a mentor advisor you can I think you're probably going to have more luck if you can come at it through a introduction you know one thing that I've seen people use very effectively is LinkedIn right so if you find somebody that you that you think you might like to approach it's the whole six degrees of separation thing that I often encourage people to go go check out LinkedIn to see who you know that knows that person or if there's a chain of a couple of people you know folks are much more receptive if it's a bit of a warm introduction so I would definitely encourage you to leverage your network you know it doesn't have to be somebody you know personally but if you think of the sort of power of the network effect the list of people that are one one connection removed from you so friends of friends is generally very large and that and that'll often be a good way to sort of break the ice and maybe even get some advice from whoever the person that you know in common about who this person is you know time availability interest etc so that you're not going in code there's another one here we'll talk about the mentorship program and how to get in one I'm going to call it sure into the service here because I know we've got a program at the LF and she's familiar with some of the other mentorship programs obviously there's things like Google some of code and code some code but sure you mind if I tag you on the on the how to go about getting in into a mentorship program no problem yes I'll be happy to so we have resources the last closing side slide has a lot of resources and this is we have three kinds of mentorship programs mentorship outreach and programs at LF this mentorship series is one of them we are trying to educate people with the resources and topics that are of interest to people and the second one is a formal mentorship program which is runs three months or six months you can check that out I will put the link in the chat I think the last site closing slide has the link as well you can check out the various projects all right let's see here other valuable resources documentation there is a ton of documentation some of it's in line in the project so in like Linux Man Info Help you know there's all these different commands you can type in sort of in the project itself to get help so definitely use those pretty much everybody has a wiki there's root means sorry somebody had a question one second I'll be right there oops somebody needs on mute training courses and that has a bunch of free training courses again there's a link in the slide at the end on starting with Linux current development a great course that sure created somehow magically in a spare time early in this year that has like almost 10,000 people in it already there's a course on basics of licensing compliance which I find super useful for folks when they're getting into open source to make sure they understand the concept of how these different licenses work and of course and that doesn't have a monopoly on this there's a ton of other places that you go to get good high quality often free training courses on to help you sort of ramp up and of course more Google is super useful takes a little bit of time sometimes to sort through the end million results that you're going to get but this is a point I make on a different slide which is the more you take matters into your own hand to try to figure things out a the more likely you are to be able to figure it out and move ahead but be if you do need to ask for help it positions you very well so you know leveraging the documentation thing to the point somebody asked earlier finding the maybe what you do is it may have to find a way to contribute to the documentation if you find a hole in there but definitely take advantage of the of the material that is already in existence I'm going to click on here this is a little bit of sort of the the interpersonal side right to just reflecting on some of what we've talked about in terms of the nature of how tech and open source software works and the dynamics of people volunteering and but not having necessarily always personal relationships and so no surprise the first one is to try to build some relationships right you know do it in major groups conferences which other people on LinkedIn you know try to create sort of a community what I would call a community of practice of folks that are working on a project or similar projects kind of in the same zone that you are I think having that network is always super valuable I mean this is true obviously in personal context as well as professional context but definitely it takes more effort I think one of the challenges in open source is you have to make more of an effort to build some of those relationships because by definition you're not on the same campus right you're on the same company you're not down the hall like you're going to have to do some outreach on your own to try to find those folks if you come into a project new for the first time. Take a breath. What I mean here is just you know we talked about sort of people I mean on the internet. It might happen right and somebody might be mean to you and you just have to you know remember that they're probably not trying to attack you personally they're probably having a bad day and they're already doing this in their spare time in the middle of the night. You know I think what you will find in general is that the folks are coming at this from place of passion and interest and sometimes you do need to take a breath and let things kind of wash over you and digest and then moved on. The distance of doing stuff on the internet does make it harder right you don't you don't see the expression on the person's face when they're giving you the comment right you don't hear the tone of their voice. And it does make it difficult sometimes to to get all the context and maybe jump to the wrong place just yeah I think being being forgiving of digital communication is a useful place to be. I think this is the point we were making earlier all the way to Rome find a place to start right just find a place that's interesting to you. You know there is no magic sort of single highway that takes you to where you want to be. You know they all lead to the same place they all lead back into the code base to just you know find a place to start kind of work at it. You know I tell folks all the time to look for patterns. You know because what I will tell you is you know which areas of the code and most dynamic. It might you know if you look at patterns in terms of how code gets used you to cut patterns in terms of error rates. You know trying to sort of find signals in the noise is a great way to have you focus on areas that that might be most impactful. And then finally you know my old mentor used to always say you should ask yourself is the client with the view. And you know how hard do you want to battle for your particular perspective how hard do you want to try to you know how much effort do you want to try to spend sort of cracking a puzzle. You know sometimes you can get into these loops where there's a little bit of sort of head banging against the rock. And so I think keeping that in mind of sort of what's the payoff going to be to help guide your level of interest and attention. I'm just looking at the questions. I'm sorry that's bad idioms on my part. Mark Google is just using Google as a search engine. Somebody said what is more Google getting Google maps just I just meant using Google as a resource to find helpful documentation. You can sometimes formulate very specific questions and find interesting. You know blogs wikis articles on things that you might have thought was a very sort of esoteric type question. All right. I just have two more slides here. The first one is top five don'ts. I have some dudes and some don'ts. And these are just my personal, you know, there's others. I'm sure there's a long list of on both of things on both lists you could put on this first one is something we have we touched on this a little bit in that, you know, there are kind of stupid questions. And what I mean by that is the more you invest in figuring trying to figure out what the issue is that you're dealing with the challenges, you know, doing your research, reaching out to your network. The better if you end up needing to ask for help and ask a question. The more effort you've put into defining that well, the more the higher the likelihood that somebody is going to respond and be helpful. You know, I, I give the analogy all the time that, you know, and I've always found that whenever I'm in France, for instance, my French is atrocious. But if I stop with my atrocious French people are super helpful and actually talk to English and and just the fact that I that that I was making the effort. I get I get a much better response. I think the same thing's true, particularly in open source. I think open source has, and again, as somebody who kind of came into it new. There's definitely a premium on on sort of respecting and valuing when people try to be self sufficient. Right. And so if you say, if you can come to something and to look at, you know, I fit an issue. I've tried this documentation says that, you know, I went here for her but I just can't figure it out. You're going to find people very much more receptive. Because you've demonstrated that you have tried to find the answer to the question. This next point is, you know, don't reinvent the wheel. There are a ton of packages out there if you're on the web development type side or modules out there and the regular code side but you know, I would encourage you that when you're, if you're if you're doing development work to spend some time looking at the code that might already exist to solve some part, maybe even all of the issue that you're facing. There's just so much great code out there now and there's no shame in reusing code right it's everybody does it. If it exists, it'll speed your journey to get you to your delivery to your endpoint. Don't feel the need to have everything be kind of uniquely your own. Don't assume the worst. We talked about this a little bit. Just, you know, sometimes people might be. Now, you might feel rubbed the wrong way that doesn't necessarily mean somebody was was trying to attack you personally could be true but don't assume the worst of the outside right try to try to push past and understand the context and, you know, if you get to that place where something bad's happening then you know that's trying to make sure that's really what what the case is because it is just communication on the Internet really can be difficult. Beware your comfort zone and this is back to this idea of sort of not just sticking to what you know, you know, push yourself to learn new concepts new models, new languages. I'm not going to need to anyway, but this is the point about the red queen effect we talk about the outset just push yourself to find out of your comfort zone to create those new skills to create those new insights. And then my final plug here just because it can be a challenge is spend some time understanding open source licenses and which ones, which are used in which purpose as a great free course. We have on this from the foundation. Make sure you understand that context. Of the of the different licensing regiments and what it's a permissive license and what is a restrictive license and what does that all mean. It is super useful to have you don't need to be a lawyer I think you just need to understand those concepts. I have a question from Kevin, he says, can we do a demo of how to go about finding a new project where on GitHub, do you look. You know, I thought about that I sort of deliberately avoided trying to do that just because there's so many different ways to kind of find project obviously you can go on GitHub and you can do some basic searching on kind of types of projects that are out there. I would actually recommend not starting on GitHub and actually, you know, using, you know, maybe some more refined Google searches to try to get a sense for what projects exist and sometimes that can be as basic where you know popular open source project on X. I literally did that as a user couple weeks ago because I run an open to desktop and laptop and the project I had been using to do captures of screenshots called snip got deprecated. And so I literally started googling for what's the best open source alternative to snip and I found the one I'm using now. You know, just, you know, you can do surprisingly good information that you can find on different types of projects and where things which things have traction before you kind of try to go to GitHub and then inspect the code because it's in a GitHub sort of and get lab kind of assume you kind of know what you're looking for. They're not necessarily great discovery tools, but the web is a great discovery tool to see what people see. All right, and then last slide I had is, you know, what are the top five do is just talk about top five don't learn the tools in the language is kind of push yourself out of the comfort zone. Start small something you're passionate about. You don't need to, you know, use the baseball analogy don't need to hit a home run right off the gate right just get get a small piece take it on or take a piece of software and start using it and then sort of build out from there. So all the time bug fixes are a great way to start small patches, you know, you don't have to go, you know, sort of invent this like with bang new feature right out the gate. I will say, you know, this is this point about sort of, you know, behind your GitHub handle nobody knows who you are. For all they know you're an accomplished coder on some other project right and so I think if you know, having the self confidence, you know, tell you put your code together user tested will be confident in what you put out right then people aren't able to sort of see past the handle to make any assumptions about the quality of your work they just see the quality of your use that to your advantage especially early on. And then the final point is just it is a team sport right be prepared to collaborate be prepared to have dialogue debate robust debate disagreement even. You know, these are. There's as much human systems as they are code systems right and so you know just engage it and interact with folks and be be part of that human side of the, of the dynamics. That's my last slide my next slide is just kind of team up the Q&A. I do see another question in the chat here and it says resources provided are helpful and I will use them. I'm looking for an open source we just beat project platform, mainly related to multi family acquisitions if you have any additional guidance or knowledge about an effort like this. Appreciate it. I do it but again I would I would encourage you to do a series of just kind of targeted web searches that I have found you know the two great ways to find this type of project is either. Kind of try to narrow the switch down on the web and progressively tighter criteria or tap your network right and just kind of go out there and kind of pull your friends on text or WhatsApp or whatever and see who's come across something. You know once you're in a specialized space like real estate that's typically going to be the fastest path to discovery. So if you guys want to jump in you can type questions in the chat you can unmute yourself and ask. I guess I sure any other commentary you will add in terms of do's and don'ts of folks. I can add one thing that never get too attached to the solution you proposed in a patch as very sure you will have to change it in some sometimes you might even end up with something that's much better and doesn't have any resemblance to what you started with. So I would say don't get too attached to your solution. So that always is a tip that I give everybody. Very cool. Thank you. All right. I'm just looking at the Q&A. I'm just trying to also scroll through the, I hadn't had the chat window open. Yeah, comment here about the first struggle points you need to overcome is to take before you contribute cold is the ability to build and debug the code. Yeah, definitely conclude with that right figuring out kind of your pipeline and how to set up. And again this is it's not as intimidating as it sounds if you're coming to it cold right you don't go, you know, get some of the do some training courses on it and, you know, start small spin up environment and environment and start sort of practicing. That's definitely worth doing. Just letting you know Clyde we have about 10 minutes left, just to let you know. Thanks I just I was just trying to scroll through a too many windows open I was mainly looking at the Q&A window and I realized there was a kind of chat window open as well. Actually while we wait for new questions to come in I do want to just take a couple minutes and talk about the last slide here on some resources that are available. I'm going to talk about the last mentoring program which she were heads up. I believe these are the documents so you can, when the, when the deck comes out. You can kind of click through this one goes to Community Bridge which is our platform for for mentoring so definitely encourage folks who are interested in that sort of program to check out the last mentoring program outreach which they've done a really good job with their remote internships right so this year again. You know, the pandemic made it really rough on some other types, you know, because some of code it always been super popular but was more oriented towards in person outreach he's got a great remote program that you might want to look into. The group I had up the training group just a ton of free courses so if you go to just training.linuxfoundation.org. And, like I said, she was course on getting started with Kernel Development if you're interested in Linux Kernel definitely recommend the course on open source licensing compliance basics you can just go to the site and search for that that is super helpful. And you'll see there are a bunch of additional courses, especially the free courses are a great place to start so you know you can just you make the investment of time right to go find them and do them but we do try to provide quite a lot of available content. And then this events team at Linux Foundation, there's just so many great events to get put on over the course of the year. It's not just great presentation, but just great what we call hallway tracks right the ability to meet with expand your network. You know, catch up over coffee, you know, ask folks things in person that you might maybe not feel comfortable asking over email is just there's a great series of additional resources that we try to provide to the community that they would encourage folks to take advantage of. All right. Hello we're getting close to the end here. I want to leave it open for any other questions I see one in here about especially good free online courses definitely the ones that I was discussing and on the development get started with open source. If you go to the training.net foundation org. I guess I can put it up. And, and just look through the free course section that's really useful. We put a lot of our content up on on edx so edx edx edx.org. One of the platform sites that was originally for sort of college courses, but the reason I point folks to edx is they're the only one where the vast majority of the content is still available for free so there are others you'd ask me you'd ask the cost error you to me. Most of their courses have become paid because they're all for the venture capital back companies edx is a nonprofit. And because I think because of that they still do provide truly free access. And we as a left have had like over one and a half million closing in on two million people take off free courses through edx but edx is also a great place for free content across a whole range of different technologies and that stuff. Definitely would encourage folks to go check that out. Client, there seemed to be one question about open source governance in the question and answer. Do you want to talk to that? I'm going to try to find you you want to just start on it while I sort of dig it out. Yes, the question is can you expand on the governance of open source projects. Right. So I can definitely talk about how governance works within the Linux Foundation for open source projects. I think it's probably largely similar for projects hosted at places like eclipse or Apache. There are technical, technical advisory boards that that shape the projects direction that are separate from the membership side so LF has commercial companies and sometimes non commercial companies who are members of the organization and who are members of projects. But that's different than the technical advisory boards. And so, you know, we do try to maintain for the projects that are hosted at LF a sort of separate swim lane if you will for the sort of technical direction that the tabs we call technical advisory boards to ensure that we're still having these projects being driven from within the community by those who are most passionate versus those who can afford to be part of a project with the sponsors of a project. And that's really critical right you want to try to make sure that you keep in the door open to a variety of different perspectives and ensure the health and longevity of the project. So I think from a governance perspective, and that's something that maybe is always clear here on the outside looking in the sort of dual track governance of overall project management versus technical project management is something that we at LF has had have had a lot of success doing. There's a question in here about Is there a central list of active projects. There is unfortunately not there's so many projects that if you go and get up there's some astonishing number of new projects being put up every day. There's a project hosted at the LF so you can go to the next foundation org. But that's just, you know, we have a ton of projects we have over 300 projects hosted with LF but that is still a rounding era compared to the thousands and thousands of repos that are out there on a GitHub, or a get lab. Okay. I mean, any closing remarks Clyde or Shua. You know, I would just say that I just reinforced the point I made on that one slide about all roads lead to room just pick a place to start. Find a place that's comfortable find a place you're passionate about and, you know, it doesn't have to be on, you know, the world's sexiest topic or the world's sexiest open source project. So get your feedback. That's the important thing is get your feedback start looking on it. You know, don't wait for the perfect project opportunity to come along. Yeah. Good advice. Okay, well, there are no more questions I'd say we can wrap it up. What do you think Clyde. Sure thing. Thank you all for attending. Thanks everyone and hope you have a great day. Bye all.