Latest / DevQuestions with Tim Corey / 075 How Do I Get Started In Open Source Development?

Transcript

075 How Do I Get Started In Open Source Development? · DevQuestions with Tim Corey

• 0:00
  SPEAKER_00: Welcome to the Dev Questions Podcast with Tim Corey.
• 0:03
  SPEAKER_00: Join us each episode as we tackle the questions you are asking about a career in software development, understanding the industry, and new technology.
• 0:12
  SPEAKER_00: If you're just starting out or you want to grow stronger as a developer, this is the place to get your questions answered.
• 0:19
  SPEAKER_00: Now, here's your host, expert developer and online educator, Tim Corey.
• 0:25
  SPEAKER_01: How do I get started in open source development?
• 0:28
  SPEAKER_01: It seems so intimidating to look at open source and say, where do I even start?
• 0:34
  SPEAKER_01: Well, the good news is there is a way to start small, start simple, and kind of build your momentum to the point where you're a full-fledged contributor to open source development.
• 0:46
  SPEAKER_01: And that's getting really good for both your career because you'll be uh actually writing code.
• 0:54
  SPEAKER_01: You'll be contributing code you can show off to employers, but you'll also be making contact with people and starting to build a network of community that knows who you are and knows that you contribute back.
• 1:06
  SPEAKER_01: It's also good because you are giving back to the community and you're helping out, and helping out is a benefit to everyone, including yourself.
• 1:17
  SPEAKER_01: So, how do you start small in open source development?
• 1:22
  SPEAKER_01: Well, first of all, I would not start with creating your own repository.
• 1:27
  SPEAKER_01: That's kind of a later step.
• 1:29
  SPEAKER_01: And the reason why is you need you need to get the flow of how this works.
• 1:34
  SPEAKER_01: That way you understand kind of the pitfalls to avoid, the things that you should put in practice, the best practices, and so on.
• 1:43
  SPEAKER_01: So start small on somebody else's repository.
• 1:47
  SPEAKER_01: Find your repository that you want to contribute to, maybe one that you use in your everyday life or that you just understand well.
• 1:56
  SPEAKER_01: And then look to see what small changes you could make.
• 2:00
  SPEAKER_01: Maybe you find some typos.
• 2:02
  SPEAKER_01: Well, you can actually fix those.
• 2:04
  SPEAKER_01: Fix the typos, create a pull request, get that process down where you understand.
• 2:09
  SPEAKER_01: Okay, I create a pull request, here's how it works.
• 2:12
  SPEAKER_01: I've, you know, I clone the repository, I fork the repository and clone the repository, I make the change, I wrap it all up, I submit as a pull request, I get it reviewed, I get it merged.
• 2:24
  SPEAKER_01: That kind of process, start small on it.
• 2:27
  SPEAKER_01: Just get to understand the basics of how that works and kind of build up a little bit of momentum.
• 2:33
  SPEAKER_01: Then maybe look at the documentation.
• 2:35
  SPEAKER_01: Documentation is always something that can use improvements.
• 2:38
  SPEAKER_01: There's very, very few projects out there that have documented well.
• 2:43
  SPEAKER_01: And even they can use some additional documentation.
• 2:47
  SPEAKER_01: So look at the documentation and figure out where there's some weaknesses.
• 2:52
  SPEAKER_01: Ask yourself the question: if I didn't know this so well, would I understand what to do next?
• 2:59
  SPEAKER_01: Would I understand when I should do something?
• 3:02
  SPEAKER_01: And then create additional documentation.
• 3:05
  SPEAKER_01: Use examples, create small code samples, and then build a documentation piece and then create a pull request for that.
• 3:14
  SPEAKER_01: And that's gonna give you an additional step where you're actually helping others out, not just with fixing a typo, which is important but not huge, but now you're actually making the community better because they're more they can more easily use the tool that you're contributing to.
• 3:34
  SPEAKER_01: And by doing that, you make the tool more popular.
• 3:38
  SPEAKER_01: Because when I go and find a tool online and there's no documentation, I almost never use it because I don't know where to start.
• 3:46
  SPEAKER_01: I don't know what the reason for the tool is existing is.
• 3:50
  SPEAKER_01: I don't know why I would use this tool versus another tool.
• 3:54
  SPEAKER_01: So I'll just skip it.
• 3:56
  SPEAKER_01: And if a documentation is poor, I might start trying to use it and then get frustrated because I don't understand what to do next or how to fix this bug or or why this doesn't work.
• 4:08
  SPEAKER_01: And then I'll just stop using it because I don't have time to learn all or go through all the source code of maybe a small tool to understand it when I have so many other things to do.
• 4:19
  SPEAKER_01: So good documentation is huge.
• 4:23
  SPEAKER_01: Now, after that, may look for the tags in or the labels in the issue list, things like up for grabs or first timer.
• 4:34
  SPEAKER_01: Look for things like that where they are encouraging new developers to jump on board and help out.
• 4:42
  SPEAKER_01: And they're saying, hey, this you can go ahead and do this.
• 4:45
  SPEAKER_01: This is maybe it's a first timer tag, and first timer tags are great.
