Yes, in theory you can get in contact with them and fix their code.
In theory. I tried. They don't listen, they are not approachable. And regarding their code, it is horrible.
Now, you can have one of those, not being approachable or having horririble code, but both at once is a disaster. If your code is great you don't need to listen, but if your code is bad and you don't listen then you will forever wade in your own feces.
I know at least one open source project where they managed to turn their attitude around. I was hoping CERN's big name would manage to initiate this for KiCad. The project I think about is Libre Office.
When Libre Office forked from Open Office the first thing they did announce was a huge code cleanup event of the rotten OOo code they forked. How did they do this? They did let the experienced programmers they did lure away from OOe define small, tiny work packages (and some more difficult ones, too). Defined so new programmer not familiar with the 20 year history of the code could do them. And because they were defined by the LO project the people who took up the tasks knew their contribution was welcome,and they wouldn't in the end have to beg the project to have a look at their contributions.
Tasks for graps were as simple as "We have this file where there are five unused functions. Remove them and commit". They still continue with this,
https://wiki.documentfoundation.org/Development/Easy_Hacks#Entry_level_Hacks They welcome new programmers to the project and give them meaningful tasks. Unlike KiCad, where they don't seem to recognise they have issues with their code base and their talent, and not every potential contributor is a tenured professor or from CERN, who has to much time on his hand.
And they have apparently not recognized in KiCad that programming is for professionals, and user interface design is for other professionals, and both is not something academics can do well on the fly.