Level Up with OSS
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Part Number | 21 | |
| Number of Parts | 94 | |
| Author | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/30678 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
RailsConf 201521 / 94
1
4
7
8
9
10
11
13
14
16
17
19
21
24
25
29
30
33
34
35
36
37
39
40
42
47
48
49
50
51
53
54
55
58
59
61
62
64
65
66
67
68
70
71
77
79
81
82
85
86
88
92
94
00:00
Position operatorMultiplication signCASE <Informatik>SpreadsheetCodeEvent horizonFrame problemBuffer solutionSystem administratorBitFormal languageProjective planeOpen sourceRule of inferenceMultiplicationSoftware developerParticle systemTranslation (relic)Revision controlComputing platformDifferent (Kate Ryan album)MathematicsLink (knot theory)Software maintenanceShared memoryOcean currentLevel (video gaming)Traffic reportingReal-time operating systemDecision theoryProcess (computing)Sound effectOnline helpInheritance (object-oriented programming)Software bugVideoconferencingBit rateView (database)Software testingRight anglePlanningGraph coloringPoint (geometry)InformationsrateNeuroinformatik2 (number)QuicksortDebuggerThumbnailWritingComputer animation
05:31
Software developerCodeProjective planeError messageInformationOnline helpImage resolutionShared memoryOpen sourceSource codeLibrary (computing)TelecommunicationRevision controlTask (computing)Software maintenanceQuicksortMereologySoftware repositoryRight angleFormal languageBlogPresentation of a groupTrailDistanceGoodness of fitCausalitySelf-organizationDifferent (Kate Ryan album)Multiplication signPoint (geometry)Fault-tolerant systemProfil (magazine)WordSound effectReading (process)Software bugCommitment schemeBit rateSlide ruleDynamical systemWebsiteTable (information)2 (number)Pole (complex analysis)Open setSpacetimeAreaMessage passingComputer animation
11:02
CausalityDecision theoryCodeExpected valueMereologyEmailOnline helpForm (programming)Process (computing)Open sourceSoftware maintenanceMultiplication signLevel (video gaming)Closed setHost Identity ProtocolDependent and independent variablesDivisorProjective planeMathematicsBitLibrary (computing)Revision controlInternet forumComputer animation
13:06
Projective planeRight angleLikelihood functionOpen sourceComputer fileError messageBit rateInformationWikiMultiplication signRevision controlProcess (computing)MereologyAxiom of choiceSet (mathematics)Online helpNeuroinformatikPower (physics)Computer animation
15:55
Coefficient of determinationBit rateProjective planeTwitterCodeMultiplication signBranch (computer science)CloningProcess (computing)NeuroinformatikPoint cloudArmComa BerenicesRevision controlMereologySet (mathematics)WorkloadRoutingRight angleLink (knot theory)MathematicsInstallation artComputer animationMeeting/Interview
18:24
CodeSoftware developerCommitment schemeVideoconferencingTask (computing)BitRight angleOnline helpMultiplication signDependent and independent variablesMereologyArithmetic progressionComputer animationMeeting/Interview
19:48
Thermal expansionCodeOpen sourceSystem callComputer configurationElectronic mailing listSoftware developerMathematicsBuildingWritingMultiplication signPlastikkarteLevel (video gaming)Projective planeTwitterBlogDifferent (Kate Ryan album)Task (computing)Software maintenanceTelecommunicationTrailBootingOrder (biology)WhiteboardArithmetic meanTerm (mathematics)Personal digital assistantWordPoint (geometry)MereologyDependent and independent variablesDampingQuicksortSoftware bugRight angleTheory of relativityStreaming mediaSocial classProduct (business)FeedbackTouchscreenCASE <Informatik>AreaBit rateAsynchronous Transfer ModeConnected spaceCuboidSelf-organizationComputer animation
Transcript: English(auto-generated)
00:11
My name is Courtney Irvin. I am a platform engineer with Code Montage and that's an open source project so I'm also an open source maintainer. Two
00:23
years ago though I was not a platform engineer. I was an administrator at a nonprofit and when I say administrator I don't mean like systems administration like IT stuff. I mean I managed volunteers, I planned events, I occasionally used Excel spreadsheets, it was a terrible time. So
00:42
I've moved on and I'm writing code now and I can honestly say that there's no way that I would have my current position and my current knowledge and skills without having written open source code and contributions. I'm a self-taught developer by which I mean that I didn't pay anyone to teach me. People taught me I just they didn't get paid for it I'm so sorry.
01:05
And some of that like free learning that I got, free learning that I got was through writing open source code. So I think that it's incredibly beneficial to your career, to your learning, to your growth and so that's kind of why I'm really interested in getting people to write more open
01:21
source code. Also there are a ton of maintainers out there that just don't have the manpower to maintain projects at the level that they'd like and you can be the change that they deserve. Okay so the first thing you want to think about when you are getting ready to make some open source contributions, pick a project, are what your goals are, right? And there are lots of
01:41
different reasons to get into open source. I would recommend you have two different kinds of goals. A personal goal, something for yourself that has nothing to do or very little to do with your career, right? And then a professional goal that is maybe related to your job, your current job, a future job, something like that. And those goals are going to guide some of the decisions
02:01
that you make and sort of the projects that you choose and what you're willing to put up with and what you're not willing to put up with. So some of the goals are listed here. New technologies like getting to know a new technology, getting to know how to link up rails with an angular front end or what have you. Version control, getting really good at Git and GitHub, getting
02:20
really good at different processes, working with a distributed team is a skill. That's a skill, you know, being able to communicate from a distance and get your point across. Code reviews, maybe you just want someone really experienced to look at your code. A really good way to do that is to give them code that helps them, right? Not just like give them a link to
02:41
something that you're working on. Visibility, so making sure that other people know that you write code, getting to know people in the community. And also helping out the community, right? Giving back to a project that you've already worked with, that you depend on, giving back to some nonprofit projects. We'll talk about that in a second. And just in general, your goals should
03:04
be about you and your needs, right? So your goals aren't my goals. One of my goals was getting to know rails because I didn't know it when I started contributing to rails projects. So I learned a lot. And what I want us to do now is just say to yourself, yes, you can do open source code. If you've been
03:24
holding back because you're afraid, if you've been holding back because you don't think you know enough, you do, okay? I'm gonna talk about this in a second, but what I'd like you to do right now is just look around and find someone else's eyes, right, in the crowd. Just look around. It's gonna be a little bit like Catholic mass, peace be with you, like make the awkward eye
03:42
contact, and give that person a thumbs up and be like, you got this. Just meow with it. You don't have to say it out loud. You got this, right? Okay, so you have permission to write open source code now, all right? Do it. If you haven't done it before, I've just, someone has given you permission. Take that permission, all right? All right, and we're gonna talk about, I'm gonna, I'm
04:03
gonna go through. This is, I spent a couple minutes, just a couple, thinking about all the ways that you can contribute to open source. A lot of these don't involve code, right? Bug reports. A lot of times people will put up an issue and they're like, okay, this thing doesn't work. Well, that's not really helpful to the maintainer, to the people writing code, right? So find an
04:23
issue. If you come across a bug on your own, do a little research. Share some links, right? Do something to push it forward. Take a video of the bug happening. That's super helpful. Take a pic. Documentation details. A lot of times people assume, or you know, I have it set up on my computer and it works on my computer, right? Well, that's not really helpful to everyone. So if you
04:42
come across an issue with documentation, making sure that there is documentation, sometimes people assume that coders know more than they do, right? Maybe they don't mention that, hey, this is in a different version of Ruby than maybe most code is right now, or it's in an older version and you might want to use a Ruby version manager. Translations. If you know multiple languages, get someone else's website to work on multiple languages.
05:05
Creating seed data so that there's a lot of data for other, for new developers to work with, so that they can kind of see examples of the code base as they exist in real time, as opposed to, for example, if you list a bunch of projects, having only three projects is going to keep you from being able to
05:21
solve certain issues. So having 25 projects really clearly makes it easier for everyone else. Add some tests. No one writes enough. Do it. Design ideas and reviews. As you'll see in my slides, I am not a designer. I think that they are witches, and I respect them for it, and I think that if you know design, share
05:40
that with someone who does not. Code reviews, right? So go to some pull requests that are already existing. If you know the code, if you're familiar with it, then comment on those code review, on those pull requests that already exist, and keep someone else from having to do that first pass, right? Help someone else improve their pull request before it even gets to the people who are on that team. Share ideas for features. You can promote a
06:03
project that you maybe don't have time to work on, but tweet about it, blog about it, star it on GitHub. That takes a couple seconds, and you're still helping that project. Track it on GitHub, so watch it and look for notifications about things that you can help with. Update a library. We're about to be Rails 5. Somebody's gonna need help with that, right? So I would
06:24
suggest you don't do that without talking to the person first. Like, they may not want that, but update a library or a gem that they're using from an older version. Fix any syntax errors that there are in the code so that the code is more maintainable and easier to read. Fix
06:40
typos. That requires almost no code knowledge whatsoever, so fix typos that you see on a website. And then finally, and we'll talk mostly about this for the rest of the presentation, code, right? Maybe write some code. That would be nice, okay. So the first thing you want to do is find a project and choose which one you want to work on. And you can do that by just searching GitHub,
07:03
but there are also a lot of tools that you can use. So Code Montage, the company that I work for, has social good projects that are open source. So open source social good projects, you can search by cause and find something, like if you're really into education or you're really into open
07:22
data, find it by cause and search for a project that you can contribute to and help that organization. OpenHatch has a lot of like little small bite-sized projects, so if you just want to do something really quickly and they have a lot of different languages that they support. GitRec, you put in your GitHub username and it will suggest repos to you based on the work you've already
07:41
done and your existing profile. That's super cool. 24 pull requests, it's like Advent but not chocolate, so you write code and you do submit a pull request every day for 24 days in December leading up to Christmas, make some presents for open source maintainers. Contribulator is kind of just the project's part of 24 pull requests and Code Triage looks for really really
08:03
bad off repos on GitHub and then they suggest them to you. So if you really want to take on like a struggle project, do that. But also if you're if one of your professional goals is like, hey I want to work for X company, look for their open source projects because their developers are running their open source projects and then they'll be looking at your code.
08:23
Like who do you think they're gonna go to when they're trying to hire but somebody that they've already kind of worked with from a distance. So if there's a company that you really like, look to see if they do open source and try to contribute to some of their open source code. It also gives you a sense of their workflow, it gives you a sense of their team and their communications and their dynamics, so that's really helpful. And the last
08:42
thing is other developers. If you know other developers, they might have some suggestions, they might have projects they're working on like ReachOut, it's a one of your career goals or personal goals is networking, hey find somebody and help them out with their project. Okay. And then the next thing you want to think about is the task, the issue that you want to work on in
09:01
GitHub, its issues. And what you want to do here, depending on how you're feeling, right, you should probably make sure it hasn't been solved already. Sometimes they don't get closed until something gets incorporated, but I would check the pull requests as well and just make sure. And then if it hasn't been completed already, just comment on it to say that you're working on it, so that it doesn't get solved before you finish, right. If having it pull, if
09:25
having your code pulled in is really important to you, make sure that you comment and make it really clear that that's something that you're working on. And then know that that comment is a commitment, right, to push that task forward in whatever small way you can. So if you work on it for, you
09:42
know, a couple hours, you don't get through it, and then you don't ever comment again saying like, oh, okay, I didn't get to this, someone else can take it on. Well, now it's just not going to get done. So consider your comment some sort of a commitment. If you don't solve the issue, you can always take the research that you've done and the things that you've learned and comment
10:02
on the issue again with that information and say, I wasn't able to get through this, but happy to pass it on to someone else. That's helpful. That's a step forward, right. So stop thinking that you're going to, like, solve everything or fix a full feature and think about the small steps you can take to impact a project and to help a maintainer. And know that as somebody
10:23
who maintains an open source project, any contribution you make is helpful to me. As long as, like, you're in a good spirit about it, you're in a, like, a learning space, right, anything that you do is helpful. Adding a comment, doing some research, that's work that I don't have to do or that someone on my team doesn't have to do. Like, we're hungry for it, so don't, again, like,
10:44
don't be afraid to reach out and kind of put something out there. Just also don't be, like, really aggressive about it, right. So if you have a feature idea and then you're like, hey, it's been a week, where's the feature, that's not going to be very helpful and it's not going to win you good graces, okay. All right. Another thing to think about before you start working is the
11:04
community. So make sure that you know because you're probably going to need help. There are probably going to be people on the team that know more about the code base than you do person just forking it for the first time. And so what you're going to want to do is make sure that you know where that community is. Maybe it's a Slack channel, maybe it's a HipChat
11:21
community, maybe it's a forum somewhere, maybe it's just an email for one guy, right. Find out what that community is and be aware of it. And also try to get a sense of what the community is like before you get started. That might also be a part of your decision factor. So for me it was really important to have a community that would be responsive, that would be, it would be
11:42
very kind because I was kind of in a place of like, oh I don't know what I'm doing, but I'm scared. And so it's good to know what that community is like before you hop in. I would also say that you might want to talk to other coders you know to look for a good community, okay. Another part of the
12:02
community is like that level of responsiveness. So maybe looking at closed pull requests and seeing how long it took, how long that process took, and that'll help you set your expectations. Okay, so you will want to contact the community when it comes to any big changes that you want to make, changing a big library, making a new version of it, adding a brand new
12:26
feature that hasn't been discussed and isn't listed as an issue. Those are things you might want to reach out for first. If again, if it's important to you to have your code pulled in to the to the code base, but depending on your goals and depending on what you need, like don't wait for permission either.
12:43
People are busy, open source maintainers often are not working full time on that project, so don't wait for permission, but do check in. So I'm gonna get into the the technical bits of this now, and since most people here seem pretty good with Git and GitHub and there's no way that I could possibly teach Git in the time that we have right now, we're gonna kind of
13:05
speed through. So the first thing you want to do on GitHub, fork the project, right, and this is just a workflow. I know that not everyone uses the same GitHub workflow, this is just a solid one that you can use, and I would recommend a lot of times in the project itself, in the documentation,
13:22
there's information about how to best go about contributing to the project. So this is a workflow that works, this is the workflow that I use, but it's not necessarily the workflow that's best for the project that you are working on. Again, so starting off, fork the project and create a version in your
13:41
own GitHub account, so that's on GitHub, and then you're going to want to clone your version of the of the project, your fork, down to your local computer. All right, and know that installing the project, so going through the steps that are listed in the documentation, or with Rails, like a lot of us are pretty familiar with how to set up a Rails project, so maybe there is no documentation, maybe you've taken that risk, which, power to you, and you
14:05
decided, like, I know how a Rails project works, I'm gonna just set this up and make some contributions, and there's no documentation, which should be your first pull request, but just know that, like, you can look at the readme.md file or the contributing.md file, those are pretty standard, find
14:20
the documentation, the wiki, the community, whatever it is, and go through the steps that are listed there. Know that this is the worst part of open source contributing, the installation process is the worst part, so if you are feeling like, I'm the only person who's ever come across this error, and now I will
14:43
never be able to achieve my needs with regards to open source, don't, it's normal to struggle, it's normal to have errors, the likelihood is that the person who created the project or the team that's working on the project has it set up and has had no problems, so if you hit an error or a bug, that's really
15:01
important information for that person to know, or for that team to know, because they might not know that it's, that other people are hitting this snag and a lot of people are hitting it and just walking away, and that's people who could be contributing, could be coding, who aren't, so what you want to do is know that you're gonna struggle, push through the struggle, write down the errors that you get, make issues for anything that comes up that you, that's
15:26
broken, and if you can fix it, write down the solution, right, make a pull request to the documentation that adds information that was missing before, and then the last thing is if you fail, if you're not able to get it installed, those issues are still a way to move that project forward and just
15:44
move on to your next best choice, right, it'll be okay and maybe they'll fix it and maybe it'll come back, so do your installation, get through it, don't get discouraged, and then what you want to do is celebrate, right, make it rain, okay, so you did it, that's a really big deal, so if you get a project installed,
16:02
like, that's a big deal, celebrate it, take a minute, right, tweet about it, awesome, okay, so these are the six GitHub commands that you'll want to know for the workflow of, like, this is not my code base, right, of moving past
16:20
the Twitter clone that only exists on your computer to someone else's code base up in the cloud, so you're going to want to set a remote, which means that you want to make sure that the headquarters version, the, like, official version is linked to your code as well, so set a remote of, like, upstream, root, headquarters, banana, whatever you like, that is focused on, that is linked to
16:45
that headquarters version of the code, alright, and then as you're coding, make a branch, name the branch something relevant to the code you're writing, so don't work on master is the takeaway, name the branch something, write some
17:03
code, commit, and then push back up to your fork, which should be called origin naturally and originally, and maybe you changed it, and, and then make the, make the pull request through github.com, and this is a GitHub workflow, obviously, okay, and then the last part, this pull and rebase is going to be
17:25
something you want to do as you continue to work on a project, so we've already discussed how the install process sucks, so if you have a good project and a good community, and you've got it installed, like, write more code, get connected, that helps you build that relationship, right, so pull down
17:43
from the upstream to your master, and make sure that your master, that you're always branching off of your master to make new code changes, and that your master is always up to date with headquarters, and then rebase is what you'll use if, like, let's say you worked on something for a long time, so it's been four weeks, and maybe that code base, that original code base has
18:01
changed, so you'll want to rebase against that original code base, and I'm saying all this just to say that you should know these six commands, and how to use them, and if you don't, like, this is the, this is the process that you'll take as you work on a code base that's not your own, or
18:20
something that you're more closely tied to. All right, so the next step is to code, just this is a good, that way, do it that way, and just understand as you're working, and as you're working, maybe you've picked a task that's a little bit beyond you, maybe you picked a task that requires you to, I'm gonna pause, that's a lot, maybe you picked a task that is a little bit
18:44
something new, right, that you have to research, that it's gonna take you a long time, so just make sure that you're maintaining your motivation, and that you don't give up, because that's a waste of your time, right, so push through, and see it as a learning experience, not as, like, an obligation, or you know, I made this commitment, and I need to write this code, see it as, like,
19:03
okay, I'm gonna learn something from this, some way or another, and that really changes the way that you think about it. Find someone to hold you accountable, another developer, if you get stuck, find someone to pair with, do your research before you reach out to the community for help, so go into the
19:21
community with the sense of, like, okay, one, two, three things that I tried that didn't work, can anyone help me, right, and that's just, like, basic developer courtesy, is do some work before you ask for help, and have some responses when people start to ask you questions, and then just know that, like, like I
19:43
said, everything that you do is some amount of progress, okay, so your pull request, you've written the code, you pushed it up, you clicked the little button to make the pull request on GitHub, awesome, now in your pull request,
20:00
please don't just make a pull request and submit an empty pull request, this is not helpful to anyone, please list the the changes that you've made in detail, if you made a front-end change of any sort, even if it doesn't, even if there's no difference, make a before and after screenshot, especially if you've made a front-end change, like, CSS changes are not, don't
20:21
mean anything to the eyes of the developer, and there's no reading the mind in terms of, like, what what you changed and what you made different, so screenshots are really helpful, if you made something and it's, like, a little weak, or it created a different bug, write that in the pull request, right, that's okay, if you have ideas for future improvements, or, you know, it's, like,
20:44
half done, maybe not half done, but at a good stopping place, but there's still some work to be done, make some lists of, like, do the to-do list of, here's some new tasks, here's some things that you might want to add to this later, here's a feature that might be great to depend on this, and put that in there,
21:03
and then maybe make issues for them, and just don't do too much at once, so sometimes you'll start working on the code, and then you'll be like, actually we should refactor all of this CSS to better fit the needs of the other front-end developers, well that's a different pull request, that's not related to the task that you've chosen, right, or you start to change syntax, or
21:21
you start to move things around, do that separately, keep things very agile, right, different, each pull request should change a very specific thing, because that allows the maintainer to say, okay, you did this one thing really well, as opposed to saying, like, well you did this one thing really well, but then you did this other thing, and I don't need that, and now I can't really separate out which one I need, and which one I don't, so be really clear
21:43
about what you've done, and make sure that it's a very boxed off thing, right, I've fixed this issue, it's one pull request, one change, the other thing that that's important with pull requests, that was important for me, because I was in a learning place, and I wanted people to review my code, was
22:01
was saying specifically, like, I'm open to feedback, that's really important, and that says a lot to other developers, right, so I would say in the pull request, because sometimes it can be a little touchy, you want people to contribute to your code base, so you don't necessarily want to call them out, and I mean, I don't want to call people out in rude ways, and I don't
22:21
want to hurt people's feelings, so if you say really specifically, like, hey I'm really open to feedback about this, I can see that there are some places that are weak, like, please let me know whether something is working or not, as opposed to just, you know, the opposite, or the other option is, like, just ignoring the pull request, right, no, let me know, and I'll fix it, I'm here to fix it, this is not just a one-time drive-by, right, so make sure that you're, it's
22:44
really clear that you are open to feedback, and constructive feedback, make changes if they're requested of you, and this is more about, again, building that relationship, and then, like I said, do your own research, fix things when you can, make sure, clarify things if you have to, and take it as a learning
23:05
experience, great, okay, so the last thing is taking all of this work that you've done, and how do you make it work for you, whether it's been pulled into the code base or not, right, so we're gonna be patient, we're gonna wait
23:21
for people to work through, and we're gonna wait for people to get to the code, and to respond to you, but ultimately the code that you've written is code that you've written, it's yours, and it exists out in the public realm, unlike a lot of code that you may write for your employer, so, so what I would say is that each pull request is a problem that you've solved, it might be a little problem, and it might be a big problem, but it's
23:43
a problem that you solved, so especially if you get to a place where you are writing bigger things, or fixing bigger problems, it becomes like its own little bubble that you can take to interviews, and use for people to see, like, this is the code that I write, this is how I write code, this is how I solve
24:01
problems, these are why I made some of these changes, this is where I got hung up, it's a story in and of itself that you can use in an interview with a potential employer, at a meetup, what have you, I actually, when I was leaving the nonprofit world, I went on to become a teacher assistant at Dev Boot Camp,
24:20
and I got hired because I walked through one of my open source code pull requests, and kind of talked about all the changes I'd made, and the things that I needed to learn in order to be able to make them, and why I'd done certain things, right, so a pull request is its own little bullet point, like, make a blog post about something that you, a pull request have you done, tweet about it, add it to your resume if it's substantial enough, like, you can focus
24:43
on this code that you, it's work, it's work that you've done. Similarly, the people that review that code, that work that you've done, can become references if you play your cards right, right, so all those people that are reviewing your code, commenting on your pull requests, the maintainers like myself, you know, if
25:02
you are building a relationship, if you are using enough emojis in your pull requests, use emojis in your pull requests, it's awesome, confetti ball is a great one, tada is awesome, clap is good, do it, do it, do it, but, you know, get your personality across through the communication means that you can, follow them on Twitter, chit chat with them, like, be active in
25:22
the community, be, be hype about their projects, you know, and that's a good way to build connections, and I don't mean in like a smarmy way, right, if you like the contributor, if you don't, then, you know, whatever, here's some code, bye, but you can build those relationships over time, and get to a place where, where now
25:40
you have references in the community that maybe you wouldn't have otherwise, and those references know your code, it's not like you met at a meet up and exchanged business cards, it's not like they're really into your Twitter stream, they know your code, they know the work that you do, so that's pretty awesome, if you add value to a project over time, you can also become like a co-maintainer, you can get like a higher level of, of
26:02
responsibility, this might not translate into anything like on the internet, but it will translate into something like being able to commit directly to the code base potentially, or being able to review other people's code, or being given responsibilities, and again furthering that relationship that you have with people that you're writing code for, and then I would say make sure
26:27
that you're tracking all the work that you do, so if you're writing issues about bugs, and you're writing like these expansive kind of examinations of a bug, well that's QA, it is, if you are doing code reviews on other people's
26:40
pull requests, like that's some lead developer level stuff, you know, if you are, yeah, if you're, and if you're writing code like you're a developer, even if you're changing careers, or you're from a different background, and I just think that like make sure that all the work that you're doing, know that that's work that you've done, it exists, it's, it's there in the world,
27:01
whether somebody acknowledges it, whether you get that pull request merged in, or not, so build relationships, work with the same project over time, can be really awesome, and the last thing is like, as with all things, your relationships with other people matter, be kind in the community that you're in, if the community itself isn't kind, find another community, it's not worth it,
27:22
you know, work over time to make sure that people get to know you, take advantage of opportunities, if you want to, and if you can, one of the best things for me about the open source projects were that I didn't have to come up with the idea, somebody else had come up with the idea, I'm terrible at
27:41
the idea part, and at like taking something from scratch, but being able to just pick up a problem in a larger, in a larger pool, and with more meaning, was really nice, so it's a great opportunity to work together, and to collaborate, and you should build those relationships to take advantage of it, so be kind to yourself, write open source code, worse comes to worse, like I said, code montage
28:03
is open source, so if you wanted to submit a board with a good montage, that would be awesome, and so that's it, thank you guys very much.