> However, I can also foresee a lot of technical and legal complications, not to mention potential maintenance burdens.

Shouldn't have a maintenance burden. That burden will be extinguished with the corporation.

If I were you, I'd put it on github with a corporate account, leave a readme that it's abandoned and then mark the repo read-only.

Let (interested) customers know and encourage them to fork it. Disable issues and pull requests before you publish.

Alternatively, put a source dump on your website, and let people know they can put it on Github, but you're not doing it. If nobody republishes it before the corporate site goes down, it is what it is.

I wouldn't do it. It'd be like a dead lover. Don't get suckered into prettying up her corpse on the off chance your opinion of necrophilia changes.

I believe the Haiku people open sourced after their company was down, I saw it as an act of good faith towards the people who trusted them, I say try open sourcing it, who knows what the future holds...

Open source but make it clear that the project will not receive any updates. If any of your clients want to pick it up they will be able to fork it.

> Legal complications

If your code was written by you and you are not infringing on any patents and you don't have any client data in your repos, you should be fine I guess, but I am not a lawyer.

Just make it MIT and open it to the public. Make sure there are no keys or credentials in the repos either.

I would recommend you make it open source. I've also done this the past as well. Even if it's a project that is not maintained you don't know how it might help someone else.

This really depends on what field the product is in.

In my opinion; if you can't sell it you could also try to hand it over to another company / third party. Finding someone to take over a project takes a bit of time but it'd allow for it to survive.

However you need legal advice, fast. First talk to a lawyer who understands this.

I would suggest putting it out as open source with a permissive license that don't require upstream commitment.

Because you don't want to become a maintainer. Just make it clear that it is provided as-is, without support.

It does after all represent a lot of value having been poured into it, worthy of a better ending than rm -rf, even if it didn't reach break-even.

> some of our most loyal users are now asking us to open source it

In exchange of the code ask them to make a non profit organization and handle the rights to them. They will be responsibles for their security in case of vulnerabilities.

I think it could be a nice emotional ending to the journey if that's where you are. At least it's 'out there' in the world and you can move on. I'll be a one time effort to get it out there, but then can be community supported.

[random advice from the internet]

If you really want to put an open source project out in the world the right way, taking what you learned and building an appropriate code base might be a better route.

And if you don’t really want to put an open source project out in the world, that’s okay.

Your customers had an interest in paying you enough to stay in business. They did not pay enough (and maybe because you did not charge enough).

And to me, it seems like you are probably ready to move on and now is probably a good time for moving on. Good luck.

See if you can put it under the [a]GPL and create a consulting niche around it.

See if you can auction it off - at least you'll make some money that way.

What is the product and source code about?

Sell it to a customer for pennies (or more, if they're willing), have them/allow them to open source it.