He could at least meet with someone who had worked on the project.

Yeah, this is not the organization that should be acting as de-facto curators of the Internet, I'm thinking. What's being described here isn't a cathedral or a bazaar, but a bureaucracy.

More often than not, if you had touched the code, it was because someone had decided to replace the way services do user credentials in an incompatible way and someone told you had to make this code work with the new scheme, by the end of the month because it was holding up shipping the new user credential protobufs... so you ended up in the code with a gun pointed at your head saying "go fix this code you've never seen to use this new API that the code never anticipated calling."

Probably wouldn't make you want to go back "just for fun."

I just don't see why they couldn't have just left it running as-is, without any support.

Differently, Reader does not seem like the kind of app that would inspire a lot of uniquely hard engineering problems. (I.e., any hard engineering problems would probably be shared by several other Google services.) That seems to suggest that far fewer engineers would be attracted to working on it exclusively, and any that did wouldn't have any significant investment in Reader as a product.

There are valid reasons to discontinue even a mature product with a reasonable amount of success, populist or monetary. I dislike that Google declined to share those (though I sympathize with the managing principle of "just do it; don't explain why"), but I doubt I'd run any company the way Google is run in the first place, so my opinion on that front isn't really useful.