Earlier this Spring, Community Classrooms Founder Kunal Kushwala spoke with Sema Founder and CEO Matt Van Itallie about how working with Open Source projects can advance one’s career.
Community Classroom believes that every student, irrespective of their college or branch, can make it big. Community Classroom is an initiative built on this thought. The organization, founded by Kunal Kushwaha, provides free hands-on training, and mentorship in an inclusive community.
Topics covered:
- The “What” and the “Why” of Open Source
- Benefits to Students of Open Source
- How Students can get started with Open Source
- Making the Most of Your Time as a Contributor
- Becoming a Maintainer
- Picking a Tech Stack
- Learning in Public
- Remote Work
- Balancing Open Source commitments and your other responsibilities
- What are the best kinds of Open Source contributions
This conversation has been edited for clarity, context, and annotations.
Introduction
Kunal: Welcome, everyone, thanks a lot for joining today. Today, we’re talking about utilizing Open Source for career advancement. But before we get started with the agenda, would you like to specify to the viewers a little bit more about yourself?
Matt: Sure. And thanks again everyone for listening, really looking forward to speaking with you and answering your questions.
I was born in New York State, and I now live in Baltimore, Maryland, near Washington, DC. I learned to code quite some time ago in Turtle Basic, on one of the first personal computers, a Commodore 64, but then I moved professionally to the business side of technology. While working with software companies I fell in love with code quality and helping developers advance their careers by improving their craft, the craft of coding. I saw how much better code quality could be, and also that most organizations didn’t do a great job of helping engineers get better, learn more, and become more effective.
And so I started a business called Sema. We build tools to help teams and individual coders improve code and improve their skills.
And along the way in my career, I’ve become passionate about career planning and career choices. I have switched jobs, have hired hundreds of people, I have reviewed thousands of resumes. I have made good choices in my career, and I’ve made bad choices. And I really like doing my best to help me help people make the best choices they can.
Kunal: Thanks a lot for sharing. Now let’s get into the question at hand. From your perspective, what does Open Source mean to you? And why is it important?
The “What” and the “Why” of Open Source
Matt: Sure. Open Source code is code that’s available in a version control system such as GitHub. Anyone can copy it, and can make potential changes. I say “potential” — if you’re using the master version of the code changes have to be approved, typically by a Maintainer. Besides copying and suggesting changes to the code you can also use it freely… usually. We’ll come back and talk about that part later.
If you’re using Open Source code, we really think you have an obligation to contribute one way or the other, even when you could use it for free.
Let’s talk about the community around an Open Source project. Sometimes you hear folks talking about “Contributors” and “Maintainers.” Think of Maintainers as the leadership of an Open Source project. They set the project standards and serve as the welcoming committee. They also do some of the code reviews, but not necessarily all of them. Contributors are people who might suggest an issue on an Open Source project, solve an issue, participate in, participate in code reviews.
So why should you care about Open Source?
First off, Open Source is one of the coolest community projects on Earth,
Millions of people around the world have worked together, most of them have never met each other in person to build code on almost any topic. NASA has over 400 Open Source repositories, covering almost every software language, for weather, for space and other amazing applications. If there’s any topic you care about, I’ll bet you there is an Open Source project. If I’m wrong let me know and I’ll send you some Sema swag.
The second reason is it’s really useful to other applications and organizations. About 96% of all software uses Open Source software as a part of it. So it’s really in everything.
[Note, for a deeper discussion of the basics of Open Source, read a piece with @eddiejaoude of EddieHub, the inclusive Open Source community. It covers the basics of Open Source and other tips and tricks for Contributors and Maintainers. Learning with the EddieHub Community: Mentoring and Supporting in Tech, and Contributing to Open Source]
The third reason is, it’s really useful for individuals. As we’re about to talk about, there are many benefits for getting involved in Open Source to advance your career.
Kunal: Thanks. Folks often think that Open Source always means free. That may always not be the case — there are companies who are earning millions and millions of revenue via Open Source projects. Thanks for the explanation.
Benefits to Students of Open Source
Kunal: You talked about the personal benefits, let’s talk more about that. A lot of students are here- can you explain how it can benefit students to contribute to Open Source?
Matt: Absolutely. And all kudos to you, Kunal, for sharing many of these ideas while we were preparing for this.
There are five reasons I would give: skilling up, mentorship, resume building, networking, and learning about yourself.
In terms of skilling up, by writing code and by doing code reviews, on an Open Source project, you are improving your engineering skill. When people are reviewing your code, or you are reviewing someone else’s code, that is an amazing learning moment. That’s one of the reasons I’m obsessed with code reviews.
As for mentorship, reviewers can be giants in the field or the codebase– you can be learning from really smart people. And so it’s a great way to learn more in terms of mentorship– of course, it depends on what community you join. And it depends on how much work you do as a Contributor. But when you do it right, you meet people who become mentors to you whether formally or informally.
Third, building your resume. Some of you might be in university, where the courses on learning to code are lecture-only. It’s really important when you’re going on the job market to actually practice coding, and especially practice coding in teams, and giving and receiving code reviews. Code reviews are fundamental in the workplace– almost every organization uses them. And so to actually have real experience coding, getting code reviewed, and reviewing code is really important. is really important for your resume.
In terms of networking: working in Open Source can directly lead to jobs or indirectly lead to people who could help you with jobs or your career. Some Open Source projects are totally free community projects. But other times, there are companies built around the project. Red Hat, for example, was the first company based on Open Source that reached more than $1 Billion dollars in yearly sales, it was later sold to IBM for $34 Billion.
I can’t stress enough if you want to network or job hunt through Open Source the first step is to be a really good Contributor. Serve first before trying to advance yourself, that’s the most important part. In any field, people can smell from a mile away, that you’re, you’re just trying to network rather than being useful. [Editor’s note: “smell from a mile away” is an English expression indicating something obvious. ;0]
And then the fifth benefit is learning about yourself. This topic could be a whole other conversation about intentionally planning your career. But overall, every opportunity, whether it’s classes, it’s an extracurricular, it’s an activity like Open Source, every one of those moments is a chance for you to learn more about who you are, and what you like, and what makes you happy at work and in life.
In that way, Open Source is sort of like a club/ extracurricular, but it’s one that just happens to be one you might want to do professionally.
Kunal: I like the last point about exploring yourself. When it comes to exploring tech stacks, often times when folks are just starting out, there’s so many things to do– so many options and roadmaps. Open Source is a great way to see what tech stack interests you. So if you would want to work on a big scale project in development, mobile development of machine learning, or DevOps, or whatever, Open Source. Is a great way to test out your skills as well in various domains and see what you like.
Matt: Very well said.
How Students can get started with Open Source
Kunal: Now let’s talk about how to get started. If I’m an absolute beginner, what is the roadmap you might suggest?
Matt: I see there was a question about creating your own Open Source project, how can you do it? The answer is you can just go to GitHub or another version control system, and make the project public, and then invite others.
If you are starting out with Open Source AND you have a team of fellow students working with you, that’s an ok way to start. Just make sure you’re doing it in a team together because you want the huge benefits of doing something more than a solo project.
But more likely a better path would be to start by joining an existing community.
The first step to getting started is to find an Open Source community that’s a good fit. One way to do that is ask everyone you know if they’re a member of an Open Source community that’s open to newcomers. That’s more important than anything else about the topic or tech stack, besides being in a language that you’re going to be able to be useful to.
Most important for your first Open Source project is it be a good experience, and you get practice at being a good Contributor and a good community member.
I’m sure many of you have suggestions of great Open Source communities — shout out obviously to @eddiejaoude of EddieHub, the inclusive Open Source community.
There’s a lesson from the fairy tale Goldilocks and the Three Bears– you want to find the “just right” community to get started.
There are giant Open Source projects like the frameworks that Meta has created. You don’t want to start with projects like that. It’s too big. You want to make sure you’re contributing usefully. And for early tenure folks it’s unlikely you’re going to be helpful.
Similarly if the project is too small– if there’s very few commits or code reviews, or there’s only one person as the Maintainer, it’s probably not the right place either.
Instead, you want one that’s “just right,” I think it was Mama Bear. [Editor’s note: I was wrong, it was Baby Bear! ¯\_(ツ)_/¯ ]
Second, once you find a potential project, you should just watch the project for at least a week. Turn on notifications, see what pull requests are happening, see what issues are created, see how people are talking to each other.
And read all of the documentation like readme files. If you don’t understand it, it’s probably a sign that it’s not aimed for someone at your level, or they may not be great at welcoming new people.
The other reason to read the documentation is if you end up participating, there’s nothing more annoying to a Maintainer than people asking questions that are answered in the documentation.
And by the way — if you read the documentation it’s good, compliment the Maintainer. Maintainers get a lot of grief and they don’t get enough compliments.
If you’re about to try joining a community, maybe pick two or three projects, and watch them all for a week, and decide which one feels the most right before you start contributing.
Kunal: Definitely, Matt. There’s no one path to Open Source.
You may find a project that your friend may be working on.
You can also check out the Explore page on GitHub which can suggest Open Source projects. I recommend this because you can filter out projects according to languages.
Or you can go to an organization’s website and see if there’s a program encouraging students to contribute to Open Source, like Google’s.
Making the Most of your Time as a Contributor
Kunal: can you talk to us a little bit more about how we can make the most out of being a Contributor as someone who is just getting started? And what about folks who are already active in Open Source and are becoming good Contributors?
Matt: Sure. So let’s talk first about being a Contributor, where you are giving back to one or more Open Source projects. And then we’ll talk about the second part of connecting with Open Source companies.
I have five suggestions for being a Contributor:
Number one, focus.
Number two, be considerate.
Number three, be useful.
Number four, small pull requests if you’re coding.
And number five, remember that it’s not just about coding in ways to be helpful.
The first is focus. It is way, way better for your learning, for your resume, for your everything if you do a smaller number of things well, then a large number of things not well. That is true in all areas of career planning and growth, but it’s particularly true in Open Source. Unless you have a lot of time, pick one Project and give all of your time to that. I would really do an awesome job helping on one before you start trying to help on two.
I see an audience comment coming in that it’s easy to get overwhelmed with all of the opportunities. I totally agree. But focus on doing a small number of things really, really well.
Second, be kind and thoughtful. Some Maintainers are paid, some of them are not. All of them should be treated with incredible respect and appreciation. Because they are doing something for you. They are doing something for the world.
So I’d like to say Don’t write anything to a Maintainer that you wouldn’t say to your Mom. I suspect you would not say to your Mom, “why haven’t you finished cooking dinner yet?” [Editor’s note: Dads cook too, like me! I was thinking back to my childhood when I said this. Love you Mom!]. There’s people who talk to Maintainers like that: “why haven’t you finished making another video? Why haven’t you reviewed my pull request yet?”
Don’t don’t talk like that. Disrespect is a quick way to burn trust, and it’s just not the right way to behave.
Third is being useful. There are few things more frustrating to an Open Source community than just doing work for work’s sake.
One example, commenting on an already closed pull request. It is super annoying, because it just gives the Maintainer one more notification, and it doesn’t do any real work. Imagine what you would say to the Maintainer if you were talking to them: “Hey, you know what I just did, I commented on a closed pull request, I did that because, well, there’s not really a reason, I just want to have an activity square on GitHub.” That is not worth it!
If you can’t be useful, be silent, until you can find a way to be useful.
Number four is small pull requests. Also true in general, not just Open Source. If you are making changes to the code, create small and discrete pull requests to make it easy for the reviewer to review. My rule of thumb is, a good outcome from a PR is the reviewer only has to make 1–4 comments on it. If they are making more than four comments, it’s likely that the pull request was too large. So watch the comments coming back on your PRs, and if it’s more than four make the PR smaller next time.
Kunal: I could not agree more about the larger PRs point. Remember folks who contribute to Open Source are also volunteering. And sometimes it may be possible that your PR is open for months and months. So you just have to be patient. And, one of the best ways to speed up that process is making it easy for the reviewer by reducing the size and breaking it down into smaller PRs, individual PRs and stuff. Awesome.
The fifth point is helping a Community is not just about the code. If you’re looking for engineering jobs, definitely you want to find a way to contribute code. But there are other ways too, like answering questions. Maintainers are so busy. If you see other people asking questions, and sending them to the documentation of where those questions and answering them, takes a weight off of the Maintainer’s shoulders. Also, some communities need help translating documentation from one language to another.
Kunal: Great. How about the other point about finding companies that do Open Source?
Matt: So one question might be, should I do that? Is it a good strategy to go try to find a job by contributing to an Open Source community at a company like Red Hat?
It might be, but first and foremost, you want to be a good Open Source Contributor.
So almost certainly I would not start at one of those because first you want to find your feet [Editor’s note: another idiomatic expression! ]. Learn some lessons first in an organization other than one of those companies.
Once you are ready to make that step, it’s a great idea. Because working on a company’s Open Source project is basically like having an internship without actually even going through a hiring process. There’s not a hundred or thousands of people applying, talking to a recruiter, you can just show up and start. Again, be a really good Contributor, before trying to inquire about a job.
Here’s a list of 1,646 Open Source companies on Crunchbase. You can also see that they have raised almost $17 Billion dollars, which tells you about the strength of their prospects.
I can’t stress enough that when you do that you need to put your best foot forward. Imagine this conversation with an employee of the company once you’ve been contributing– this is how you want that conversation to go:
“Hey, Kunal, I’m Matt, I’m a university student, and I love JavaScript. I watched your project’s community for a week, I saw that there was a need to start answering questions. So I just started answering them based on the FAQs that you guys already put out.
“Then in my fourth week, once I got the hang of it, then I started taking issues. And I asked a person for feedback on my pull requests. And the first time I did it, he said I had, it was way too big. So I broke the PR up the next time.
“And I’m really pleased to say that now I have 20 successful PRs six months later.
“I’m just a huge fan of your company. I’d love to meet you. Could we talk for a few minutes?”
That would be an amazing conversation to be able to have, and it’s possible to do it.
Now this doesn’t work with all companies. You certainly can’t get a job at a place like Google skipping the interviewing process by doing Open Source. But you might be able to do it at smaller or midsize companies.
Kunal: Awesome. I loved your last point that you mentioned about big tech companies, contributing to those projects is relatively difficult because they may not show much interest to newcomers. I know a few people who got hired at like Google and Facebook, just by Open Source contributions, so it’s possible, but you have to be really, really good at yours. But this approach is definitely a great way at smaller companies to showcase your skills.
Becoming a Maintainer
Kunal: Let’s talk a little bit more about being a Maintainer. How do I transition from being a mentee / Contributor to a Maintainer?
Matt: For promotions and advancement, the best way to get an advancement is to do the job you want in advance. And that’s definitely true in the Open Source world.
So once you have figured out how to be a great Contributor, start watching what Maintainers do, and start doing that too. Take on more and more code reviews, answer people’s questions, and welcome people to the community.
A side note– answering peoples’ questions could include this answer. “This was already answered in our FAQ, look here…” You don’t have to literally give everyone a one-to-one answer, because part of your job as a Maintainer is encouraging people to find it for themselves.
Once you start doing pull requests, I would definitely get some feedback from an official Maintainer, to make sure that you’re doing it the right way and to see if they have feedback on your reviews.
Then, after you’ve spent some time reviewing and carrying out these tasks, then would be a good time to go and ask one of the official Maintainers: I would like to sign myself up for becoming an official Maintainer of this group.
Some tips on being a good Maintainer:
One you absolutely, positively, must meet your time commitments. Here’s a sample conversation if I were asking Kunal to be a Maintainer: “Kunal, I’m such a fan of Community Classroom, what you’ve built is amazing. What I can do is, 15–20 minutes of answering Discord questions, 5–7 days a week, almost every day, but not always every day. And I will do at least two hours of live sessions with the community every month.”
If I say that, I absolutely must meet that standard. Being an Open Source Maintainer is hard– you are trying to figure how to make the project work with all of these volunteers. You must be reliable. It is much better to underpromise and overdeliver.
Two, as a Maintainer, I would also spend careful attention on the documentation. Because documentation can never be good enough to help make it easier for new people.
Three, being kind back to Contributors. If someone asks you an obvious question that’s answered by an FAQ, if it’s the first question in the FAQ, you can still reply: “Thank you so much, I really recommend that you go to FAQs, and you can find it right here, and here’s the link.”
It takes almost no extra time to be polite. And not only is that person watching, but everybody else in the Community is, too.
Kunal: Thanks for sharing that. And also giving and receiving feedback is very, very important for Maintainers.
Picking a Tech Stack
Kunal: Let’s answer some questions. One question is about picking a tech stack to use in Open Source. As we mentioned previously, there is an Open Source community for basically everything you work on.
Matt: Early in your career, you just want to get good at something or several things. So if you’re working on a language already, and you like it, just keep going with it, and get as deep as you can. Any language or framework. Because one of the things you’re learning to do is learning how to learn. And it is you will learn a lot more going deep in language x, then being “light” in languages x and y and z.
And to be honest- even if you don’t like the language you’re currently the best at, I’d rather you start with a community in that language Because your first project should be all about learning to be a good Contributor. And the more something and the more language knowledge you have, the more useful you can be. Once you do that, then later you can start learning a new tech stack by contributing elsewhere.
Kunal: I agree with your point.
One more important thing to keep in mind is you have to have an open mind. Because when it comes to Open Source projects, it’s likely you are going to have to learn about more than one thing. Most web development tech stack also require learning something else, like CI/CD tools, how projects are deployed, how releases are created.
So even if you are working with a tech stack you know, you will be learning new skills and tools too.
Learning in Public
Kunal: There’s another question — can you talk a little bit more about how we can learn in public?
Matt: First let me answer, what it is, then why does it matter.
I actually didn’t really understand “Learning in public” until I started contributing a few months ago. So you can learn from my lack of knowledge.
Learning in public means, with very, very, very few exceptions in the Open Source world, ask your question on a channel, or to a group or in a public place, don’t send a private message.
One reason is, the person you might send the private message to is so freaking busy. They may not have time to answer. You’re giving a Maintainer one more thing to do.
Whereas if you add it to a general channel, someone else can jump in and answer it. And by the way, you’re letting someone else feel useful– because especially if you’re a new Contributor, but you can answer a question from somebody else, it feels great.
You might be thinking, oh, but this is a stupid question. I’m afraid of looking foolish.
As a Community leader, if you’re asking me a thing, if you’re asking it, then other people are almost certainly gonna be asking it too.
And look — if you go to an Open Source community, and you ask a question in public, and they treat you poorly, you should quit. You’re a volunteer! There are plenty of places who are very happy to get help and treat people respectfully.
I totally get why you’d want to ask people individually first, I really didn’t understand. I think I wrote you privately, Kunal, when I first met you. I just had it wrong. Now I understand.
Remote Work
Kunal: Got it. Next question is about remote work. Folks are really interested in that. Your company offers remote work, right?
Matt: exactly right. At Sema, we have about 45 people who work in about 25 countries, including three in India. I’m in the United States, fewer than 20% of our employees are here. Our engineers are in Africa, Europe, North America, South America and Asia. We don’t have any in Antarctica at the moment, but maybe someday,
To give a quick big picture perspective: over the last decades multinational companies have learned to work with teams in other countries. But COVID accelerated things further. COVID required all tech-related companies to learn how to make remote work work for everyone, no exceptions.
And as a result, companies realized it was much, much more possible to have a globally distributed team.
Because if you’re not going to be going into the office, it doesn’t matter if you live a mile from a person or you live– Kunal do we live 20,000 miles apart? [Editor: I checked. 7500 miles.]
To give you an idea at how Sema hires, we only hire one of two ways. One is through referrals from people who work here who can vouch for someone they’ve already worked with or studied with. The other is we go through Contractor and Freelancer agencies, like Toptal, an amazing source of talent for mid and senior level Engineers, and Velotio, a fantastic team in India.
A couple notes to consider if you’re going to check them out:
One, early on in your career I would not do a freelancer site because you need mentorship and training. Instead look at a company or consultancy that is going to invest in training.
And two, read all of the instructions and guidance for the kinds of engineers they are looking to hire and what the requirements are.
I think the right way to think about remote opportunities is to start by going to the place where you are going to learn the most. Let’s say you work for a consultancy or company for a couple of years that’s not remote. While you are there, you probably can also be doing Open Source when you’re there [Editor’s note: but double check what your contract says, just to be safe]. Getting mentored well at the early stage in your career is critical. Then in a few years you’ll be in a stronger position to network into other organizations through Open Source and otherwise.
Kunal: Thanks for sharing that. And I love your point about what you mentioned about remote work. There are a lot of companies that hire globally. There are two types of remote work: within the country and globally. There are companies that hire globally and have the paperwork HR handled via other companies like Remote.
Balancing Open Source commitments and your other responsibilities
Kunal: another question– you mentioned you could do Open Source while you’re working. How would one balance that? How do you balance your job or your internship with Open Source contributions?
Matt: Really good question. We could do a whole session just on this.
First, do a very small number of things very, very, very well.
One reason is, employers like to see a track record of success. And the smaller number of things you do, the more likely you are to do any one of those really well. A second reason is what I said above — you’re going to learn more by getting deeply rather than lightly involved. And the third reason is, the fewer number of things you do, the more likely you are to do a really good job, AND the more likely you are to get good references.
For folks who are still in school, it absolutely starts with doing really well on your grades. Absolutely, positively. If you do not have a great grade point average, sit yourself down, write yourself a message. What are the reasons I don’t have a better grade point average? And what could I do to make that grade point average better?
If you’re working on the hardest degree at your uni, and you’re literally giving everything you can, and you’re gonna have an okay but not a great grade point average in a really hard major, that’s okay.
But in any other situation, it’s almost certain that you’re going to be able to by focusing more, and taking grades more seriously.
It is never too late to do this. Even if your grade point average has been so-so, so far. Because if you have so-so grades your first three years, and then a great job in your fourth year, then employers can see that maybe you didn’t really know what you were doing your first few years, but then you really got it together.
So grades always come first.
Similarly when you’re in a job or an internship, doing an awesome job in the eyes of your manager. You should be having check-ins with your manager, at least once a month, even if they don’t have a formal feedback process: “Tell me: am I meeting your expectations? Are there things I could do a better job to be a better employee?”
You want to awesomely maximize trying to be helpful and successful in the eyes of your manager, just like successful in the eyes of your university. Those are the most important things.
After grades and job/ internship, then you have to be honest, how much time are you honestly willing to give to work on other things. And then you have to pick carefully.
Take me for example. I am the Founder and CEO of a software company. There are 168 hours in the week… by the way, you know if someone’s really busy when they keep track of the total available hours … I protect time for family, exercise, sleep- I don’t give up sleep. And then I work about 90 hours a week, including about five hours per week being of service to communities that matter to me. I do not have time to contribute to another Open Source project beyond the volunteering that I do, because I would not do a good enough job on top of my time commitments.
So you have to be honest about what you are able to commit to Open Source, or anything else. Back to what I said earlier about being dependable — it’s honestly worse if you have a resume full of “contributions” where you did almost nothing. “Yeah, what did you do?” “Well, I made one code review comment.” That’s not nearly as good as just having an internship where you’ve nailed it, or an Open Source project where you really are contributing.
Realistically, I would aim for a minimum 50 hours commitment over 6 months. If you don’t think you can do that I probably wouldn’t do it.
Kunal, I had a lot to say about this! As I promised, you know, I was very passionate about career planning.
Kunal: I agree. I do a lot of things. And this is when I have realized the importance of saying no to a few things. Absolutely you must prioritize your tasks and your future.
What are the best kinds of Open Source contributions?
Matt: I see another question from the audience. What are the best kinds of Open Source Contributions?
The contributions that look the best are:
One, where you have learned,
Two, where you have worked hard,
Three, where your colleagues would say you have done a good job,
And preferably four, where you made a difference where something was better as a result.
If you spend 50 hours on a project on an Open Source project, you should be able to learn something about not just being a Contributor, but also about that codebase and also your coding skills. Of course you’re going to behave in the right way that your colleagues think you were useful. And hopefully the project is then better as a result. But that last one is actually less important early in your career. What matters more early in your career is your contribution.
Kunal: Amazing, thanks for sharing that. And we are right about time, as well. So we’re gonna wrap this one up. Matt, any closing remarks?
Matt: this has been wonderful. Kunal, as I said, I made a commitment to you. Two hours a month of sessions like this, I’m at your disposal on career planning, resume building, giving and receiving feedback, obviously, code reviews, too. Kunal, I’m looking forward to being more of service.
Kunal: Thanks Matt, and thanks, everyone for joining and giving your time.
