Making database code open source
This is a good question with a simple answer:
Best practices cannot be applied in every situation.
The best practices of "don't tell the world what security algorithms you use" and also "don't expose your DB structure" exist as a possible fallback- just in case your code has a security flaw in it, it's much harder for someone to exploit it if they don't know how it works behind the scenes. Obviously both of these best practices directly conflict with Open Source, so you should just focus on not having security flaws in the first place. Fortunately, opening your source code will help with that.
Relying on keeping your schema secret to protect your system is not a good starting point. It's not Kerchoff's principle, but if the security of your system relies on the obscurity of the schema, then even if you keep it closed source and don't offer it to anyone else, you have problems.
the script with the connection username/password should not be hosted on the source repository
No.
You certainly don't want to put your database credentials in a public repository but you should put the code for managing and applying them in the report. You could use dummy values in the repo, read them from a flat file or the env, use the defaults in PHP.ini, use user-supplied credentials stored in the session, restrict access to localhost' and not require a password....there are potentially lots of solutions.
However I am unsure how to proceed as I have also heard that you do not want to expose your database structure to others.
You don't want to expose them because if SQL injection exists they know which tables to target. However, if SQL inject exists to make this happen it is a moot protection since your security is already broken. Especially since most PHP/SQL applications in the wild rarely set up proper SQL user permissions. So most times the attacker can make a dump of your structure and have no need to guess at it.
The only thing I'm sure of is that the script with the connection username/password should not be hosted on the source repository of my choice.
A lot of projects get around this by providing a sample configuration and then through their version control software create a rule that prevents their configuration from being pushed to the version control repository. An example of this is they may have an example config called config-EXAMPLE.php and their setup script renames this to config.php (or creates from scratch) as soon as the information for it is available. And if they are using Github for example include a .gitignore rule to block config.php which will ensure they don't accidentally expose their own configuration.
It is currently not open source, but I am considering making it open source, so that others can fix bugs, improve it...
Don't forget security when making this statement. The best thing about open source is others can spot what you don't and fix or improve on it. And this includes security. Open sourcing your project could potentially fix more security issues than it exposes.