Table of contents
Introduction
I recently had the great pleasure of attending two Twitter spaces led by the EddieHub community about Open Source and mentoring and supporting colleagues in technology.
EddieHub is the inclusive Open Source community on GitHub, Twitter, and Discord that is extremely welcoming and inclusive for folks who are interested in joining tech, regardless of their background.
It is led by @eddiejaoude but I know he would be quick to thank all of the maintainers, contributors, and participants in EddieHub who make it all possible.
Pro tip: Follow Eddie for tips and examples on leading the digital nomad life, or at least to be jealous of their amazing photos from Bali. ;0
Hundreds of attendees joined two different sessions to discuss questions about contributing to and maintaining Open Source code/communities and giving and receiving support and mentorship.
Panelists included: Emma, Naomi, Lou, Tanya, Mikhal, plus a cameo from Danny– some of the kindest and wisest people you’ll meet. Participants are too numerous to mention.
Each topic could be its own book, much less its own blog post! Nonetheless, I thought there were interesting commonalities worth combining the highlights from both talks– especially since EddieHub sits at the intersection of inclusion and Open Source.
How this piece is organized
Part 1 talks about the benefits of providing mentorship and support to others in tech. Supporting others through Open Source is one method, but there are many others.
Part 2 provides some background on Open Source projects, trends, and terminology.
Part 3 shares seven tips from Open Source Maintainers, who are responsible for organizing and curating Open Source projects and communities. This covers what Maintainers want you to know about being a contributor to Open Source.
Part 4 includes seven tips for Maintainers.
Part 5 is a brief conclusion.
Some quotes were lightly edited for clarity. Quotes are anonymous due to sporadic transcription ability… but you know who you are.
Part 1. Why Mentor and Support others in tech?
The energy and stories from participants about why they mentor and support others, and what they’ve taken from it, were incredible.
Many participants use Open Source as a way to provide that support but there were many other methods — sharing stories on social media, speaking at events, giving 1:1 talks or responding to messages, and more.
The benefits fall into six categories.
To give back like the people who came before them and lifted them up.
Coding is a craft, after all, and there was story after story of technologists who wanted to help others because so many people had helped them learn and grow.
For the thrill of helping others and watching them succeed.
Helping others feels awesome.
As one participant said: “It’s having that passion about helping others learn and wanting to see them improve and succeed, and continuously passing that ‘learning baton’ on to others. Because you don’t know what kind of influence that you might have to help them on their journey to become great.”
To learn more themselves.
Teaching and supporting frequently leads to more learning for the teacher too.
Another participant: “A great thing about Open Source projects is when you get new people who are new to tech or the industry or your project, they can give you a fresh perspective on your project. I love when new people say, ‘Hey, can you explain this project?’ And if the project isn’t understandable, then there’s nothing wrong with you, there’s something wrong with our project, and we need to improve it. By them asking questions, we can make improvements to it.”
Another participant: “Community is so important to me. Instead of learning from one or two people I want to learn from everyone. I want to learn from you and potentially pass on wisdom to you. To make for me, it’s always a two-way street, it’s never ‘here’s me giving you information.’”
To advance one’s career.
While there were many intellectual and emotional benefits to helping others, some practical benefits were mentioned too.
One participant shared how supporting others in tech has led to great job opportunities:
“There were students that have been trying to get a job for a long time, they ended up being so active in a Discord community that were seen by higher-ups at a company. Their work proved their technical abilities: if you’re in a Discord server answering questions, you’re debugging problems, you’ve proven yourself.
“You never know who’s watching, you never know what opportunities that could bring you.”
For surprising connections.
Several participants talked about making connections to people they never would have met. And both Twitter Space sessions, with a global audience and participants, are great examples.
Here’s my favorite story from the talks about making connections by helping others:
“The more and more you’re actually involved, whether it’s actually your own projects, or somebody else’s projects, the more experience you get, and those relationships naturally build up.
“Just to give a random bit of context on this: my wife is studying for a Ph.D. in a completely different area than mine, child psychology. The software she was using for tracking participants’ eye movements had some problems… so I wrote a couple of scripts to help out with this project and put them on GitHub.
“And I really didn’t actually think anything more about this of this, but randomly, I started actually getting stars and comments from people in China who were working on advertising technology that uses eye-tracking. Sometimes helping out, however random the assistance is, will actually open up connections.”
As a way to meet kind and caring people.
This was my favorite reason, though the panelists were too polite to say it about themselves.
The enthusiasm and sense of community among people who went out of their way to lift up and support others was magical. So by giving back to the tech community, you end up spending time with other people who want to contribute.
Imagine spending more time with people like this:
“For supporting people, my personal experience has come back tenfold. So many people have received little nuggets of advice from me, and I haven’t even realized that. And they’ve come back and said, ‘I took your advice. And now things are starting to change in a positive way. I’ve been in meetings before and someone’s messaged me on Slack or Discord and told me good news.’ So I’m like, ‘Oh my God, I’ve had an impact on their life. I can’t believe it.’”
Or:
“Supporting another developer’s success will literally never ruin your own success. By showing that you’re caring, you’re supporting them, you’re literally uplifting other developers of any other skill. I’m telling you, it makes a massive difference. genuine support is everything.”
Part 2. Basics of Open Source.
What is Open Source?
Note that this is a summarized definition of Open Source, intended for Beginner and Intermediate Audiences. For Advanced and Expert audiences we recommend you review the definitions at the Open Source Initiative.
Open Source code is code that is accessible to everyone, and (almost always) is created and maintained at least in part by members of the public.
“Accessible to everyone” means a viewer only needs to create a user account on a version control system like GitHub, Once they do that, they can see Open Source projects.
The opposite of Open Source code is private code. To access private code, not only do you need a version control system account, but you also need an invitation to that private repository (code is stored in repositories, one or more repositories make up an application).
“Created and maintained at least in part by members of the public” means that not only can viewers view the code, but they can also make suggested changes such as features or bug fixes, and can review others’ code.
The Maintainers of the Open Source project– the leadership of one or more repositories– set out guidelines for Contributors of the code on how to write, propose and review code. There are almost always fewer Maintainers than Contributors.
Again by contrast, private code relies on a private group to maintain the code. Typically these private groups are employees of companies, government agencies, or non-profit organizations.
Say more about what Open Source Maintainers do.
Open Source Maintainers are responsible for organizing Open Source projects.
This includes organizing the work of Contributors, including the processes for recommending improvements, adding proposed code, and approving that code. Maintainers can approve code (in GitHub, via reviewing pull requests), and Contributors can too, depending on the project’s guidelines.
But Maintainers do a lot more than that, too. To quote a few of the Maintainers who spoke:
“Being a Maintainer is not just about coding, it’s about finding issues that are really good, especially for first-time contributors to the repository. I try to sit down and go through the code and see if I can find good first issues on a fairly regular basis, so that I can help new people to get involved with our code.”
“Being a Maintainer often involves walking people through how to get started, or matching them to an issue.”
“I do a lot of code review as a Maintainer. I really like it because it helps me to learn how to code better as well, and helps me become a better communicator.”
Importantly, being a Maintainer can be more about working directly with the code:
“So, to me, being an Open Source Maintainer is very little about the code and very much about the community– creating a space where people feel encouraged to contribute, especially new contributors. It’s very important tome to lower the barrier to entry and create spaces where the community can support each other, you know, as a, as a maintainer.”
What are examples of Open Source?
A neat example of Open Source code comes from NASA.
Here’s the link to NASA’s Open Source code: https://github.com/nasa
NASA has published 413 Open Source projects, some of which are combined to create applications.
One of the applications is Cumulus, which is used to collect information about the Earth’s atmosphere.
Pro Tip: it is incredible what code is available for exploration via Open Source. Go take a look!
You can that Cumulus is actively under development — there are changes made within minutes of this screenshot.
From here you can dig in and see that one repository within Cumulus, also named Cumulus, has 2810 finalized or rejected changes (closed Pull Requests) and 10 changes that haven’t been accepted yet (open Pull Requests).
From here you could jump right in and start code reviews or tackling issues…
… but you shouldn’t.
It’s always, always a good idea to fully familiarize yourself first with the project, to be respectful of the hard work of the Maintainers and Contributors who came before you.
For example, you should always read the How to Contribute Guides first, like this one:
How big is Open Source?
It’s huge, and it’s growing every day.
One estimate is that there are 180,000 Open Source projects.
And Open Source code is incorporated into many other projects. One recent estimate found that 96% of all applications included some Open Source code.
GitHub estimates that 19% of code contributions went to Open Source projects:
Open Source contributors and maintainers can come from all walks of life and are around the globe. 80% of Open Source contributors in 2019 came from outside the US.
Employees at RedHat/IBM, Google, and Microsoft are among the major contributors from companies.
What about the actual number of Open Source contributors? Answers vary, it’s not as easy to tell as you might think, A 2019 study estimated there are 7 million developers who are not paid for their work– not all of them are working on Open Source projects, AND many developers who are compensated for coding are also working on Open Source. So let’s agree it’s a very big number.
Can anyone use Open Source code once it’s created?
Sort of.
It is technically possible to take any Open Source project and make a copy of it– that’s part of what it means to be Open Source.
If you want to learn and explore, it can make sense to make a copy of the repository and get to know it.
It is also technically possible to reference or use that Open Source code in another project, whether it’s Open Source or private.
Those are the technical answers.
However, there are also important legal– and in my view, ethical– considerations.
First, the legal ones.
All Open Source code comes with a license, which lays out how you are allowed to that code. Private code has licenses too.
These licenses vary substantially.
Some licenses are quite permissive– you can do whatever you want with the code.
Other licenses are commercial– you can only use the Open Source project if you pay for it.
Finally, some licenses have very particular requirements: if you use the code and share it, you are required to give away any code you create for free as well. This is called a “CopyLeft” license. Violations of CopyLeft can be a big deal for companies– such as lawsuits.
What does that mean for you?
First, know that there is no way to tell what kind of license it is just based on having access to it– you have to read the license.
Good news, if you are exploring the code to learn from it, there’s nothing to worry about.
If you are using the code personally– not just exploring it, but putting the code to work– then you need to read the license file. If it’s a commercial license, do the right thing and pay for it.
Pro tip: If you are at a company or organization that is using Open Source code, please check with your colleagues about setting up a proper approach to organize and vet the usage. Send your colleagues, or your company’s lawyer, this article. There is great software that can help.
Those are the legal issues. Let’s talk about the ethical issues.
Open Source code is only based on the community of millions of coders who make it possible.
Even if the license type is permissive, I believe all Open Source users, whether individuals or teams, have an obligation to give back to the communities who’ve created the code.
From my Scouting days there is an expression– leave a campfire better than you found it. This can apply to codebases generally, but it also applies to Open Source: if you use Open Source code, you should help make that Open Source code or other Open Source code better.
Thankfully there are many ways to give back to Open Source, and not just by coding.
- As an individual, become a Contributor or a Maintainer to the code
- As an individual, become a Contributor or a Maintainer for the community
- As an organization, donate to Open Source projects that your company uses
- As an organization, donate goods or services (such as your company’s software) to Open Source projects
OK, now that I’ve covered some of the basics, let’s turn back the discussion from the EddieHub sessions about Open Source.
Part 3. What do Open Source Maintainers want you to know about contributing to Open Source projects?
Here are seven tips from EddieHub Maintainers and Community members on how to be an effective Contributor to Open Source.
Focus
Pick a small number of Open Source communities to be a part of and make a real contribution. That’s way better than joining a lot of communities and not helping.
One Maintainer: “And remember everyone, while you can belong to multiple communities, I don’t recommend joining 100. I highly recommend joining two or three because you get different things from different communities. But don’t try and join 10 or 20, or 30, it just doesn’t work. It’s not beneficial to the community, and it’s not beneficial to yourself.”
Read the documentation
Maintainers are doing their best to build documentation to make it easier to be an effective Contributor from the start. A quick way to earn trust is to read that documentation before asking a question. Maintainers are so busy that it is much better for them to work on things that help the many, not the one– and documentation is a great example.
Pro tip: Particularly like the documentation? Say thank you to the Maintainer(s), and explain why. It is always the right time to give a specific, positive, compliment.
Learn in public
Learning in public means asking your questions to many people rather than one, privately.
The benefit for the Community is that your question might help other Contributors. And it saves time for the busy Maintainers, by letting them help many people at once.
Another Maintainer: “If you ask me a question, I’m going to have the same conversation with the next person. And so when you comment publicly, you’re literally helping those people as well. That’s why it’s so important to ask in public. It’s not just for you, but maybe 100 other individuals that are literally faced with the exact same problem. I guarantee you, if you’re having a problem, someone else has had the exact same problem. And by commenting about it publicly, you’re helping everyone.
“That’s why Stack Overflow exists. Do you think it exists for that one person’s problem that nobody else needs? No, we all find that same question to answer because we have the same problem. It’s the same exact concept here. Trust me on this.”
Pro tip: worried that your question might be too silly, or obvious, and you’re concerned how you might look? Ask it in public anyway and see what happens.
If members of this community are disrespectful, well, you have learned something valuable about their values– and it’s likely time to find a new community. I promise there are many great Open Source communities out there that would be thrilled to have your help and have you ask questions in public.
Pick a community that is welcoming to new Contributors
Some Communities are better set up for newcomers. If you are just getting started, it makes a lot more sense to start with a community that is prepared to help you have a great experience.
Of course, I highly recommend EddieHub as one such community.
Other ways to tell? Go to another community and just jump in and start approving pull requests and asking random questions.
OK… that was a test to see if you read the previous sections. Never do that. ;0
The other ways to tell if an Open Source community is set up for newcomers is to read the Documentation, to see how understandable they are, and the issue list, to see if stories are clearly indicated that they are suitable for newcomers. If you love the topic of the code but it’s not clear how you can help, start helping somewhere else and then come back when you are more ready.
There are many exceptions, but in general, I recommend the Goldilocks rule. Beginner-friendly projects are likely not too big (like React) or too small (with only one Maintainer and a few contributors), but have a “just right” level of Contributors and Maintainers.
Pro tip: I recommend watching a community for at least a week to understand the flow of contributions and conversations — after you’ve read all the documentation — before you try to contribute. You want to start off on the right foot.
If you are contributing code, create small pull requests
Each version control system (GitHub, GitLab, Bitbucket) uses different terminology for code reviews. For example, in GitHub, coders create a pull request once their code is ready for review. They may also identify one or more people to review the code, or a manager could select people to serve as code reviewers, or anyone can volunteer.
A code reviewer leaves feedback either for the pull request as a whole, or individually through comments. A single pull request can have 1–100+ code review comments but less is definitely more here.
It’s highly recommended to create pull requests small enough to only need 1–3 comments. This makes it easier for the Community and reduces the likelihood of blockers.
Another Maintainer: “As a maintainer, if you get a large pull request, is a lot of work. And larger pull requests do often get resulted in getting reviewed later, and maybe by fewer people. And that way, they end up with more conflicts, and it takes longer for them to get merged in.
“It’s really OK to think, ‘actually, I don’t have to add more lines to this pull request. If it’s two lines, but it adds value, then perfect. That can that can get merged in and then some other features and changes and fixes and improvements can all come in another pull request.”
Remember there are more ways to help than just coding or code reviewing
I know when I started getting involved in Open Source, I thought it was only about contributing code.
But then I realized it can be so much more than that.
Here are some Maintainers’ tips on ways you can help that aren’t coding:
“But I think the easiest way to support people is if you see a question on any platform, answer it. Or even if you can’t answer it, point the person to someone who can answer it.”
“Just being available to other people is a great way of supporting it can be answering questions, it could be pointing out resources, it could be connecting others to each other as the small way of supporting people.”
“Documentation is a great way to help. There’s so much documentation and it’s so helpful to get help with keeping it up to date. It’s even helpful to volunteer to translate documentation into multiple languages.”
Just make sure you are actually helping
There are many reasons you might choose to help with an Open Source community– for learning, for career advancement, to give back. Any of those reasons, and others, are good ones.
But you owe it to the community you are a part of to make sure your work is actually useful. Much better to make a smaller number of contributions that matter (see Focus, above) than spread yourself too thin.
And especially please avoid contributing for contributing’s sake– not only does it not help the community, but it can slow them down. And it doesn’t serve you well either.
Again, the Maintainer point of view: “One thing I’ll just caution people is don’t just try and make activity on your profile, because it creates a lot of noise for everyone else in the project and the maintainers. Writing “great” on everything, without even actually reviewing it, actually has a negative effect for your own GitHub profile, and the community as well. So just make sure what you’re doing is adding value.”
“Please don’t go approve a pull request that’s already been merged. It makes absolutely no sense. You’re adding value there. It’s merged. It’s been approved enough to get merged. And it just creates noise, not only for the maintainers. But for everybody involved in that discussion.”
Pro tip 1: spending a week watching the community before you try to contribute is a good way to calibrate what’s really helpful.
Pro tip 2: imagine one of the Maintainers is standing in front of you and you are explaining the contribution you made. Can you look that person in the eye and explain why your contribution is good for the community, and not just an activity metric for you? If yes, great. If not, find a better way have.
Part 4. How can you be an effective Open Source Maintainer?
Those were tips on how to be an effective Contributor to Open Source.
Now let’s talk about tips to be an effective Maintainer. There are seven tips here too. I promise that was a coincidence.
Be ready for a lot of notifications
This is a great tip for first-time maintainers: you will get a lot of messages.
“Be prepared for lots of notifications. It can be a bit of a shock, especially if like a really enthusiastic person comes across your repository and makes a lot of issues or pull requests at one time. This is a good thing and it means that people are learning all the time. So go with it.”
Make it easy for newcomers to get started
Writing clear and detailed documentation and having issues identified that are suitable for newbies make your community more welcoming– and save time for Maintainers, too.
Here are Maintainers on how to do this well:
“At EddieHub, we have a ‘good first issue’ channel, where people can pick up good first issues to get started. However, for people who are posting those links, just make sure they are good first issues, make sure they have steps for people to understand how they need to get going.”
“Make sure that your Readme has a really good quickstart guide so people can get started. It’s not just about how you clone a repo, there are many official sources for that. Make sure that you also cover the specific parts about your project in your repo rather than the stuff that people are going to find on finding the official documentation.”
Be clear on documentation. Be really clear
It is almost impossible to make your documentation clear enough.
One maintainer: “Make sure you have like a really clear contributor files, saying like, if you want people to, for example, write the pull requests in a specific way, have it clearly explained in the contributor file so that people know how to contribute. And then there’ll be less back and forth.”
Pro Tip 1: Read your documentation out loud. Is it something you would say to another person? If not, change it to how you would say it.
Pro Tip 2: a great project suitable for new contributors is to have them pressure test your documentation. Have multiple newcomers read the documentation and see what questions they have. Then update the documentation to reflect answers to those questions.
Be kind to contributors
Remember that these contributors are volunteers, who have chosen to spend their time helping improve your project. Repay their contributions with thoughtfulness.
This does NOT mean that you will always agree with their contributions– after all, a reason to contribute to Open Source is to get feedback to become a better coder or technologist — but share feedback through code reviews or other methods with a spirit of generosity.
Another maintainer: “Be kind to the people that want to contribute to your repository. Even if they do something wrong, it’s not out of ill will, they’re there because they want to contribute. Many of them are young, try to help them learn. And just try to be as kind as you possibly can. Because it’s easy to take things the wrong way in like a written message when you write back to someone in an issue or a pull request.”
Encourage multiple code reviews per pull request
Code reviews are a magic method to help improve the code and help improve coders’ skill and knowledge. It’s not just about the code author, either– code reviewers frequently learn by reviewing.
And while one code review is good, two or three code reviewers can be even better.
One maintainer: “It’s always great to have multiple reviews. Pull requests with two or three reviews means there was a great (asynchronous) conversation and coordination, which helps the project.”
Automate processes
The more that can be done to improve the code and core processes, the less work it is for the maintainers and contributors, and the more they can focus on what they can contribute.
One maintainer: “I would say automate as much as possible. So have if you’ve got linters, run them on GitHub actions. Not to take away from the collaboration or communication that you’re gonna do with the community, but focus that collaboration and communication on what matters more. There’s no point are we saying you’re missing a semicolon, your indentation is incorrect, you want to have that automated, and then you can discuss the more interesting and fun things.”
Pro tip: helping automate tooling for a community is another great way to contribute, whether that’s in the codebase or in the communication channels.
Set clear expectations on time commitments and update them accordingly
This is the flip side of “Focus” for the Contributors. If you are a Maintainer, be realistic about what time commitment you can actually make, and meet that commitment. If the situation changes and you have to reduce the time, be upfront about that too.
As a Maintainer, people are now relying on you, and it’s much better to underpromise and overdeliver than having people wonder where you went.
One maintainer: “Don’t stress yourself out by thinking I have to dedicate many, many hours to this every week, because I’ve volunteered to be a maintainer. If you’re looking to be a maintainer on a certain site, and you don’t feel like you’re going to have the time, discuss that with the person that owns the repo in that case, just so that you don’t feel stressed yourself.”
Part 5. Conclusion
I hope you found this useful and intersting, and encouraged you to take a step further in mentoring and supporting others in tech, in Open Source or elsewhere.
Open Source in general and EddieHub in particular is all about learning in public, so please reply with comments, suggestions, and improvements to make this piece even better.
It’s hard to convey the energy, support, and passion from hundreds of people from across the globe– many of whom have never met in person — emanating from two Twitter Spaces on a Sunday afternoon in the US/ Sunday evening in Europe/ Sunday evening in India.
I hope I did my best sharing some of that magic. But better yet, follow EddieHub and join the next session to see for yourself.
