By Ben Pfaff
The previous part in this blog series explained the basics of getting involved in open source. After being involved in one way or another for some time and finding the work to be enjoyable, many people will feel the urge to found a new project to help satisfy some need at home or at work. Before you dive in, it’s best to spend some time searching for existing open source software that can serve the same purpose. If you find a project that already works, that saves a lot of time and effort, and if you find a project that almost fits the need, then that becomes another project where you can help out.
If no existing project is close enough, then it’s reasonable to found a new project. At this point, you need to make numerous decisions, many of which are the flip side of the factors covered in the previous post. such as what version control system to use and where to host the repository, what license to use, what legal formalities to require from contributors, and how to accept contributions. You should document each of these choices in a README or other file in the repository. It’s more important to decide than to decide perfectly, because while most of these choices can be changed later, potential users and contributors will want to know what they are as soon as they encounter your software.
Writing software is a big job that involves many pieces that have to fit together just right. If you’re starting a new open source project as a sole developer, then you have to prioritize what pieces to build first. One good approach is to first get enough code written and working that the project is useful in a basic way for your own purposes. Then, or even before, write enough documentation to allow someone who already has some related knowledge to get started with your software. After that, besides adding additional functionality, it’s a good idea to set up automatic build and test infrastructure, which is readily available for free for open source software, to ensure that the software works in an environment outside your own laptop.
When you feel like your software is ready for outsiders to try out, it’s time to start talking about it. Word-of-mouth via Twitter and other social media is the most common way to start. Don’t expect your new software to attract attention quickly. It usually takes a while to attract users, and even longer to attract significant contributors. The early users for open source software tend to be developers themselves, since they are the users best equipped to use software that probably still has rough edges. Make sure that you have a way to get their feedback, such as a bug tracking system, and that your documentation tells them how to do that.
Once you have users, congratulations! You have successfully founded a project.