At first glance, the issue seems to be that the project isn't managed. Management of open source/volunteer efforts is an interesting challenge that deserves a paper/presentation. I mention this only to highlight that the question is, I think, more important/significant/on topic than it may initially appear.
If I were to try to manage this project, my priorities would be
1) Socialize (nemawashi) and articulate clearly, consistently and repeatedly a compelling shared goal. Given that efforts are volunteer, the most important way to ensure that everyone is pulling in harness/working together is to motivate people with a shared, compelling vision.
2) Establish a governance mechanism based on consensus with respect for diversity. Once you have a compelling shared vision, you need to refine, reify and maintain that vision. In my (albeit limited) experience, the best way to do this is to have a core group who are willing to devote the effort to examining contributions and analyzing what impact they'll have on the vision. This can be a Configuration Control Board, this can be a scrum meeting, this can be an autocrat, this can even be an AI based on a random number generator. But it has to do the following things
Accept contributions as part of the project. If a contribution is not accepted then specific feedback should be offered. I strongly recommend that this "accept" process be based on "What impact will this contribution have on the shared vision?"
Sponsor forks. There are going to be diverse opinions about "What is Good?". I suspect that in most cases the best approach is always to say, "go ahead and fork that, build a spke/sprint/demo and let's see." The best way to avert irreconcilable differences is to welcome and respect diverse opinions.
Discuss & approve changes to the shared vision. Explicitly work the cone of uncertainty.
Identify priorities - act as the product owner and identify the code fragments that are most necessary to getting to the shared vision. Make sure those are visible; that everyone knows about the blank spaces on the development map/development debt.
3) Establish code quality standards. Stitching together code is going to require standard interfaces. Build some kind of consensus based standard about what the calling code should expect, and the called code should provide.
4) Study bitcoin & other project. Bitcoin plummeted from the savior of the universe to an interesting case study because it forked over a fundamental disagreement about the goals. If I were in your shoes, I'd study the heck out of that and look for similar cases. I'd write myself papers and look for leading indicators of irreconcilable differences.