This blog is developed from my keynote presentation delivered at the U.S. Department of Energy Solar Energy Technology Office (SETO) one-day workshop focused on building community engagement for lasting impact.

The community that develops around projects is one of the richest aspects of using, developing, and sharing open source software (OSS). This community consists of individuals who are interested enough in your software project to contribute and you, likewise, engage with their work fostering a reciprocal relationship that enables projects to benefit. These communities must be created and nurtured given the large number of projects and domain expertise that is often required to use and contribute to software code bases.

I'm offering the following considerations that will help you when building and working in an OSS community. This is a comprehensive but not an exhaustive list and they do not have to take place sequentially. The first two considerations are action-oriented and the last is prescriptive for maintaining an OSS code repository.

Consideration 1: Human

• Make it easy to use and contribute to the code.
• Be responsive to individuals when they inquire about the project through issues, pull requests (PRs), and external repository communication.
• Build personal relationships to cultivate frequent contributors and long-term support maintainers.
• Be inclusive by offering suggestions and being open to various types of contributions including code, documentation, and general suggestions.
• Build careers by finding new user groups to market your project and include newbies or those that want to change careers into technology (e.g., Girls Who Code, Operation Code).
• Never tolerate bad actors and make sure to resolve conflicts quickly. A code of conduct file in the repository is very important.

Consideration 2: Program

• Establish an outreach approach to engage with individuals who are most likely to be interested in your project and code base (i.e., who has the domain knowledge to help?).
• Meet people where they are located by considering online and offline community events (e.g., Meetups).
• Update the repository consistently because individuals will ignore stale repos.
• Use media for consistent communication including issues, PRs, chat, groups, listservs, and email.
• Use social media with blogs, tweets, and featured topics and community members.
• Attend and hold events such as OSS conferences, challenges, hackathons, and office hours.
• Give out free stuff like stickers, t-shirts, and fun things. Everyone likes a reward!

Consideration 3: Repository

• Documentation is often overlooked but probably most important. Individuals will readily participate with better technical documentation, "how to" contribute, and code review process.
• Code of Conduct file should include the project owner's pledge, standards, responsibilities, scope, and enforcement in case of bad actors.
• Contributing file informs individuals on how to contribute to the project and code base.
• License file needs to be included for the project to be considered a "real" OSS project. If needed, work with a legal team to consider proper licensing for contribution and use.
• Readme file should include a project overview, easy to understand instructions for using the software, and API keys if needed.
• Issue and PR templates provide workflow for addressing issues and completing PR merges. One way to complete is to assign at least one team member or another contributor to review.
• Labels including "help wanted" and "good first issue" provide a starting point to notify users of easiest first contributions.

The Open Source program at SAS

Did you know that SAS sponsors a robust open source software program? We host hundreds of code repositories at github.com/sassoftware. Before sharing, each project undergoes a diligent review for appropriate content, license terms, contribution guidelines, and legal considerations. A few of our most popular projects include SASPy (a Python library to work with SAS), the SAS Extension for VS Code, and relic (a tool for software developers, not specific to SAS).

Participation in the open source community is energizing for SAS developers too. Many developers attended the recent All Things Open conference in Raleigh (where SAS was a sponsor). The open source ecosystem benefits SAS developers, the tools that they use and the software they build. By giving back with their own contributions, the developers in SAS R&D feel the connection to a larger community of software professionals.