The open-source software industry is booming. Software developed by large corporations is built on open collaboration, thus enjoying the benefits of widespread adoption. In addition to bringing together many people from all over the world, free and open-source software brings people together by bringing their individual interests together.
Due to our diverse backgrounds, it's worth reflecting on how we work together to improve things. Depending on how you behave while working with others, your work may be merged, you may receive assistance with your issue, or even be blocked from participating in the repository further down the line. In this article, I'll describe 8 best practices in open source to help you have a more enjoyable experience in the community and contribute to making it a better place to live.
1. If there are guidelines for contributing, follow them.
Use the contributing guidelines to follow when you submit a Pull Request for a project. Every new issue or PR on GitHub includes a link to them (if the project has a Contributing.md file).
Whenever they say "tabs, not spaces," use tabs. If they say a particular style comment should be used, use it. Make the changes they require and run the build process if they instruct you to. If you don't know how to let them know in your request. if you don't take these steps, your project will appear inconsistent, and the authorship of a multiauthor project will be inconsistent.
2. Do not file issues with statements such as "is this even maintained anymore?"."
Such comments are insulting to the work they have done since it suggests that their work is no longer valid only because they needed a break, or were working on something else, or their father died, or they had a kid, or any number of human reasons for not being available for work. If you are not satisfied with past commits, then it's totally okay to ask if there is a roadmap for the future. Passive-aggressive behavior is not acceptable towards someone who has created something for you for free.
3. Never take entitlements.
There is no obligation on the project maintainers' part. After you begin using the project, you are responsible for helping maintain it. Provide suggestions and offer assistance if you are not happy with the way the project is being maintained. If you feel strongly that it is not the direction you personally would pursue, you can always fork the project and work on it on your own.
4. Practicing Impatience or rudeness
Please be polite when asking questions or expressing concerns. All questions cannot always be answered immediately. It makes no sense to respond to someone who is rude or impatient because they have nothing better to do. Commercial software is best for support if you need it right away and the producer can afford to provide it.
5. Ignorance of the documentation
As much as you hate to read documentation, developers dislike it too. Nevertheless, they exist for a reason. Ensure that you have read the documentation (if it exists) in order to determine whether it answers your questions. Search Google for answers. Most answers will be found there. Don't bother the developers with documents that don't exist. Submit an issue in the tracker instead.
6. Inconsiderate of people's time
You should not assume that every open-source project has a team of developers ready to answer your questions. There are many projects that begin as hobbies, and only a single person can work on them without pay, on their own time, in their free time. Many of the projects hosted on GitHub are noncommercial and the developers are the only ones involved. If they don't have anything better to do, they may spend a few hours on weekends if they are in the mood. Neither do they receive any payment for their work, nor do they receive much in terms of donations. These projects are of use to them, and they enjoy writing code. Once they no longer benefit from them, they will cease working on them. It's possible to reach a point where an application meets all its requirements and there is no reason to continue adding features to it.
7. Don't make noise but make progress
Think carefully about how you communicate in a project - be sure it is useful and does not impede other contributors. It's great to submit pull requests to fix bugs, but are they actually helpful, and are they easy to review? It's fine to file issues and join other conversations, but are your issues and comments relevant to the discussion, or are they unrelated?
8. Learn where to ask your questions
Ask questions where it is appropriate to do so. A good OSP will always make this clear in their documentation. Use these channels whenever you want to ask a general question. Make sure you are not just filing issues on GitHub for every question, as this only creates more noise (see "Make progress, not noise" below).
Open source is of immeasurable value to our industry. By following some simple etiquette rules, everyone can have a better experience. Remember that maintainers often work on projects in their spare time. Do not forget that some users of your projects may not be familiar with the rapidly changing world of software. Be aware of this when communicating and collaborating. By doing so, we are able to improve the open-source community.
You can now extend your support by buying me a Coffee.😊👇
Thanks for Reading 😊
Top comments (0)