Building an open source software community


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

SAS sticker
Did you know that SAS sponsors a robust open source software program? We host hundreds of code repositories at 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.


About Author

Joseph Castle

Advisor, Strategic Relationships and Open Source Technologies

Joseph Castle, Ph.D. builds strategic relationships for the U.S. public sector with SAS. This involves educating current and potential customers about data analytics, artificial intelligence (AI), cloud-based environments, development operations (DevOps), and open source software (OSS). Castle served over twenty years in the U.S. federal government. In the General Services Administration (GSA), he led numerous programs for the office of the Chief Information Officer and Technology Transformation Services. Castle directed the federal government’s Open Source Program Office (OSPO) to implement the federal source code policy by educating and collaborating with major federal agencies to publish OSS. A veteran, Castle served in the U.S. Army’s 10th Mountain Division. He is a Fed100 recipient and a GitHub Star. Castle holds numerous advanced academic degrees including an MBA, MS in information systems, and a Ph.D. in public administration and public affairs. He lives in Maryland with his wife and two children.

Leave A Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Back to Top