I find the premise itself to be a bit worrisome, and it comes down to one of your opening sentences:
"On my part, this would become a part of my public portfolio in the future."
The issue with this mindset is that you start treating the project less like a building block of your companies solution, and more like this pure expression of your programming ability. You have to reflect what will happen when you need to commit code that doesn't pass what you consider good enough for your portfolio. Or even if your coworkers do.
To be honest, if I'm looking at a candidates code, I want to see what they have coded outside of work, when they have freedom to express themselves, and not have potentially unknown factors influencing the code that I see. If a candidate cannot point to external projects, and can only point to code done between 9 - 5, that would reflect poorly on them.
There is a cost to open-sourcing. Some flexibility is removed. Risk is increased. You really need to ensure your suggestions include sections of code that actually would benefit the open source community. This means code that has a clear purpose, a clear scope, and applicability to other projects.
Your companies implementation of some miscellaneous business logic is quite different from a project which provides an easy to integrate solution to a problem that other entities have.
In addition, if your company creates a project with the same purpose as other popular open-source projects, it really has to be unique and compelling in some way. Otherwise it will just seem your company suffers from a bad case of NIH syndrome, which goes against many of the points you have raised.