I've never heard of anything like that. Although you don't explicitly say, I assume you have a function in your IT department that controls commercial software with the intent of avoiding duplication. Since Open Source software doesn't require that control, it is much more likely that it will be used in redundant ways, and that various internal organizations are "reinventing the wheel".
The PM answer is that this information should be documented as an organizational process asset. If you have a PMO they should be interested in capturing this kind of information as part of lessons learned.
One brute force approach would be to develop a library of requirements rather than a library of software. e.g. *37 different organizations have stated a "Must have" requirement for software with an API to manipulate Gantt Charts; 30 of them use Microsoft project, 4 of them usr LibreOffice, and 3 of them use an open source SaaS product.
Probably a better approach would be to work through enterprise architecture. EA is often summarized as just the description of ASIS and TOBE, but it should be capturing the technologies that bridge between the two. You might contact Troux; see if they have a solution, and then work down their competitors. I have no affiliation with them, and don't use their product, but they are recogzized as a market leader
A third approach would be to approach your cybersecurity office. In theory they should be assiduously collecting and maintaining a list of the software in your environment. A fully mature cybersecurity program would also take notice of internally developed software.
A fourth approach is to capture this as part of your knowledge management efforts. The few times I've dealt with people who are knowledge management guru's they advocate capturing information like this. Unfortunately, I haven't yet seen what I would consider a mature knowledge management initiative.
