The reason this project (and many others like it) exist is pretty obvious: Lots of people have to build different kinds APIs using rails, get some experience with Rails, discover it sucks for building APIs out of the box (to much anti-DRY repetition, doesn't deal with auth/permission dichotomy well), and then proceed to roll their own API layer/Auth layer/Permission layer because either:
a) information on existing solutions is hard to find/not obvious or otherwise in the world of unknowns to the author
b) existing solutions are too generalized or otherwise structured in ways that don't work for whatever real world particular business cases.
I ran into this with permissions in my current project. Nothing obvious in my realm of knowledge fit (sometimes I suspect this happens because projects only advertise their basic features clearly). So I now have a massive custom permission layer.
Sometimes you also end up with things like this by accident - you need one thing, it's not worth going whole hog to begin with, but then suddenly stuff gets tacked on until you have a whole system you never set out to build.
I tried emacs a few years ago when the peepcode on it came out. It's a full blown OS with a text editor! I managed to get my work done, but it wasn't for me. I went back to Textmate for another few years, and am now happily using vim with tmux. I might try emacs again in the future.
1. The data is now available under the MIT license. This is important because (a) it is a predictable, well-known license that allow businesses to interact with the data without fear of the unknown (license) and (b) it does not have the "you must remove our data if we ask you to" clause that their data portal has .
2. They're actively seeking contributions from the community. None of the existing data portal tools have a built-in way of doing this, so they went with GitHub because it's a step in the direction of taking feedback. Is the data wrong or lacking something? Add it yourself and submit a pull request.