Continuing the discussion from Subjam (@subjam@mastodon.subj.am):
This is part of the reasoning behind Eric Ramond’s famous hacker maxim; release early, release often.
If you develop in public right from day 1, and commit code to your public branches in small, frequent chunks, you will be motivated to make sure your code is always well organised, thoroughly commented, etc, etc. Because people might read it 
Side note: A friend once told me that he writes comments first, until the algorithm makes seems to make sense and do everything he needs, then goes through and codes each comment underneath it. This is even better than using pseudocode, because you can just use natural language, and it gets the comment writing over and done with. Making it a useful and therefore fun part of the development process, instead of boring chore.
Knowing it’s in public also reduces the temptation to build up technical debt by throwing stuff on the ‘tidy up later’ pile. This makes your code easier for you to read, which can end up reducing both development time and maintenance work. How many times have you come back to a file you haven’t worked on in a while and thought; who the hell wrote this, and what were they thinking? 
The other result of all this is that because you’re putting more thought into architecture and code structure, and paying more attention to detail (to avoid embarrassment when people read your code), you tend to have fewer complexity bugs, race conditions, and security holes. Which leads us to another hacker principle; security by obscurity.
It seems obvious on the face of it that if people can’t see your code, that makes your software more secure. But counterintuitively, the opposite is true. People who exploit security flaws generally find them by analyzing the software in production (with various cracking/ pentesting tools), whereas the people who find them by reading code are much more likely to file a circumspect bug report on the subsystem that’s causing the problem, or if it’s a critical bug (like the recent PHP one), do a responsible disclosure.
So the best time to publish your code is the day your start writing it. The second best time is today. Once your code is published (AGPL is what I would use, but that’s not legal advice ), you’ll be amazing how motivated you are to do some quick-and-dirty tidy refactoring, so that it makes some kind of sense to an outside reader. Every bit of tidy-up from then on will be easier by comparison, and you might even get help to do it.
As for security concerns, I think Linus’ Law is relevant here; ‘given enough eyeballs, all bugs are shallow’. If you do have any security holes, they’re more likely to be reported, and maybe even patches submitted to fix them quickly, if the code is in the open. If the code is not published, all those flaws are still there to be found with cracking tools, but they’re less likely to be discovered and fixed.
One caveat though: Before you publish, check your code to make sure there are no secrets (eg passphrases, security keys) stored in the repo. If there are, make sure you abstract them out into a separate repos for your committer tools, and your production system, and double-check before hitting publish.