How to Become an Open-Source Developer

What's an Open-source project?

The tech world is moving according to economic trends.

There’s no company or startup which is ready to risk a lot of funds for a software project if there is a cheaper alternative.

What a company needs is to get a service up and running regardless of whether the software was built from scratch or as an open-source project.

At an individual level, open-source saves time and money too. By the way, what reward do you get after building your project from scratch?

Why build something which already exists and you can get it for free? Would love to hear your thoughts :)

But what is an open-source project? It is a software project which is publicly free for anyone. That is, you can edit the source code, and change it as required for your needs.

You can build your “big idea project” just on top of the open-source software. You can also release your sweet project back to the community as an open-source by allowing other developers to manipulate your codes.

How to Jump In While You’re Fresh

Stepping into open source projects as a newbie might be a challenge at first, but getting the right foot to start with can solve the issue of overhead.

There are things you should know before starting, contributing, or building your application on top of an open-source project.

Here’s the list of things you should consider first:

Are They Able to Use Git and Github Comfortably?

You’ll always find these projects in version control (VC) like Github. To access them and alter the change, all need a knowledge of the git. You need to know how to:

• Clone a project from Github (or any other VC).
• Branching models (master, develop, feature.)
• Push the project.
• Raise and resolve the issue.
• Write good comments.
• Tag and versioning the project.
• You can learn the basics from Github but I also wrote deeply about Git and branching models in my article titled “Contribute as a pro”.

Learn How to Write a Good “README”

A README in Github serves as brief documentation of a particular project. Writing a precise document about the project helps another developer to jump straight into the project and manipulate whatever he wishes.

On another hand, learning how to document your own project will help you to easily read and follow along with the docs of other projects.

While writing, there are a number of online tools to help with the job. I normally use Dillinger to write the README before shipping it into Github. It has some placeholders which you can just change to fit your headings and contents. It supports markdown language as that used in Github.

Learn How to Write Clean Codes

By "clean codes" I mean the codes which are precise and easy to read. Don't just focus on the working codes, but the codes that another developer can read and scale the project.

Write the code while thinking about another person who'll come to read them. Here are the tips for writing clean codes:

• Master the domain language of a given project. That is, if the software is about Health, then the naming convention and your variables should all align to the health context.
• Clear naming convention. Be very clear in naming the variables, methods and classes. Don't let your code become unequivocal just for laziness reasons.
• Use comments only where required.
• Obey the DRY principle. Only define once and just reuse it where needed. Don't Repeat Yourself!
• Well-structured file tree. Your files should be in an organized manner. Don't just write the codes anywhere! Also, specify your main file (entry-point file). This will help another contributor to easily know where your software starts.

What's next?

If you're comfortable with the tips above then it's the right time for you to try out doing something handy.

• Pick one open-source project. I'll write on sample open-source projects for beginners.
• Read the project codes and documentation
• Contribute. I will upload soon the article on how to contribute as a pro.
• Or build your software on top of it.

Thanks for reading this!

Stanley Ruheza (maen08)

Co-published