While I generally do favor service oriented architectures (and remote work), this is woefully short sighted.
Say the remote worker builds you a shaky RoR+MongoDB app, no scalability, no error handling, no tests, no comments. At least in the short run, it works - there are occasional outages, but the worker (remote or otherwise) does a great job keeping it going. Then the remote worker quits. What do you do?
Just because something is behind an API doesn't mean you don't have to worry about knowledge transfer, code quality, etc.
Okay, good points ;-) I may have overstated my case for emphasis; but I maintain that in general, an API is better than a library (there was an article saying just that some time ago on HN; can't seem to find it right now).
I wouldn't even go that far. "API" and "Library" are not distinct concepts. A library has an API - it's the set of public functions (ideally rarely changing) that you are supposed to call from external programs. It is beneficial if one developer can hide their work behind a simple interface with only a few access points (the API), but there is no compelling reason this should be json over http.
The real distinction between a network API and a library is that the network API allows users to avoid thinking about the hardware. The API provider is responsible for allocating hardware, the user need only send messages over the network to use it. I.e., buying hard drives is Amazon's problem, I just GET/PUT my files onto S3.
If the API isn't hardware intensive, this is pointless - you are adding network overhead (i.e., latency, network errors) for nothing.
That just opens another can of worms. Now every single application you either provide or use come with an integration issue attached.
I have read somewhere that was the Amazon way of doing thing but it was a costly investment. A costly technological investment. And even Amazon did it only at team level, not individual level.
I cannot imagine a 500 developers company being able to afford that without some serious competitive advantages down the line. If what I can see around here is any indication (medium size IT company in London), if you can afford not having people on site, there are better opportunities to take in Poland or even India than a small discount on a UK worker.
Unfortunately, a network API letting you mix and match languages still opens up risk from a rogue employee who uses something different than the status quo and then quits, leaving something unfamiliar that needs to be maintained.
Say the remote worker builds you a shaky RoR+MongoDB app, no scalability, no error handling, no tests, no comments. At least in the short run, it works - there are occasional outages, but the worker (remote or otherwise) does a great job keeping it going. Then the remote worker quits. What do you do?
Just because something is behind an API doesn't mean you don't have to worry about knowledge transfer, code quality, etc.