Surviving Project Abandonment: Meteor.js Case Study
summary
Meteor falls near-abandoned after a company pivot and lack of communication but rebounds because a large ecosystem and active forums keep packages maintained and upgrades moving. Key facts: 44,000 GitHub stars, one part-time developer in 2017, community-run Meteor Community Packages and Pacosphere, and a two-year effort to produce Meteor 3 (breaking upgrade from fibers to a single-thread runtime). Recovery uses GitHub Sponsors, Open Collective, OpenSSF / CHAOSS metrics, Open Source Insights, Orbit and Apache DevLake to find maintainers and automate docs and releases.
AI-written summary · about
chapters (12)
- 0:00Introduction
- 1:26What is Meteor.js
- 6:23Meteor’s golden era
- 11:24Community decline and GraphQL pivot
- 14:36Community survival efforts
- 18:40Can open source die
- 21:50Why Meteor survived and lessons
- 24:44Fortifying open source projects
- 29:03Building resilient communities
- 32:36Governance and sustainability
- 35:08Community health metrics
- 38:02Meteor’s future and conclusion
related talks
47mGame of Open Source: A Tale of Hype & Mire
25mThe Maintainer’s Perfect Storm: Survival, Succession, and a Decoupled Future
39mManaging an Open Source Project
58mResponsibly Abandoning Open Source Projects
32mRebuilding the Cathedral
30mOut of Maintenance Mode: Refactoring a Community
25mSustaining Open Source Software: Exploring Community, Financial, and Engineering...
44mBUILD A COMMUNITY, NOT A FRAMEWORK