Open Source is something where you have a project and its open to all. Anyone can work on it, contribute to the project and build something great.

And when you solve a bug , that the community has been pondering for months, you feel that joy - The True Joy of Open Source

Open source is a term used to refer to codebases that anyone can view and propose edits to. Most notably for our industry is the website GitHub, which hosts almost all open source projects. Open sourcing projects is a great way to get involved in the community — it lets you interact with other developers, it lets you learn to code better, and it even can help you become familiar with large code bases, something often quite daunting for junior developers.

But how do you start? First, I’d try something really, really simple. Go find a project you like, maybe it’s your favourite ruby gem or an npm package and start reading the code. We’re not looking for logical flaws here, we’re looking for typos. Yes. Typos. Typos in comments. Your first pull request to an open source will be a typo correction. You will change reuturns to returns. You will change him to them. You will change whatever you can find that is trivial and safe. But the change isn’t important. What is important is how you propose the change. Look around a bit, and you’ll most likely find a contributor’s guide or a section in the read me. These sections will tell you how you make a change to the code base. How you check out the code, run it, branch naming conventions, PR conventions etc. You might also want to read last week’s Code Reviews blog for a good read on how to create a great PR. Also it’s a great time to interact with the maintainers of the project, and start that relationship that will be helpful to have as the intensity of the PRs increase. Now that you’ve learnt how forking and creating pull requests works, it’s time you open source something of your own. But what Sam? Well, do you have any projects from Uni or bootcamp? How about that script you wrote one weekend for a laugh? How about that code you wrote a hackathon? The code doesn’t necessarily have to be good (whatever that means?!) just get it online. It doesn’t have to be finished. We just want to see you’ve done something. And yes, you don’t have to get fancy and write a contributing guide like the one above, but a simple yet effective ReadMe will be helpful.

So what goes into a great ReadMe?

• A description of the project. What does it do? What does it solve?
• Installation of the code into your own, or how to run it on your computer
• Common (trivial) examples of usage
• Comments about how to contribute. This can be simple
• A link to more information, documentation or support
• A list of known bugs, limitations and/or a To Do list of features. Although these should also be issues in the GitHub repo
• Optionally, a list of people using this code inside theirs (in the case of plugins etc) or top contributors
• If no LICENSE.md, an indication of the license of the code (MIT, Apache etc). Use Choose a License to determine this

So that’s a great open source ReadMe. What else should a great repo have (apart from code)? (Yes, I know, some of my projects don’t have all of these)

• A ReadMe
• A Contributing Guide
• An Issues template
• A PR template
• A License
• A Code of Conduct