Open source projects need: good documentation, a license to use, instructions for use and an accurate translation into various languages. The software should be easy to install and understand; the site must be simple and the visual design is a big plus.
Did you know that many different open source projects are in need of programmers to complete their project? A good way to get started creating a new open source project is to think of something exciting for people to do. You need to choose the idea that you really want to do and then start a website for your project. Then you will have a place for people who want to help create the same thing that you want to create. It is up to you what kind of thing you want people to work on, but it can be a game, an app or anything else that could use more work.
No one cares about your project
First of all, as an author, shift your thoughts about open source. You might think that if putting a lot of effort into the project (library, tool, framework, etc) that’s interesting to you, a lot of developers are going to get excited as well.
Unfortunately, that’s far from the truth…
It might sound harsh, but developers out there are only interested in solving their problems. So when someone visits your repository, one is searching for a solution.
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.
Well Designed README
README.md is the first thing anyone sees. Make sure to catch their eyes right away.
It’s harder to gain traction based purely on the merit of the tool rather than on the presentation of the tool.
For frontend applications, you should focus more on the design of the frontend rather than the
README. This is for CLI applications.
A well-designed README answers these questions succinctly:
- What does this do?
- Does it solve my problem?
- Does it solve my problem better than the competitors (if they exist) do?
- How do I install it?
- What are the basic commands I need to know?
- Where can I go for more help?
This is how a
README answers these questions.Open to view Infographic
We’ll go through each of these.
Define what success looks like
urllib3 is used by millions of people everyday, has 785 stars on GitHub, and has been growing since its creation in 2008. Andrey has another project, ssh-chat, that has 1,560 stars on GitHub, but is only used by about 15 people today. So which project is more successful? In order to answer that question, Andrey described how defining success at the beginning of project will help you understand if it’s successful or not.
The beginning of every open source project looks like this:
- Build something. Anything.
- Get frustrated with the hardest parts, build libraries and tools to help.
- Discard the original project to focus on the libraries, which become your new project.
- Go back to step 2 and repeat.
The story of urllib3 begins with the problem of trying to upload billions of images to S3 in 2008. Using existing Python libraries, this would have taken more than three weeks because there was no good concurrency support. You could use s3funnel, a multithreaded S3 client, but managing threads is painful. You could use a worker pool in s3funnel instead, but existing HTTP libraries didn’t reuse connections, and most solutions weren’t threadsafe or lacked multipart (filepost) encoding. Enter urllib3.
A snippet of requests, a popular function in urllib3
In Andrey’s words, “The solution space [in engineering] is about building something and solving a problem. For urllib3, the space was really small and the solution to other things were really useful, and that’s what made it successful.”
When defining a project’s goals, think about how solving a small problem can make a large impact.
Another form of success in open source is exemplified by ssh-chat, an encrypted chat-over-SSH program written in Go. Andrey started ssh-chat as a weekend project. One of the main contributions to the project’s success started with creating a thorough README. As Andrey puts it, “Having a great README is basically 80% of the work to success. You need to be able to answer three questions for your contributors: “Who else uses it?” “What do they use it for?” and “Where can I get more help?”
A snippet of ssh-chat, a popular ssh-chat program written in Go
But just creating an awesome README didn’t kickstart the impressive growth of ssh-chat. To make it thrive, it needed more traction.
Solve a real problem
Before even starting the open source project, before even writing the first line of code, invest a lot of time in finding a real problem to solve.
To summarize, a good open source project solves a problem that developers are actively searching for a solution.
I wasn’t particularly enthusiastic about strings. Creating such a library might even be boring… But what’s more important I found a decent problem to solve.
Recruit core contributors
To spread the word about ssh-chat, Andrey started asking for help, asking for improvements, and finding ways to bring more people into the project. In order to help build interest, Andrey reached out to people on Twitter and offered free Go programming lessons in exchange for opening pull requests. This overcame the initial inertia of getting a few people involved and interested in the project. These early contributors eventually became champions of ssh-chat and started answering questions on Stack Overflow.
Another component of building and maintaining open source projects is learning to be inclusive. Andrey says “accepting pull requests very generously, and very graciously” was a key step in building more community interest and is something that many open source authors miss in the beginning. And asking specific people to make a pull request was much more effective than making more generalized asks of his Twitter followers.
The process for setting up an open source project is like a rite of passage to many technical people. You initialize your repository and you feel the weight and sense of responsibility of making your project open source. You should document all details so that individuals with questions can get help quickly.