Maintaining SYB fits well in this idea, and if no other natural maintainers volunteer, I (with some support from the other people at Utrecht) am happy to take it upon me. I probably won't do heavy development on the library, but including patches, and providing support is fine. We're also planning to maintain EMGM here in Utrecht, although we didn't develop that ourselves.

Recently, (at least) Claus and Oleg have been posting interesting suggestions of improvements/modifications to SYB. Those should be further analyzed and discussed, and finally introduced (or not) in the library. The generic map for SYB, for instance, evolved from the "impossible to implement", through the "unsafe implementation", until the latest gmap2 as described by Oleg [3]. If further tests show this function behaves as expected, then it's clearly a good candidate for extending SYB. We should also rethink if other things previously deemed impossible remain so.

Maintaining SYB, alongside with the other generic libraries, will require things such as:
 * Releasing packages in Hackage, properly documented with Haddock;
 * Updating such packages as necessary for new releases of GHC;
 * Writing examples of how to use the libraries (from a user perspective);
 * Writing testsuites, which are important for checking backwards compatibility of any changes;
 * Having an updated webpage linking to the library sources, documentation, possibly a bug tracker, etc.
These are all things we plan to do for the libraries.