Open Source can be daunting for new developers to get in to. Here are some tips that I have learned along the way while managing an, albeit small, active project.

Background

This project started around the time I was getting ready to graduate college, like most good projects it started because I was lazy. I had grown tired of constantly boiler-plating projects, so I made the MEVN Stack. A vanilla quick start template of my preferred technologies with some example code in there to help get others (and myself) going on a new full stack project.

The Beast of Open Source

Originally the project was made for myself and a few colleagues, however it started to get some traction from other developers on GitHub. Before I knew it the project was averaging 400-700 views every 2 weeks and had over 50 stars. With these new eyes on the project came contributions, and for me one of the scariest things.

People looking at my code.

When the project's first issue was opened my heart sank, I expected a programmer much better than myself to be tearing apart every aspect of my project. Turns out it was just a friend of mine calling out some redundant code that snuck in, a completely humbling experience. Since then the project has gained 2 more contributors, merged 2 pull requests, and closed 2 more issues. These are some things I learned along the way:

Mindset

It is easy to get a solid case of imposter syndrome when putting your work out for the world to see. Here are some tips for how to think when approaching Open Source:

• Be humble.
  When my first issue was calling out a simple redundant line of code I realized that 99% of the time if someone is opening an issue, they are commenting on your work in good faith. Issues are not where someone is going to call you out and tell you that you are not a real developer. The issue is more often than not a chance to improve the project, and yourself as a developer.

• Keep an open mind.
  If someone is reporting an issue that you cannot reproduce, attempt to gather more information. If they propose a code change, ask them to open a Pull Request. Review the changes they made, perhaps it does not affect the project on your environment, but will improve it on theirs.

Product

When most user's click on your project the only up front information they have is the name, and a README (hopefully). These tips pertain to the actual product, your code:

• Write readable code.
  When someone pops open the source code of your project they should be able to read and understand what it is doing. Not only do I mean that your code should be formatted properly, it should also be understood. Give variables and functions meaningful names, follow (or at least loosely follow) standards that people are expecting to see. Do your best to remove the mystery around your source code, this will make it easier for others to use and help them over the hurdle of starting to contribute.

• Keep it simple.
  This is applicable in most cases. If there is no benefit to using the super convoluted function you just thought up, then don't. Every point in your code that makes it harder for another dev to "compile" in their head, is another point you could lose a potential contributor. In cases where simplicity is unattainable, leave a comment in your code.

Self-Care

When people are using your code you may feel obligated to carve time out of your day to fix problems they are having, or improving their experience. You should do these things, but not at the expense of your own health. These are some things I learned about putting yourself first:

• Don't overcommit.
  When working in Open Source, people will ask for improvement, help, and bug fixes. It is easy to get in the mindset of "Someone asked for X, I have to drop everything and do it". However you come first, if you do not have the time due to other commitments, or are starting to burn out a bit; ask the reporter if they would like to submit the fix. This helps you keep a balance, helps the project remain maintained, and helps someone else contribute.

• Find a balance.
  I work 40+ hours a week along with a long commute and travel. Finding time to work on projects can be a bit difficult. The best I have found is taking a chunk of time during a vacation or long weekend to get some tasks done. This works well for me, I get to hit a groove and check off a bunch of work without it encroaching too much into the rest of my time off. Find what works best for you and stick to it, if someone is asking you to do some work and not respecting your timetables then they are not coming to you in good faith.

I hope these tips I picked up in the past year of working in Open Source is helpful to developers looking to get their foot in the door and seasoned contributors alike. If you have any more helpful hints to contributing feel free to drop them in the comments below!