The rules for building a successful open-source project are pretty similar to those for building a successful startup: make something people want.
Glancing at the project description, the biggest problem I see is that pretty much the only value provided is "my own opinions". I have my own opinions; I don't need yours. I don't even use the widely-used boilerplate packages like Twitter Bootstrap because invariably they do something contrary to the needs of my site, and then ripping them out is more effort than not using them to begin with.
I've got a couple moderately-successful open-source projects with Write Yourself a Scheme in 48 Hours [1] and Gumbo HTML5 Parser [2], and what they have in common is that they solve a problem that people have that they're too lazy to fix themselves, in a way that takes less effort than diving into the problem would. In Write Yourself a Scheme, that problem is "I want to learn Haskell", and the lazyness is "but I don't want to have to butt my head against these annoying monad things, and specific API calls, and undocumented type-system corners. I want all that explained to me." For Gumbo, the problem is "I want to parse HTML", and the lazyness is "but I don't want to spend my time implementing the 400+ clauses of the spec".
If you think in terms of "What can I do for other people that they don't want to do for themselves?", you will end up with many more users. Projects that do all the fun stuff but none of the hard stuff end up fun, but useless. Projects that do all the hard stuff and leave the fun stuff to other people get used.
[1] http://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_H...
[2] https://github.com/google/gumbo-parser
