Open source projects do not spring forth fully formed. A project’s success depends on the people involved and their ideas. Although there is no easy formula for creating a successful project, here are some best practices that will get you started. They are listed in order of importance, so pay attention!
It’s time to make your first open source project. You can start with something small, and simple, like a component that you use in your daily programming. This post will cover how to make a reusable component. If you’re wondering why you should create an open source component, check out my post on Open Source Benefits . That post goes over some of the benefits of open sourcing code including more bug fixing, more usage and better maintainers!
Choosing a license
An open source license guarantees that others can use, copy, modify, and contribute back to your project without repercussions. It also protects you from sticky legal situations. You must include a license when you launch an open source project.
Legal work is no fun. The good news is that you can copy and paste an existing license into your repository. It will only take a minute to protect your hard work.
When you create a new project on GitHub, you are given the option to select a license. Including an open source license will make your GitHub project open source.
If you have other questions or concerns around the legal aspects of managing an open source project, we’ve got you covered.
READMEs do more than explain how to use your project. They also explain why your project matters, and what your users can do with it.
In your README, try to answer the following questions:
- What does this project do?
- Why is this project useful?
- How do I get started?
- Where can I get more help, if I need it?
You can use your README to answer other questions, like how you handle contributions, what the goals of the project are, and information about licenses and attribution. If you don’t want to accept contributions, or your project is not yet ready for production, write this information down.
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.
Get to know GitHub
GitHub is the most popular platform for open source collaboration, so you’ll probably use it when exploring the world of OSS. First, you need to create a GitHub account and read the guide that helps you get started. On GitHub, you can contribute to projects by submitting issues and contributing code. Submitting issues means sending messages about errors in applications and suggesting ways to fix them. Contributing code involves sending pull requests with your corrections and improvements.
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.
Learn the basics
When working with GitHub, you should know how to use Git – one of the most popular version control tools (also known as revision control tools). Because developers constantly make changes to their code, they need a system that can manage those changes in a central repository. In this way, everyone involved in the development process can download a given piece of software, make changes, and submit updates.
We don’t have to wait for someone else to make a product we want. We can do it ourselves. Yes, even if you are not a designer, a coder, or an expert in the technology behind the product. This book shows you how with concrete steps and examples.