How to Start an Open Source Project

Do you have an idea for a useful open source project? This guide provides step-by-step instructions for getting started and making progress on your project. It covers tools and techniques, including a list of resources like people, mailing lists, events, books and more. It’s geared toward people getting started with open source — you don’t need to be an expert coder to use it!

Great open source projects, like delicious recipes, are built with the right ingredients. Open source projects live or die based on their community. Communities are comprised of people, and to succeed your community will need to be nourished with a goal everyone can get behind, code that’s easy to get started with and contributors who can help others. These ingredients aren’t a secret. They exist in nearly all successful projects. Learn how to set up your project for success by following this recipe for success.

Determine the goals

Every open source project solves a specific problem. Talk with colleagues, chats, forums, and share your idea. It all helps you on the first steps to understand important things, like which solutions already exist, and to hear criticism. Talk with people who already have open source projects. They can give you very valuable advice, so don’t be afraid to ask and take the initiative.

One important bit of advice which I got at that stage is to pay attention in the first place on the documentation of the project. You can have a very good project, but no one will spend the time to understand how it works.

The most important aspect, without which further steps are impossible, is motivation. The idea of the project should inspire you primarily. Most often people get used to the tools with which they work and fall into a comfort zone, so external opinions may be ambiguous.

Report a bug to the project’s issue tracker

Reporting an issue to a project’s issue tracker, such as GitHub Issues, is one of the easiest ways to support the open source projects you use. Most open source projects have iso trackers–typically using something. Sometimes when we discover a bug in software, we’re in no mood to go out of our way to report it. We want to work around the problem and move on. That’s fine, but be sure to report the bug as soon as possible while it’s still fresh in your mind. Report all the details you can about showing the bug’s behavior and explain it just like you’d want a user to explain a bug to you.

Sometimes, of course, the bug isn’t even in the code, but in the documentation. Maybe you’ve come across an out-of-date reference to a feature that no longer exists, or even just a typo. These documentation bugs are just as real as bugs in code, and they should be reported in the issue tracking system.

But most bug reports received by open source projects are terrible. They’re often one-liners that vaguely describe a problem and don’t provide details about how it happened, where it happened (which browser, which OS, what type of device, and so on), or provide any steps to reproduce the bug.

This gives you two great opportunities to contribute in a way that gets you noticed and genuinely helps the project.

First, if you encounter a bug in an open source tool you’re using, document it as thoroughly as you can. Include details like OS, browser, device type (mobile/desktop/laptop). Include detailed steps to reproduce the bug, and add screenshots if possible.

Next, try to reproduce, verify, and document bugs discovered by others. Follow the same steps you’d follow when reporting your own bug. See if there’s any new information you can add. You might add a comment like, “I found that calcScreenResolution() only shows this behavior in Chrome, but not Firefox.” Details like that can be a huge help to developers working to solve the problem. This turns terrible bug reports into detailed, actionable information the project’s developers can use.

If the project accepts one of your bugs as a valid issue, offer to fix it, and ask what they’ll expect in terms of unit tests to verify the bug is fixed. This can be a great way to contribute your first code to a project because you’re not just reporting a problem–you’re also offering to solve it.

Planning

The choice of a certain task manager is a matter of taste. It should have a clear picture of the tasks and stages of your project.

Divide tasks into sub-tasks. Ideally, if one task does not take more than 3–4 hours, it is important to enjoy the implementation of small tasks. This will help to avoid burnout and loss of motivation.

I use pivotal tracker. The main advantage is a free version for open source projects where you can sort tasks by type (feature, bug, chore, release), and group them into releases and determined deadlines.

Volunteer to write documentation

Precious few developers are eager to write documentation, but it’s critical to the success of open source projects. What’s the first thing you look for when exploring a new project? The documentation. And what’s the first thing you look for in that documentation? Examples of how to use it.

But starting out writing code when first joining an open source project can be a challenge. It’s often tough to contribute code until you’ve taken time to understand the codebase, its coding conventions, and testing requirements.

Writing documentation helps you learn the codebase–you’ll often need to read and understand the code you’re trying to document. This gives you a sense of how the project hangs together and how the code works.

Documentation can be a good starting point because it’s a sore spot for many open source projects.

And don’t overlook the social aspect. Open source projects commonly have senior developers who own part of a project’s codebase. These owners aren’t always friendly to outsiders. Writing documentation gives you a chance to get to know the developers working on the project, and gives them a chance to get to know you.

So when you’re ready to make your first code contribution, it won’t be coming from an outsider. It’ll be coming from that brave person who dove in and wrote the docs nobody else wanted to write–and the rest of the team will be happy to help you get your first code pull request accepted.

Conclusion

An Open Source Project is a project where the end-user gets to choose what they want, when they want it and where they want it. This tutorial will help you get started.

0 Comments

No Comment.