* focus on documentation. Good documentation is the thing that differentiates good open source from bad open source.
* separate out all things external. This includes services, dependencies, and especially ads. Manage them like managing a foreign business partner.
* provide a demo tool if applicable.
* focus on code organization. My applications are well organized large files. This scares the shit out of people who don’t really read code but is preferred by people who do read code, so know your audience. I would rather a drastically smaller audience of higher quality interested people but that makes your application appear less popular.
* automate everything. If automation is not a primary consideration your code is just a toy.
* everything is broken. Encourage challenging critical feedback
I should say, I'm also open to any resources like articles/podcasts/talks on this topic.
In line with the "release early, release often" mantra, you can just go ahead and do it.
Secrets are usually split into separate "configuration" repositories that remain private, and that's the only gotcha.
Any other time you invest in beautifying your code, writing documentation, stripping ads and making them configurable, might be in vein: most open source projects do not attract any contributors, yet having these "easy pickings" is also stimulating for someone to contribute.
Your users are better served having an ability to tinker with the code than waiting for the code to become nicer. At least, the free software persona in me says so :)