Open-source is everywhere. There is an extremely high chance that you used more than one open-source library in your last project.
The power of the open-source is the power of the people. The people rule - Philippe Kahn
The open-source has a lot of benefits, they include:
- learning
- hands-on experience
- exposure (you to the community and vice versa)
- collaboration
If you are not contributing to open source, then it is a good time to start. Some links that might help are -> GitHub explore, Good First Issues, Collaborators needed
While projects from big companies are attractive and give you more exposure. There are plenty of ideas/projects out there looking for contributors. Be a part of the next big thing.
Please do consider contributing to the idea that you love.
The open-source community is growing exponentially, as maintainers, we must ensure certain standards.
Appreciate / Recognize / Reward
Maintainers 👏 -> 🤝 -> 💰
Disclaimer: I know we (maintainers) juggle between many roles. But we should understand that we are shaping the community.
Appreciate the contributor. The project might have gazillion stars and thousands of contributors. No matter what appreciate the contributor. They spent their invaluable time to build your dream.
Irrespective of whatever the quality/quantity of the contribution, appreciate.
If it is a
first-time contributorthen congratulate them, make them feel welcomed.If the contributor is consistent and looking for ways to contribute more, then Recognize them.
Create a team, and ask them to join the team. GitHub provides granular control for the teams, create a team, and add every contributor to that team.
Reward them if you have the funds. Projects like Webpack / JHipster reward the contributors for their contribution.
If your project is funded, then share it with the community.
Users 👏 -> ✨ -> 💰
Appreciate the project and the maintainers.
The product/software is not created in a single day. The maintainers put in hours and hours of dedicated work to make it work. So always respect and appreciate them.
Even if there are some mistakes, please fix them.
Recognize the project. Give stars 💫 if you like it. Share it on social media.
Reward them if you have funds or time. Fix that long-standing bug or donate a coffee to the maintainer.
Give constructive feedback 💬 💬 💬
Maintainers
The quality of the Pull Request may not be perfect always. Remember the person contributing may be new or have a different understanding.
Give constructive feedback. Instead of pointing the mistake, show them how to correct them.
If you have to close the work (Pull Request), give enough context why did you close it and at the very least wait for the approval before doing so.
Imagine how frustrated you were, when your last manager dismissed all the efforts that you made. Don't be like that.
Naturally, people like to contribute more if they feel welcomed.
Users
Please do respect the decisions made in the project. If you don't like a decision, but the project maintainers insist to go in that way, accept it. The answer is fork and not public shaming.
The same constructive feedback applies to you. If a maintainer makes a mistake, be constructive. At the end of the day, they are people too.
If you are an expert in the field, then encourage best practices and guide them. Not all project maintainers know everything, it is important to remember "open-source is all about the power of the people".
Document 📝
Maintainers
Document anything and everything.
Believe it or not! Documentation saves both your and users' time. Features are mandatory but documentation is an absolute necessity.
When documenting, add the following scenarios:
- The basic usage (the default way to use your product)
- The tips and tricks (that increases your user's productivity)
- The essentials that your users need to know
- Add
Contributionguidelines
and others.
Think documentation as a feature, not as an overhead.
Users
Understand it is not always possible to document everything. If something is missing, please do contribute.
Create a blog post, add links to the wiki page (if the project has one). Tell it to the maintainers, ask them for a review (if needed).
When using the product, you hit a roadblock, found a solution, document it, and share it with the community.
Always remember, in documentation, every single bit matters.
Do not enforce complex / stringent rules 👾 👾 👾
Maintainers
Often, some projects impose an incredible amount of perfection. Like your commit message should be in this tense, the issue should have the GitHub issue number, and others.
Please do not ever impose them. Have a system that automatically handles this or stop asking for it.
Always remember people are helping you to build your vision, enable them rather than blocking them. Make it easy for them.
Users
Certain projects have stringent rules for many reasons.
- They are some good practices to follow.
- They make it easier for maintainers, in their process.
- They provide a great name for the project.
- Always green build increases the confidence in the project.
Please read the contribution guidelines, if you understand and accept everything then contribute.
🐦 Twitter | 💻 GitHub | ✍️ Blog
Share your Open-source experience or idea to make it even better :)
Top comments (0)