What Kind of Open Source Help Do We Need?

Open source questions often arrive with the wrong label. A “security issue” may really be an ownership problem. A “policy problem” may be a workflow problem. A “community question” may be a stewardship question. A “tool evaluation” may actually be about procurement, data, and public trust.

This guide helps teams name the kind of help they need before the work becomes too broad.

When You Need to Understand

Start with understanding when the main problem is visibility. Something has raised questions, but the team does not yet know enough to decide.

This often happens after an SBOM, package list, vendor claim, security scan, dependency concern, or leadership question. The useful first step might be a project health review, ecosystem map, dependency scan, or short decision brief.

Understanding work should reduce uncertainty. It does not need to become a permanent research project.

When You Need to Adopt

Adoption work fits when the organization is deciding whether to use, buy, pilot, replace, or phase in an open source tool.

The real question is rarely just technical fit. Public-sector teams also need to think about procurement, security, privacy, accessibility, maintenance, records, support, and service delivery. A small pilot is often the right first move because it creates learning without committing the organization too broadly.

Adoption work should help the team decide whether the tool fits the real operating environment.

When You Need to Sustain

Sustainment work fits when open source is already in use, but the routines around it are uneven.

This may look like unclear approval paths, policies nobody uses, repeated exceptions, inconsistent SBOM practices, missing owners, or uncertainty about who handles updates and escalation.

Sustainment work is usually practical and operational. It makes existing use safer, clearer, and easier to repeat.

When You Need to Participate

Participation work fits when your organization needs a healthier relationship with the people and communities around a project.

That may mean preparing for a maintainer conversation, clarifying contribution rules, mapping peer organizations, or deciding how staff should show up in public project spaces. It may also mean recognizing that “community” includes more than developers, especially when public services are affected.

Participation work should make the relationship more respectful and useful for everyone involved.

When You Need to Steward

Stewardship work fits when a project has become shared infrastructure or when your organization has a responsibility to help sustain something others rely on too.

This is not always a large formal effort. It might start with critical project triage, support options, sponsorship, peer convening, or a shared governance conversation.

Stewardship work asks what kind of care the project needs and what role your organization can responsibly play.

When More Than One Fits

That is normal. A dependency question may start with understanding and move toward sustainment. An adoption decision may uncover stewardship needs. A policy concern may require participation with maintainers or peer organizations.

Choose the first step that answers the most immediate uncertainty. The goal is not to label the work perfectly. The goal is to help the next decision become clearer.

Next step: Talk through a first step.