There are several reasons why people opt for open source vs proprietary these days. Open source encourages innovation through collaboration, allows for more efficient responses to security issues, reduces bias and discrimination and enables wider adoption and distribution.
Through collaboration, contributors experience a lower risk of burnout because they are part of something bigger than the individual, contributors receive feedback more efficiently because users can engage directly with the project developers, and contributors have a competitive edge on the job market because they’re developing on the cutting edge.
Enterprises embrace open source because it allows them to start small and scale immediately, to build a proof of concept quickly to test if it will work for them, to avoid vendor lock-in, and to create the feature you want to see in the project.
The reason why open source can do all these things for so many people is because the power of community is at the core of successful projects. Without community, a project is only technically open source because of its license and won’t reap the benefits of rapid innovation, consistent release cycles, and faster response to current trends and market needs.
In order to create a healthy, rich community full of globally diverse contributors, we must make it easy for everyone to use the project, clearly explain how to contribute, build personal relationships, make people feel included, and create a safe environment by setting a code of conduct.
This is not just about documentation or sample apps or workshops, but about every piece of content that enables users of all learning styles to become successful within the project. This touches documentation, yes, but also marketing and education and developer relations and anyone else who creates content that will influence, inspire, and encourage people on their developer journey from “I’ve heard of this project and I’m curious to learn more” to “I have contributed to this project’s core.”
- Documentation details all aspects of the project
- Content includes examples and use cases - this may be from one line commands to extensive sample applications and customer implementations
- Content is updated regularly and is easy to contribute to
Collaborators who want to contribute need to have all the information at hand to get started and work at full speed. This includes an up to date contribution file, well labeled issues using ‘good first issue’ or something similar indicating an issue for new contributors, and an informal or formal mentorship program or office hours or clearly indicated ways for people to ask questions.
Collaborators are people, not computers, and people need connection in order to avoid burnout, maintain sound mental health, and work efficiently. To that end, every community needs a space to communicate, like IRC or discord, to be welcomed to the community, and to be recognized for their contributions.
The more people feel they belong to a project, the more enthusiastic and motivated they’ll be to stick with the project through thick and thin. What are the best ways to make the open source community feel included?
- Feedback of all kinds is heard - both positive and negative.
- Moderators and representatives are available to the community via several communication paths.
- Public recognition for contribution. Extra highlight for first time contribution. Possibly via an Author.md or Contributors.md list on github.
- A mentorship program, either formal or informal, to help people complete their first contribution.
- Promote trusted contributors to maintainers with commit access and a chance to maintain the project to a professional standard.
An open source project brings people together from all over the world with different cultures, backgrounds, and variations in cognition. While diversity is key to innovation, it can also lead to major conflicts within the open source community.
According to GitHub, negative interactions between users in open source are quite common. Nearly 18% of people who're active in open source communities have been faced with a negative interaction with another person. Moreover, 50% of them have been a witness to a negative communication between other people in open source. The most common negative interactions are impoliteness, name calling, and stereotyping. A whopping 21% of users said they stopped contributing to a project because of a negative interaction.
A project needs to offer a harassment-free experience for all users, regardless of their age, ethnicity, gender, nationality, sexual identity, or religion. In order to foster an open and welcoming environment and avoid negative interactions, post and enforce a Code of Conduct.
- an open source LICENSE file
- basic documentation
- README
- CONTRIBUTING
- CODE_OF_CONDUCT
- The issue queue is up-to-date, with issues clearly organized and labeled
- Project uses consistent code conventions and clear function/method/variable names
- The code is clearly commented, documenting intentions and edge cases
- There are no sensitive materials in the revision history, issues, or pull requests (for example, passwords or other non-public information)
- Friendly README
- Clear Code Examples
- Up to date Issues
- Good First Issues
- Initial Contributor Appreciation
- Average Response Time
- Contributions besides HackTheGibson Code
- Interpersonal Communication / Contributions That Don’t Fit
- Online Community Interactions
- Office Hours
- Zero-Tolerance Policy / How Are People Asked to Leave
- Advice for New Contributors
- Mentorship Program
- User Recognition Program
- Shared Ownership
- Contributors / Authors File
- Recognizing External Contributors
- External Contributor Commit Access
- 1-2 Maintainer per Repository
- Consensus Seeking Process
- Do Contributors Feel Heard?
- Community Tiebreaker
- #WhyThisProject
- Target Audience
- Request Feedback
- Relevant / Related / Tangental Open Source Projects / Communities
- Online Promotion
- Social Media
- Stack Overflow, Reddit, Hacker News, or Quora
- In Person Promotion
- Meetups / Workshops / Conferences
- Reputation
- How do we help other individuals / projects / companies / communities
- Develop an Audience
- Share resources
- Develop relationships with other open source projects
- CoC Expectations
- Location - where the code of conduct takes effect (only on issues and pull requests, or community activities like events?)
- To whom the code of conduct applies to (community members and maintainers, but what about sponsors?)
- Consequences - what happens if someone violates the code of conduct
- Reporting Process - how someone can report violations
- Main Reporting Email
- Alternative Reporting Email
- Other Alternative Reporting Email
- Report History
- Gathering Information
- Take Appropriate Action
- Public Warning
- Private Discussion
- Suspension
- Permanently Ban
- Project Vision
- Project Expectations
- Contribution Review / Acceptance Process
- PR Template / Checklist
- Open an Issue First, then Submit a PR
- Contribution TYPES
- Follow Up / Escalation Process
- Timeline (we only spend five hours a week on this project)
- Communication (mailing list or issue tracker)
- Meetings (internal only meetings need public notes published)
- Events
- workshops / meetups organization
- conference organization / volunteering
- speaker training / mentorship / CFP
- Design
- restructure layouts
- user research
- navigation / menus
- style guide / consistent visual design
- artwork for swag / logo
- Writing
- documentation
- use cases
- blog posts
- newsletter
- mailing list highlights
- tutorials
- l8n / translation
- Organization
- link to duplicate issues / suggest new issue labels
- suggest close old / abandoned / outdated issues
- ask clarifying questions on recently opened issues to move the discussion forward
- Coding
- open issues
- new features
- automate project setup
- improve tooling / testing
- Helping People
- answer questions on Stack Overflow / Reddit
- Answer questions about open issues
- Moderate the forum
- Help Others Code
- Review code
- write tutorials
- mentorship
- Thank Them for their Contribution
- Explain Why It Doesn’t Fit
- Clear / Specific Suggestions for Improvement, if possible
- Link to Relevant Documentation
- Close the Request
- Don’t Feel Guilty
- Be Kind
- Formal vs Informal
- Goal(s)
- Structure (Traditional 1:1 / Group / Peer to Peer / Reverse / Flash)
- Initial Post / Push
- Registration (Cadence)
- Documentation
- Metrics
- Basic Maintenance Tasks
- release
- testing
- packages
- no-response
- code review
- contributors agreement / CoC acknowledgement
- dependencies
- triage
- Issue Templates
- Pull Request Templates
- Take Breaks
- Prioritize Self
- Set Boundaries
- Say No
- total page views
- total unique visitors
- referring sites
- popular content
- github stars
- Download Rate
- Traffic
- Total Contributor Count
- Number of Commits per Contributor
- First time / casual vs repeat contributors
- Diversity within the Community / Maintainers / Contributors / Committers
- Number of Open Issues / PRs
- do we need help triaging or doing code reviews?
- indicates that someone cares enough to open an issue / PR
- types of contributions
- fixing typos
- commits
- bugs
- comments
- Average time an issue remains open
- Whether issues get closed by PRs
- Whether stale issues get closed
- Average time to merge a pull request