I work on several projects that I have never used. However, my employer doesn't completely shield me from people who do use it. At least for me, the satisfaction comes from interacting with people who the project helps and seeing how it helps them.
I think part of why (some)? engineers may not give a shit about the project they're working on isn't necessarily because they have no interest in it, but because they haven't met anyone with an interest in it. In github's case, it just happens to be themselves.
I like to know what I'm doing actually matters. Meeting people my stuff impacts helps with that.
My best experiences in corporate IT were when I escaped the department for short times - a flight to an office whose processes were on fire, a deployment of a new warehouse management system where all the workers were counting on me, a 3-month 5-person project sprint to deliver a late, overbudget project without adult supervision.
Whatever the purpose of IT middle management, it does not appear to accomplish much.
I wish I could give you ten upvotes. I get a lot out of interacting with the people that actually use my software. It makes things more personal and that makes me more motivated to work on a project. And the feedback helps to make what they actually want instead of having to second-guess, or build to some abstract specs.
That the project is technically interesting/challenging also goes a long way, of course, but that's not everything.
Worst would be a project that is boring and you don't know whether anyone, including yourself, is ever going to use it.
I think part of why (some)? engineers may not give a shit about the project they're working on isn't necessarily because they have no interest in it, but because they haven't met anyone with an interest in it. In github's case, it just happens to be themselves.
I like to know what I'm doing actually matters. Meeting people my stuff impacts helps with that.