Earlier quoted context omitted.
Open-source projects take a lot of time and effort to do well. They're kind of like startups in themselves, actually. And in this kind of situation, you're committing to publicly maintaining the thing that you're trying to shut down. If there isn't enough interest at the start, it's just prolonging the pain of failure. It's better to rip the bandage off and move forward with your life.
I don't understand why. Strip credentials from your source, dump it on GitHub. It may or may not get picked up by someone else, but this in itself is already better than having the project die. It also doesn't make you committed to anything. So honest question - even if you don't feel like maintaining it later, why not open source anyway?
+ Documentation
+ Structure and organisation
+ Time and effort
I shut my startup and open-sourced our code. But it was hard, very hard.
It takes a significant effort at a time when you've just expended all the effort you have in trying to get funding or a future.
First you need to go through your entire code and ask: What code or assets were acquired under a license that prohibits open-sourcing or re-licensing? This may be a library, or it may be a paid-for webfont, or it may be licensed photos or UI packages. For every one identified, you now need to find an alternative that can be used and implement it before you can open source and remove reference to the old before you open source.
Then there is the documentation, whilst you have a small team of a couple of people who intimately know the code you probably focused more on shipping than documenting. To open source really asks for the documentation more than the shipping... the ability to survive as an open source project isn't just about providing value it is to deliver that value in a way that people can access which means documentation.
Then there is the structure and organisation of the code. The finest example of this is that you probably aimed at the sky and have built a multi-tenant SaaS platform in which most components can scale independently of the others. This stuff is complex to deploy and run, but that's OK as you're probably running only 1 to 3 instances in total. But someone who is a user of your software cares not about this, and just wants it to work for a single tenant with a super-simple deploy process to get started. It is really hard to take a "built for SaaS in a single environment (AWS)" and make it a "built for someone to deploy wherever" thing.
All of the above add up to months worth of time and effort. Time when you're looking at your bank balance and realising that you need a job to avoid being homeless. Time that you simply don't have, and effort that is best focused on finding a job.
When your startup dies, there is certainly a lot that could be open-sourced, but unless you spent the last few months of the startup life working towards that... it is the lowest priority thing you can do.
What you should do when your startup fails:
#1 Focus on you, your health and state of mind. See friends, eat well, exercise, get out of the city if you can.
#2 Get a job. You're super valuable right now and you're in demand. You can build product, manage a team, probably code, and you really should get money in so that you have security and stability you probably haven't had for a while.
Take time, recover.
Worry about open-sourcing, or starting the next new thing, in the future. When your startup fails, now is for you to recover.
Edit: And open-sourcing makes a huge assumption that your investors (who own the rights to a chunk of this stuff) even agree that you can just give away what they invested in.