As people noted in last months / years... the worlds OS, apps, developers, and tech oriented operating system / repo / code / porters eyeballs users and interactors have more or less moved en masse to git, primarily on github, often augmented by running their own git copies in house if they are a large project.
It's unlikely under what is now an ecosystem settled into git, that any new talent or otherwise will bother trying to use monotone or any other repo to fetch patch hack commit etc on anyones code, regardless of whether that code is an OS, a repo, or an app. It's the language problem, if you are one speaking Z, in a world where everyone else speaks only A, you will need to adapt to them. If monotone wants to survive in a compileable state across OS, to maintain an example presence that alternative repo embodiments are available that do run and can be studied and tried out, it needs at minimum... a) A tarball release that compiles against the latest versions of all external libraries, and on the latest release of FreeBSD and Linux-Debian. and b) A github repo (and ticket system) that is considered an "upstream" that can be interacted with and that will accept maintenance patches from the OS and userspace. and c) Some public FYI blurb advert when doing those interactions, and in the topline of the toplevel README, that monotone is accepting new maintenance / dev people. No one lives or maintains forever, thus wise continually seek new eyballs and people in wherever the new places are. Otherwise monotone dies. If there are compilation and bug patches out there waiting to be applied, and tarballs with them needing cut, then someone or some group throwing a monotone continuance project up on github and working those things there is probably not a bad idea.
