  One of the biggest strength of many modern programming languages is their
rich open source package ecosystem. Indeed, modern language-specific package
managers have made it much easier to share reusable code and depend on
components written by someone else (often by total strangers). However, while
they make programmers more productive, such practices create new health risks
at the level of the ecosystem: when a heavily-used package stops being
maintained, all the projects that depend on it are threatened. In this paper, I
ask three questions. RQ1: How prevalent is this threat? In particular, how many
depended-upon packages are maintained by a single person (who can drop out at
any time)? I show that this is the case for a significant proportion of such
packages. RQ2: How can project authors that depend on a package react to its
maintainer becoming unavailable? I list a few options, and I focus in
particular on the notion of fork. RQ3: How can the programmers of an ecosystem
react collectively to such events, or prepare for them? I give a first look at
an emerging model of community organizations for the long-term maintenance of
packages, that appeared in several ecosystems.