• 4:49
  SPEAKER_01: Because what they're saying is that not only is this a fix, it's probably a little easier to do, but it's also something that they're gonna help you with.
• 4:59
  SPEAKER_01: Because when you submit a pull request, it's not just as simple as here's the code, go ahead and merge it in.
• 5:06
  SPEAKER_01: You've got to do more than that, you've got to conform to the rules of how they're looking for the code to be set up.
• 5:14
  SPEAKER_01: Do they have unit testing and have you run that?
• 5:16
  SPEAKER_01: Do you need to write new unit tests?
• 5:18
  SPEAKER_01: All those kind of things are important to understand.
• 5:21
  SPEAKER_01: And so that first timer tag, especially, is going to help you kind of show off, hey, I'm not real comfortable yet doing these things.
• 5:32
  SPEAKER_01: So I'm starting here first.
• 5:34
  SPEAKER_01: And people will help you walk through the process of submitting that pull request, getting it right, and getting it merged.
• 5:43
  SPEAKER_01: Now, with that, I recommend that you look for completed pull requests to see the pattern.
• 5:50
  SPEAKER_01: Look at what the pattern was where the person said, okay, I'm going to work on this, I am working on this, I have completed this, and how they tag things, what uh things they bring in or do, what pattern they follow, and so on.
• 6:06
  SPEAKER_01: Also look for submission guidelines.
• 6:10
  SPEAKER_01: Usually projects will say, This is how we want you to submit pull requests.
• 6:15
  SPEAKER_01: These are the steps we want you to take.
• 6:17
  SPEAKER_01: Make sure you follow those.
• 6:19
  SPEAKER_01: All right.
• 6:20
  SPEAKER_01: So conform to the project, conform to how they want things done, and make sure that your your help is actually a help.
• 6:28
  SPEAKER_01: Don't just fix their formatting.
• 6:30
  SPEAKER_01: Because if you fix their formatting to fix to fit your perspective, that's getting rejected.
• 6:37
  SPEAKER_01: Okay.
• 6:38
  SPEAKER_01: Do something that actually helps the project and makes it better in some way.
• 6:43
  SPEAKER_01: Now, from there, work up to larger fixes, like actually fixing bugs.
• 6:48
  SPEAKER_01: Go through the issue list and say, hey, could I figure that one out and try and fix a few bugs?
• 6:55
  SPEAKER_01: And then maybe look for again small features that have been requested.
• 7:00
  SPEAKER_01: Maybe it's a small tweak that really is bothering someone and that no one has time to really delve into.
• 7:07
  SPEAKER_01: Figure it out, fix it.
• 7:10
  SPEAKER_01: Or add that feature.
• 7:11
  SPEAKER_01: And then also performance improvements.
• 7:14
  SPEAKER_01: Look to see, hey, you know what?
• 7:16
  SPEAKER_01: I see they're using, you know, maybe in C sharp it's adding two strings together, and they're doing a lot.
• 7:23
  SPEAKER_01: Maybe we can look at string builder.
• 7:25
  SPEAKER_01: Would that make their performance better in this particular spot?
• 7:28
  SPEAKER_01: Don't just change the code, make sure you test it to make sure it actually does improve performance.
• 7:36
  SPEAKER_01: But with that, you could make the repository better.
• 7:39
  SPEAKER_01: So that's a little bit larger fixes, you know, bug fixes, small features, performance improvements.
• 7:44
  SPEAKER_01: These are things you can do next after you get that ball rolling.
• 7:48
  SPEAKER_01: Now, here's some tips.
• 7:51
  SPEAKER_01: When you're working with open source, especially with somebody else's project, work with the owners or admins.
• 7:58
  SPEAKER_01: Don't try and go off on your own.
• 8:01
  SPEAKER_01: You are not the boss.
• 8:02
  SPEAKER_01: They are.
• 8:03
  SPEAKER_01: Act like it.
• 8:04
  SPEAKER_01: I have seen a number of people who've tried to force their own way and say, well, this way is better.
• 8:11
  SPEAKER_01: It doesn't matter if it is or not.
• 8:14
  SPEAKER_01: The fact that you are going against your boss to do it isn't gonna work out for you.
• 8:19
  SPEAKER_01: Okay.
• 8:20
  SPEAKER_01: Treat them with respect.
• 8:22
  SPEAKER_01: They are the owner, do it the way they want.
• 8:26
  SPEAKER_01: Talk to them.
• 8:27
  SPEAKER_01: Ask if this is the way they want it done.
• 8:30
  SPEAKER_01: Ask if you can do something.
• 8:32
  SPEAKER_01: Okay?
• 8:32
  SPEAKER_01: And then don't take rejection personally.
• 8:36
  SPEAKER_01: You're not the owner of this project.
• 8:38
  SPEAKER_01: They are.
• 8:39
  SPEAKER_01: You're not the one that has to maintain it.
• 8:42
  SPEAKER_01: They are.
• 8:43
  SPEAKER_01: You're not the one that has to deal with the long-term consequences of a potential action.
