Aside from the code: Know your intention. What do you want to achieve by open sourcing? Are you trying to grow your username, gain trust or is it just throwing

Aside from the code: Know your intention. What do you want to achieve by open sourcing? Are you trying to grow your username, gain trust or is it just throwing code over the fence so users can go on while you focus elsewhere. Do you hope for contributions or do you want to continue driving the project? From there you can derive the community management you have to do. The more involvement you want from externals the more you have to invest in community management. (The more you want the quicker and more thorough you have to respond) Then be aware of all the legal things. When using libraries: anything lgpl or gplnlicensed stuff with something incompatible etc.? And then for secrets best is indeed squashing the history. Makes it in the beginning a bit annoying, but you might have code comments or commit messages referring to customers or have experiments with libraries of unacceptable license or whatever in there. Limiting review to recent state is a lot simpler.