How to handle abandoned projects, Take Two
summary
A practical, experience-led runthrough of what actually works when code becomes abandoned: explains that GitHub fork is not a real fork (issues disabled by default, commits don’t count on your graph), shows how to transfer ownership (preserves issues/commits and creates a 301 redirect), warns about licensing and pulling competitor code, recommends the no maintenance intended badge, and frames choices against concrete risks like Python 2’s EOL and one maintainer’s redundancy story plus community-and-mental-health lessons learned.
AI-written summary · about
chapters (19)
- 0:00Katie McLaughlin How to handle abandoned projects, Take Two
- 8:40Just fork it!
- 8:55GitHub Faux-forking Licensing 'Competitor' Code Dead Source
- 10:29Limitations Parent Lock-in Default Pull Requests No Issue Logging by Default
- 11:03GitHub Repo w/out LICENCE?
- 11:31Stackoverflow Code? MIT Everything else? CC-BY-SA
- 13:03But why should you care?
- 13:30Ruby 1.8, 1.9.3 EOL
- 15:30Porting is boring but it's imporant
- 15:43Google Code Read Only
- 15:55SourceForge
- 16:21Projects are going to need attention
- 16:44Abandon Responsibly
- 17:13Mark as inactive
- 18:17GitHub Ownership Transfer
- 19:22Benefits All the PRs, Issues, Commits stay 301 Redirects to new URL You get the commit bit
- 20:08Restore Dead Code Check their README Is it inactive? Is there a better solution? Could you be the new maintainer?
- 21:33What did I choose?
- 23:21It's okay.
related talks
58mResponsibly Abandoning Open Source Projects
29mTaking over Someone Else's Open-Source Projects
05mAdoption Agency for Abandoned Repos (AAAR)
29mDon't Be A Hero: Sustainable Open Source
27mTaking code to next level with Open Source (Git & Github)
31mMaintaining a big open source project: lessons learned
51mMy awesome journey with Open Source
22mLessons from HasGeek's FOSS Journey