• 8:49
  SPEAKER_01: There are times when a good short-term solution might be a bad long-term solution.
• 8:59
  SPEAKER_01: Maybe uh, for instance, you could bring in a third-party library to solve this problem and you get rejected.
• 9:06
  SPEAKER_01: And the reason why is because we don't want to take dependency in that library.
• 9:10
  SPEAKER_01: Well, you may argue, yeah, but that fixes the problem.
• 9:15
  SPEAKER_01: It does in the short term, but now every every client, every person who uses their package has to take an additional dependency.
• 9:24
  SPEAKER_01: And that might not be okay, and it might even not allow the project to be used in certain circumstances.
• 9:32
  SPEAKER_01: So short term it might be good, long term might be bad.
• 9:36
  SPEAKER_01: Trust the owner of admin.
• 9:38
  SPEAKER_01: Don't take the rejection personally.
• 9:40
  SPEAKER_01: It's not about you, it's about how they are trying to shepherd their project through.
• 9:46
  SPEAKER_01: Okay.
• 9:47
  SPEAKER_01: And then don't argue.
• 9:49
  SPEAKER_01: Okay.
• 9:49
  SPEAKER_01: If you don't agree, fine, you don't agree.
• 9:52
  SPEAKER_01: Don't argue about it.
• 9:53
  SPEAKER_01: Okay.
• 9:54
  SPEAKER_01: This is not your project.
• 9:55
  SPEAKER_01: And if you want to make your own project, then at that point go ahead and do.
• 9:59
  SPEAKER_01: But don't just argue with people because what you're doing is you're actually hurting the project, not helping it.
• 10:08
  SPEAKER_01: Because remember, these are all people who are donating their time.
• 10:12
  SPEAKER_01: Don't just cause them more frustration and grief.
• 10:16
  SPEAKER_01: Okay.
• 10:16
  SPEAKER_01: So these are tips to help you better work with other product owners and work better in open source.
• 10:24
  SPEAKER_01: Now, stick with one repository for a while.
• 10:27
  SPEAKER_01: So if you're helping out one repository, don't skip around.
• 10:31
  SPEAKER_01: Stick with that repository, make it better.
• 10:33
  SPEAKER_01: Start those uh, you know, typo fixes or documentation, move into bug fixes, small features, but really help out that repository.
• 10:43
  SPEAKER_01: Because you're gonna not only be contributing to open source, you'll also be building a reputation in the community.
• 10:52
  SPEAKER_01: That reputation can open doors for you that you might not even be thinking about.
• 10:57
  SPEAKER_01: So if you're to lose your job and you were to tell the people there you build a relationship with, hey, I lost my job, or maybe they start following you on Twitter and they find out, hey, you lost your job.
• 11:07
  SPEAKER_01: Hey, you know what?
• 11:09
  SPEAKER_01: They probably work at other organizations.
• 11:11
  SPEAKER_01: And maybe they say, hey, you know what?
• 11:13
  SPEAKER_01: This person's a great employee.
• 11:15
  SPEAKER_01: They know C sharp inside and out because they've been working with me for X number of years, and you might find yourself in a better situation because you were contributing to open source and building that reputation.
• 11:30
  SPEAKER_01: Now, don't get discouraged by setbacks, they're gonna happen.
• 11:34
  SPEAKER_01: This is the way it is in jobs, too.
• 11:36
  SPEAKER_01: Okay, so don't get discouraged by that.
• 11:38
  SPEAKER_01: It's okay, just keep moving forward.
• 11:41
  SPEAKER_01: If you have to switch to a different repository, do so.
• 11:44
  SPEAKER_01: But try and build that reputation up of being a positive, encouraging, helpful member of the community, not a negative, discouraging, tearing down uh thorn the flesh for the community, okay?
• 12:00
  SPEAKER_01: That positive positivity and help is going to push you a whole lot further forward.
• 12:06
  SPEAKER_01: Okay.
• 12:06
  SPEAKER_01: So thanks for listening to this week's episode of Dev Questions.
• 12:09
  SPEAKER_01: I hope that answers the question of how you get started in open source development.
• 12:13
  SPEAKER_01: If you have a question about being a developer, check out the previous episodes either on YouTube where it's a video podcast or on your podcast app of choice where it's just an audio podcast as well.
• 12:26
  SPEAKER_01: Thanks for listening.
• 12:27
  SPEAKER_01: And as always, I am Tim Corey.
• 12:30
  SPEAKER_00: Thank you for joining us for this episode of DevQuesti.
• 12:33
  SPEAKER_00: Tim is committed to making it easier for you to become a developer.
• 12:36
  SPEAKER_00: If you would like to help make more content like this possible, please like, subscribe, rate, and share DevQuestions.
• 12:44
  SPEAKER_00: You can also send your questions to questions at IamTimcorey.com.
• 12:49
  SPEAKER_00: Until next time, remember, you are too smart and your time too valuable to waste it making all the mistakes Tim did.
• 12:56
  SPEAKER_00: When you're ready to learn to think and code like a professional developer, head over to imtimcorey.com and enroll in the course.