Plans · Software
Launch an open-source project
8 weeks · 5 phases · 25 tasks · 5 milestones · 4 risks
For a team or a company releasing code as open source for the first time. The weeks run from deciding the license and cleaning the code through documentation and community setup to a public launch and the first month of issues. Adapt it to how much time you can give maintenance afterwards, because that is what decides whether the project lives.
Makes it a program in your harbor, dated from today.
Milestones
- Week 1License and maintainers agreed
- Week 4Code clean and building
- Week 6Docs ready
- Week 7Repository public
- Week 8First follow-up release
The plan, phase by phase
1. Decide
Weeks 1 to 2. Agree why you're releasing it and on what terms.
- Week 1Agree goals and who maintains the projectName maintainers and the time each will spend. A project with no maintainer time stalls fast.
- Week 1Choose a licensePick a widely used license that fits your goals, and get legal sign-off if the code belongs to a company.
- Week 1Check that you own or can release all the code
- Week 2Review third-party dependency licensesMake sure every dependency's license is compatible with the one you chose.
2. Prepare the code
Weeks 2 to 4. Make the code safe and pleasant to read in public.
- Week 2Scan history for secrets and remove themRotate any credential you find. Consider publishing with fresh history if the old one is messy.
- Week 2Remove internal references and hostnamesSearch for internal URLs, employee names in comments and customer data in fixtures.
- Week 3Make the build work from a clean checkout
- Week 3Set up continuous integration for pull requestsOutside contributors need to know their change passes before a maintainer looks at it.
- Week 4Add a basic test suite if one is missing
3. Documentation and community
Weeks 4 to 6. Make it easy to try, use and contribute.
- Week 4Write the readmeWhat it does, who it's for, how to install it and a first example that works.
- Week 4Write getting-started docs
- Week 5Write the contributing guideHow to set up, run the tests, and what makes a pull request easy to accept.
- Week 5Adopt a code of conduct
- Week 5Write a security policy with a private reporting address
- Week 5Set up issue and pull request templates
- Week 6Label a handful of good first issues
4. Launch
Weeks 6 to 7. Make the repository public and tell people about it.
- Week 6Ask a few outside developers to try it
- Week 7Publish the first release and packageUse a version number that says how stable it is, and write release notes.
- Week 7Make the repository public
- Week 7Write the launch postExplain the problem it solves and show a working example, not just a feature list.
- Week 7Share it in the communities it's for
5. First month
Week 8. Respond quickly so early users and contributors stay.
- Week 8Triage new issues within two working daysA quick, kind reply matters more than a quick fix.
- Week 8Review outside pull requests
- Week 8Publish a public roadmap
- Week 8Ship a follow-up release with early fixes
What usually goes wrong
Secrets leak in the history
Old commits can hold keys or passwords that become public the moment the repository does.
What helps: Scan the full history before release, rotate anything found, and publish fresh history if needed.
Likelihood 3 of 5 · impact 5 of 5
Nobody has time to maintain it
Unanswered issues and pull requests make a new project look abandoned within weeks.
What helps: Agree maintainer time with managers before launch and set a response target you can keep.
Likelihood 4 of 5 · impact 4 of 5
Hard to get started
If the first install fails, most people leave and don't come back.
What helps: Have outside developers follow the readme from a clean machine before launch and fix every snag.
Likelihood 3 of 5 · impact 4 of 5
License or ownership problems
Code the company can't release, or incompatible dependencies, can force a takedown.
What helps: Get legal sign-off on ownership and the license, and review dependency licenses before going public.
Likelihood 2 of 5 · impact 5 of 5
Using it
Copy what fits and cut what doesn’t: no real project matches a template. In Harbor the plan becomes a program with these milestones, one project holding every task with its due date, and these risks in the register, all yours until you hand them out. The first phase starts in To do and the rest wait in the backlog.
Open this in HarborMore plans
- Ship a mobile app v114 weeks · 28 tasksA 14-week plan for a first mobile app: scope, design and user tests, build, beta testing, then store review and release with crash reporting in place.
- Run a round of customer research6 weeks · 23 tasksA 6-week customer research plan: research questions, recruiting, a discussion guide, interviews, synthesis and a readout with decisions.
- Migrate to a new database10 weeks · 26 tasksA 10-week database migration plan: inventory, schema mapping, sync and backfill, verification, staged cutover, rollback and decommissioning.