I would call Parse a "Backend as a Service"[0], akin to Firebase[1]. "API as a Service" is more like Apiary (bought by Oracle) or Apigee (bought by Google).
The first iOS app I built used parse for the entire backend. We basically used it as a database in the cloud accessible by multiple clients (it can accommodate fancier uses as well). We didn't really run any custom code on the server side, Parse basically provided access to a shared db across our client instances. It allowed us to build a simple location sharing app in a few hours.
From my understanding, it provided services that you would have to create from scratch in your own infrastructure that would be a significant undertaking. For instance, push notification in iOS is a bit of a nuisance if your app really doesn't rely on a complex server back end, but you would like to still add push notifications. Parse did this portion for you, so you could focus on the product. I could be wrong though, I looked at it a year ago, and my memory isn't what it used to be.
It was basically a CRUD API as a service; simple object storage and retrieval via HTTP, with goodies like validation and nested routes (joins) and such built in.
And if I download the open source code, and run it on my own server, is it a service as a service as whatever-the-opposite-of-a-service is? I'm confused...
You're thinking too small. Support it multi-tenant on a fleet of servers and sell it to customers, now you've got a service-as-a-service-as-a-platform.
[0] https://en.wikipedia.org/wiki/Backend_as_a_service
[1] https://firebase.google.com/docs/