Hacked up code is all fine and good, but what I'm looking for are the tools that are necessary to make it easy to consume the code:
* Stable, versioned releases, with sufficient API (if not ABI) compatibility across releases.
* Accurate and complete API documentation (with bonus points for higher-level integration documentation.
* A bug tracking system
* Mailing lists.
These are all historically accepted best-practices that have (and continue) to serve the OSS community well, but they're also practices that are strongly and innately de-emphasized by github's "code first" UX.
If github (and git) were facilitating the production of marvelous new libraries and software that we'd never seen before, then maybe I'd acquiesce that it's worthwhile to abandon the best practices above.
That, however, has not been my experience. Most of the code is poorly maintained, often abandon-ware, and with unclear lineage. It's unknown which of the 50 forks is the best one to use at any given time, and what the ongoing costs will be to track unstable development branches directly, since there are no releases.