This may look like an attack on the winamp owners, but it is not. They just made so many different mistakes that they were the obvious example to use, but many other companies make some of the same mistakes.
The first thing you have to do is decide exactly what you want to do, and make sure you have someone in your project who knows how to do it. You then put them in charge of all communications surrounding it, and when they tell you that what you are doing is wrong, listen to them. Way too many projects get this wrong, sometimes in spectacularly messy ways.
Part of this persons job is to manage everyones expectations, so choosing between copyleft, open source, source available, and deciding not to do it is extremely important. I've listed them in order of decreasing expectations from your users, and one of the worse things you can do is to over promise and under deliver. This choice should be made in private, after you consult the sort of person suited to become your spokesperson, so they can tell you the consequences of each option for your project before you make the choice.
Once you have decided what sort of release, and which version of the code to release, the next question is how to do it. With a few special case exceptions, the only ways to do it now is using version control, which if you are just adding it means using git. Get your consultant to explain how it works, and go through everything and see if it should be in the repository before making it public. Once it is out there, it is almost impossible to hide it again, so one of the factors in deciding when and if to go public is when you have removed everything that should not be there, and it still builds working code. Because this also means removing proprietary libraries, this in itself might stop you from being able to release working code, and if you did not tell anyone it is easy to walk back the decision.
Some files just should not be in your version control in the first place. The most common mistake projects make is adding them in the first place. The next most common mistake projects make is not removing them. The next most common mistake after this is thinking that removing the file from the working directory is the same as removing it from the repository. If you make any of these mistakes and publish without fixing it, you cannot call it back later, which has consequences.
The most important thing to remove is the keys for signing the code. If you actually release them, then anyone can add something nasty, use your key to sign it, and pretend to be you, causing all sorts of problems for you, and lots of bad publicity. The only way to fix it is to invalidate those keys and create new ones.
The general problem with this is that you do not own them, and are often restricted in how you distribute them or even if you can. In either case, it can have legal consequences if you get it wrong, which can be severe.
winamp got this spectacularly wrong by releasing code belonging to microsoft, intel, and dolby, the later of which even said it was under a non-disclosure agreement.
For open source libraries, there are restrictions on what code you can release, and which licence it must be under. Again they got this badly wrong, including gpl libraries, meaning any code using it must also be gpl licenced.
Depending how clueless the developers were, they might have large parts of the code which cannot be released, even more which must be released as free software, and in the worst case, code which you cannot ship as a product as it would require proprietary code to be shipped as free software, and good luck getting someone like microsoft to change their licence for you.
Again, all of this needs fixing before you put the code up online for everyone.
For most tools in general, and third party tools in particular, you probably do not have permission to distribute the code, which in any case will go out of date very fast. This is ignoring the fact that for some things like version control software, you already need it to get it out anyway.
The only real exception to this is scripts and little tools you wrote yourself for this code base, which are not used by any other project. Once it is also used elsewhere, it needs to be in its own version control.