Plan to fork (So you don't have to fork)
summary
Writing a detailed plan to fork acts as a disaster recovery checklist: enumerate triggers (license change, vendor gravity, stalled maintainers), count how many engineers and non‑dev roles a fork actually needs, and start hiring or funding contributors now. Track contribution timelines at Apache/CNCF projects, use a dedicated org like Amazon contributing for collaborative forks, budget CI and marketing, and expect running a fork to cost 2–5× more. Case studies include the OpenSearch fork and Redis/Valkey split.
AI-written summary · about
chapters (14)
- 0:00Introduction and background
- 3:59Forking terminology explained
- 6:27Fork as disaster recovery plan
- 8:33Governance imbalance triggers
- 13:12License change risks
- 16:21Lack of control in projects
- 17:46Slow contribution responses
- 19:33Creating a forking plan
- 23:08Building community capacity
- 23:28Marketing a corporate fork
- 25:14Governance and budgeting
- 26:38Milestones and timeline
- 27:21Naming a new project
- 27:42Summary and call to action
related talks
44mFORK IT ALL if You Fork It
11mRules of Engagement for Forking a Dependency
32mYou Never Know When You Need a Fork: Lessons Learned Building...
06mHow the Fork Do I Contribute to Open Source
19mFork It for Fun and Profit
32mA Fork to Reckon With: Minimizing Friction When Adopting OSS
29mOpen Source Contribution - How does it even work?
25mYou Never Know When You Need a Fork