releasing-oss-strategy.md

This is a teaching tool for people new to releasing OSS, or who want to revisit their goals for existing projects.
This does not include guidance for licensing, compliance or other specific legal or business policies

Introduction

Open collaboration is an opportunity for innovation beyond what's possible within a single team or company. It's an opportunity to hear from and work with customers, to test use-cases, engage with developers extend brand recognition and gain diverse contributions. This is true for Open: source, science, education, access, data government and beyond.

The Open Way

While there is no one way to approach opening your project, there is shared knowledge within the ecosystem that you can build on to think and act more strategically. To ensure that your goals for an OSS project are strategically aligned with your business goals, based in the reality of your resources, focused on the jobs needing done, and communicated effectively. Specifically this is a continual cycle.

This playbook will take you through that release and renewal cycle, to ensure your success.

Step 1: What Problem Are you Trying to Solve?

You should never throw a project over the wall. By that we mean releasing a project without explicitly having thought through or committed to the success of the project beyond the initial release; furthermore thinking of it as an opportunity to fill gaps, or obtain free labor. Without strategic goals, projects thrown over the wall become abandoned. That's a terrible experience for collaborators and looks bad for your organization.

One reason might be a recognition the domain expertise your project needs to grow isn't found in-house.

Open source is our gateway to be able to collaborate and gather these insights; bridging the gap between computer science and industry experts.

Another might be for cross-platform efforts, which require a community collaboration.

Step 2: What is your Collaborative Focus?

Whether you have one, or one million people willing to collaborate, success will only come with being clear about who it is that you need to collaborate with to solve the problem you've identified. Who are those people: Potential customers? Ecosystem partners? Developers? Localizers?

Working side, by side with customers, for example, can allow a team team to rapidly experiment and co-build new features independently of the main product release cycle.

Where can you find these collaborators?

If you build it, there is no guarantee they will come! Think about where your collaborators are, so that you can be strategic in outreach during the planning phase.

• Universities and colleges
• Start ups
• Industry events
• Diversity-focused tech organizations
• Tech-specific Community Meetups
• Following specific hashtags on social media
• Regionally specific (in countries and speaking languages)

Step 3: What are the Jobs to be Done?

Now that you know who you want to collaborate with, it's time to ask - what needs to happen to make that successful?

Success is a two-way street. You will need to entwine your project and organizational needs with the community needs. What are the Job's to be done?

...by your collaborators

Think about the types of activities that you need from your collaborators. Some examples might be:

• Documentation
• Proposing new workflows
• Testing/QA
• Opening issues (bugs, feature requests)
• Developer advocacy (sharing successes and enthusiasm on social media)
• Translation/Localization'
• Community building

Try to pick one or two up front to focus on first. You can always, and are encouraged to revisit.

...by your team to enable collaborator success

Looking at the jobs you need from your collaborators, ask yourself "What do we need to do to make collaborators feel successful?"

• Responsiveness to pull requests
• Creating content for sharing
• Developer scripts
• Mentorship

Step 4: What Skills are Needed?

For each job to be done, what skills (minimally), must people have to be successful? What gaps might exist for someone slightly less qualified?

Technical skills are important, but what makes a community thrive involves empowerment and care for people.

Step 5: Make a Plan (time/people/resources)

Now that you know who/where/what it's time for how!

Minimally, you should allocate time for issue-responsiveness, and to communicate project updates (via README or Discussions). This will ensure that the experience of interacting with your project is positive and people will want come back

Some other things to consider when planning:

• Time zones

• Languages

• Skills

• Vacation time

• Moderating a GitHub repository Check out the Moderation Pocket Guide

If during this step you realize, you do not have enough time. Go back and set more realistic goals. You can always change them in future.

Step 6: Communicate in all Directions

Communication is everything. This is true for your collaborators, for your manager, and their manager and your peers.

"Every time there's a lack of communication, people fill in the gaps. They tend to fill them in with whatever fear, uncertainty, or doubt they have in their heads" - OSS Maintainer

Some metrics for your team to consider tracking:

Contributors

• Ensure your README.md is always up to date. Make sure you are as clear about what type of collaboration and contribution you are not able to support in the moment, as those you are. This helps people avoid investing time in the wrong place
• Communicate any planned, or unplanned absences of maintainers to manage expectations.
• Setup a bot, or empower a community member to welcome every new contributor - this can be via a separate chat channel or right in issues and GitHub Discussions.

Managers and Leadership

• Regularly, report the impact of external contributions on business goals. If you're feeling challenged to do that, have a conversation with your manager to align. Don't wait for those conversations.
• Be honest about the time you are investing, and set goals for that as well. Burnout helps no one.

Cross-Organizationally

• Keep internal collaboration a focus as well, share your goals and bring others in who might have similar. It's always possible to get more resources and internal contributions this way!

Externally

• Write, blog, share even when its early days.

Step 6: Measure

Some of the tools below can provide you with tooling for metrics insights.

• CHAOSS Tool: This is a community tool which provides some of the most popular metrics for a given GitHub repository. They're also open to new requests, and improvements via the CHAOSS community.

What does success look like for each of the jobs to be done, for you and your collaborators? Look back at the jobs to be done for your team and your collaborators? Pick one metric for each, and check in each week. Some considerations:

For your collaborators

• New contributors
• Number of new issues and/or pull requests in the specific area you need help (i.e. documentation prs)

For your team

• Time to first response
• Contributor onboarding progress (qualitative)
• OpenSSF Scorecard results (GitHub repos scores available in the Open Source Portal)

Step 7: Repeat and Renew

Releasing a project openly is just a beginning, it's something that needs regularly revisited. It's a renewable cycle:

• Is the problem you're solving still the same?
• Are you still focusing on the right collaborators, jobs, skills and metrics?​

At times it may be true that your project is no longer an investment you want to continue, and that's OK too. We'll include a documentation on sunsetting and/or transfiering an OSS project in future.