Managing an Open Source Project

A Checklist of Issues to Consider

This resource is intended to be a conversation-starter for open source software project leaders, their collaborators, staff, and community. We know that some of these items are substantial, resource-heavy requests for an open science community and we don’t intend that this is a comprehensive list of topics, nor a limiting one. ¹

¹ This resource was first developed by attendees at the July 29, 2024 Chan-Zuckerberg Initiative community call for the Essential Open Source Software program. If you add to this document, please also add your name to the contributors list (alphabetically by last name). You can make contributions at this Github Repo

Fundraising

Organizational Structure

• I have explored and chosen/developed an organizational structure(s) for the project
  • Nonprofit
    
  • Fiscally sponsored
    
  • Cooperative
    
  • Government Institute
    
  • For-profit - Company, LLC / Inc
    
  • University project
    
  • Using my personal checking account
    
  • I have no idea yet, but have begun learning about these models
• If applicable, I have considered the relationship(s) of the project to my home organization(s) (e.g., lab in a university, project within an institute)
  • I have formalized this relationship in writing

Bylaws, Legal, and Tax Considerations

• I have considered potential tax implications for me and the people I work with around the above fiscal model
• My project has a statement about transparently sharing finances, funding allocations, and the decision making process in an ongoing way with community members

Developing and Maintaining the Project

Managing Contribution

• Our project has contributor’s resources, which:
  • Invite contributions from individuals of all skill levels and backgrounds, whether they involve code, technical writing, mentoring, localization or other types of contributions.
    
  • Outline what acceptable contributions look like
    
  • Explain any obligations associated with contributions (e.g., best efforts to support contributed code, including what happens when multiple contributions interact in a way that leads to problems)
    
  • Invite structured engagement methods before to prepare contributors for submitting contributions
    
  • Motivate and encourage contributors to share ownership and governance of the project
    
  • Details potential equitable access models to financial resources and incentives for substantive contributions
    
  • Details about how sunsetting / simplification decisions are made across the project
    
  • Details about how breaking changes / deprecation are communicated and enacted, with a means for community input during the process

Planning for the future of your project

• Our project has a development roadmap
  • This roadmap is used and referred to in the context of project planning and development priorities
    
  • There are clearly documented procedures for how additions/removals to/from the roadmap are considered and discussed
• We’ve talked to users of our software to understand how they use our software
  • We’ve published example use cases online

Marketing the Project

Communications plan

• We have a marketing and communications plan, and it includes:
  • Conferences (in-person and/or virtual)
    
  • Video Content (YouTube, etc)
    
  • Events
    
  • Social media
    
  • Academic publications / pre-prints about the software and possibly results created with it, including submission to JOSS or another venue for software papers
    
  • Invited talks
    
  • Online information sessions
    
  • Training events / tutorials, perhaps at events where potential users gather
    
  • Hackathons
    
  • Community calls / meetups
    
  • Synchronous communications means (slack, gitter, discord etc)
    
  • Asynchronous communications (mailing list, github issues, community forum)
    
  • A periodic newsletter
    • Weekly
      
    • Monthly
      
    • Quarterly
      
    • Per Release

Documentation

• Our documentation suggests how our project should be cited in publications and requests that users do this

Marketing

• As our community grows, we’ve got a plan to distribute the load of “marketing” across the project, not expecting that one person “does” all the marketing

• As a project, we’re considering how our marketing needs may change and evolve and how we can encourage our community to conduct informal marketing on the project’s behalf. To support this we’ve created a branding toolkit that includes:

  • Short one/two page colorful collateral about the project
  • Informative presentation slides
    
  • Easily findable and accessible vector logos
    
  • Template slides
    
  • Document templates
    
  • Style guide (fonts, colors, logos and their acceptable uses)
    
  • Communication guides for community members
    
  • Ways to get involved / contribute

Managing the Project at Scale

Community Roles

• We have identified the stakeholders responsible for prioritizing tasks, both technical and social
  • We have developed and documented a process for agreeing to development goals and setting progress milestones
    • This process is transparent and accessible to the community
    • Outcomes of the process are communicated to the broader community
  • We have identified incentives to encourage contributors and maintainers to work toward these priorities
  • We have decided or have a process for deciding which parts of the project will and will not receive maintenance

Scoping

• We have decided and communicated what the project “never will be” - i.e., we have scoped down and communicated the technical goals of the project

Governance

• We have developed a project governance structure
  • The governance structure is published and accessible
    
  • We have discussed and set goals for how the governance structures may evolve as the project grows
    • We have identified benchmarks or measures that are relevant to our community to signal that governance changes may be needed (e.g., low community participation in decision processes; retirements or career changes of key personnel)
      
  • We have discussed whether or not the project would benefit from an advisory board
    • We have developed plans for involving the community in designing and selecting the board

Community Health

• We are prepared to manage conflict in our project
  • We have installed processes for identifying conflict as it occurs (e.g., in online spaces or in-person)
  • We have a project Code of Conduct
    • The reporting process is sufficiently explained and accessible
      
    • We have delegated responsibility for fielding reports and ensuring they are addressed, with appropriate training and resources provided to those responsible
• We have considered and implemented ways to avoid burnout among key contributors and maintainers, including by asking for input from the community

Individual Growth

• There are clear, traversable pathways for users to move to contributors, contributors to move to maintainers, community members to take leadership positions, and other role transitions
  • We have listed or illustrated the skills necessary to move between these roles
    
  • We have strived to make these pathways accessible to all

Resources

Fundraising

• OSS.Fund’s catalog of monetization platforms for open source builders

Developing and Maintaining the Project

• GitHub’s “Setting guidelines for repository contributors”
• PLoS “Ten simple rules for helping newcomers become contributors to open projects”

Marketing the Project

• rOpenSci’s “Marketing Ideas for Your Package”

Managing the Project at Scale

• Center for Open-Source Research Software Stewardship and Advancement (CORSA)’s governance resources
  
• Cloud Native Computing Foundation’s “Roadmaps as a Way to Encourage Contributions”

This resource was generated as part of CZI’s EOSS Community Calls during late 2024 with Organizational Mycology facilitating discussions, gathering input, and generating the final document. Participants in the calls, and open comment periods are given co-authorship in alphabetical order by last name.