In the first 90 days, build the inventory, write a short policy, and open two paths: one for employees to contribute and one for funding critical dependencies. Month one is facts, month two is rules, month three is enablement. Resist building a committee before you know what you use.
Month one: know what you use
- Name an owner and a backup. The Linux Foundation guide says to find a leader with technical credibility who understands the business. At a small company that is a part-time role. Say so out loud.
- Generate an inventory from lockfiles or SBOMs for every repository you ship. See how to count the open source your company actually uses.
- Sort by license and by exposure. Which components ship to customers, which are internal only?
- List the top ten surprises. Unknown licenses, abandoned packages, single maintainer libraries.
- Pick your first three numbers to report monthly. See five numbers an open source program should report.
Month two: write the rules
- Draft a one page policy. See a one page open source policy for a 10 person team. The guide's advice is a well-defined minimal policy, reviewed repeatedly.
- Define license tiers with counsel. See a three tier license policy.
- Add checks to pull requests so the policy runs without anyone remembering it.
- Agree on an exception process with expiry dates.
- Ask for feedback. The guide stresses seeking buy-in from executives to developers. Share the draft with engineers before it is final.
Month three: enable people
- Contribution path. A short form or message to the owner for employees who want to send fixes upstream, with a checklist on confidential code and licensing.
- Training. A short walkthrough at onboarding. The guide mentions one large company requiring a one hour open source class for new engineers.
- Funding. Choose three dependencies from the inventory and pay their maintainers. See which dependencies to fund.
- Evidence folder. Start saving the inventory, policy, exceptions and decisions in one place for buyers and auditors.
- Review. Look at what slowed people down and cut it.
Plan on one page
| Month | Outcome | Done when |
|---|---|---|
| 1 | Inventory and owner | Every shipped repository has a component list |
| 2 | Policy and checks | Pull requests enforce license and advisory rules |
| 3 | Contribution, training, funding | First employee contribution and first payment completed |
Mistakes to avoid
- Forming a board before the inventory exists.
- Writing a long policy no one reads.
- Treating the program as a one-off project with no owner afterwards.
- Starting with release of internal code when you cannot yet describe what you consume.
When to grow it
If the owner spends most of the week on repeated questions, it is time to formalise. See when to form an OSPO.
Where Safeguard fits
Safeguard's SBOM and dependency scanning supports month one, policies and gates support month two, and compliance and evidence automation supports the evidence folder. A free scan is available at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. This is the kind of list month one should produce.
Quick check
Can one person run this?
Yes, part time, with a named backup and support from legal when needed.
What if we find a problem in month one?
Record it, triage by exposure, and fix the worst first. Do not delay the policy while you clean up.
Sources
Last reviewed: 19 October 2026.
