This is a really broad subject so I'll answer at a very high level and not touch specifics unless they are relevant for OSS.
"Works for me"
This is really the crux of the problem; you have build environments that are different in a way that affects software behaviour. The industry at large has been tackling this for decades, and a number of best practices have emerged, such as making sure that development and production environments are exactly the same, or that all developers must set up their environments in the same way. Obviously some approaches work if you're paying someone full time to do whatever you want, but don't work if they are volunteers with their own devices.
Capture all configuration
Anything1 that can affect your build - configuration files, environment variables, compiler flags, dependencies and versions - this all needs to be documented. Some go as far as recommending that these be version controlled, so environments can be replicated easily by checking out the relevant files.
1except for secret keys and passwords.
Write tests, run them with a CI service, for every build and every pull request. This should be your first line of defence - if it doesn't pass CI, don't check in.
There are many CI services available, many free for OSS.
Make sure everyone uses the same environment... but the onus is on you.
You can have the most complete walk-through on how to set up an environment but if it's going to take a day to complete, forget about volunteer contributions. Having a project be as easy to set up as possible is great, but almost a requirement for OSS. This might mean writing scripts that automatically installs dependencies, or sets up a testing environment, or having a suite of samples and templates.
GNU's projects are a good example of this in action; all their projects can be built by running
./configure; make. If you've ever had the misfortune of working with autotools, you'll really appreciate how much wizardry and blood/sweat/tears goes into making a project easily build and run on almost any developer machine.
Fortunately things are much easier these days; modern build systems, languages or frameworks do a lot of this work for you. But the onus is still on you to make sure new developers can easily get started.
Support as widely as possible
Which also means you often need to bend over backwards to support as many weird environments as possible, to minimise the barriers to entry. That is, instead of mandating The One True IDE, support all IDEs and editors. Don't use compiler-specific or bleeding-edge language features, stick to standard, widely-used ones. That also means keeping up to date with the latest developments, avoid using deprecated features, so your software doesn't break when built with the latest versions of its dependencies.