Launch Your Own Open Source Project
Ideal moment to open source your work will never come. An idea, a work in progress, or something that has been closed source for years can be made public
Table of contents
In general, you should open source your project after you feel at ease with others viewing it and providing criticism.
Any project should have the following documentation, regardless of when you decide to open source it:
Open source licence:
An open source licence ensures that people are free to use, duplicate, edit, and contribute to your product without facing any consequences. Additionally, it shields you from difficult legal circumstances. When you start an open source project, you have to incorporate a licence.
Legal labour is not enjoyable. The good news is that an existing licence can be copied and pasted into your repository. It won't take long to safeguard your diligent labour.
Although there are more alternatives, the most prevalent open source licences are MIT, Apache 2.0, and GPLv3.
On GitHub, you have the choice of choosing a licence when you start a new project. Your GitHub project will become open source if you include an open source licence.
Readme:
The purpose of READMEs is not just to describe how to utilise your project. They also describe the significance of your project and the potential applications for your users.
Try to address the following inquiries in your README:
What accomplishes this project?
What makes this initiative beneficial?
Where do I begin?
Where can I go if I need further assistance?
You can use your README to address further queries, such as how you manage contributions, what the project's objectives are, and details regarding licences and attribution. Write down this information if you don't want to accept contributions or if your project isn't yet ready for production.
Sometimes, people avoid writing a README because they feel like the project is unfinished, or they don’t want contributions. These are all very good reasons to write one.
When you include a README file in the root directory, GitHub will automatically display it on the repository homepage.
Contributing guidelines:
How to engage in your project is explained in the CONTRIBUTING GUIDELINES file. You could, for instance, provide details on:
The best ways to report bugs are to use the issue and pull request formats.
How to propose a new function
Creating your setup and running tests
A CONTRIBUTING file is a chance to explain your expectations for contributions in addition to technical information, such as:
What kinds of donations are you seeking?
Your project's strategy or overall objectives
How to contact you from contributors, and how not to contact them
Making visitors feel welcome and eager to engage can be achieved by speaking in a nice, upbeat manner and suggesting particular contributions (such as producing documentation or creating a website).
In the earliest stages of your project, your CONTRIBUTING GUIDELINES file can be simple. You should always explain how to report bugs or file issues, and any technical requirements (like tests) to make a contribution.
Over time, you might add other frequently asked questions to your CONTRIBUTING GUIDELINES file. Writing down this information means fewer people will ask you the same questions over and over again.
Link to your CONTRIBUTING file from your README, so more people see it. If you place the CONTRIBUTING GUIDELINES file in your project’s repository, GitHub will automatically link to your file when a contributor creates an issue or opens a pull request.
Code Of Conduct:
Finally, a code of conduct aids in establishing expectations for conduct among participants in your project. This is particularly helpful if you're starting an open source project for a group or business. You may encourage positive, beneficial community behavior with the help of a code of conduct, which will lessen your stress as a maintainer.
A code of conduct typically specifies who these expectations apply to, when they apply, and what to do in the event that a violation takes place in addition to outlining how you expect participants to behave.
There are emerging standards for codes of behavior, similar to how there are for open source licenses, so you don't have to create your own. Over 40,000 open source projects, including Kubernetes, Rails, and Swift, employ the Contributor Covenant, a plug-and-play rule of behavior.
You should be ready to enforce your code of conduct when appropriate, regardless of the text you use. Directly paste the text into a file named CODE_OF_CONDUCT in your repository. Keep the file accessible by linking to it in the project's root directory.