I recommend you review the needs and decide on what tools need to be common.
For example you can't have some people using svn and others using git when there is a lot of code sharing. However when it comes to editors, differences may be ok. The time, cost and motivation for people to switch tools that are essentially about preferences is often not worth it.
Some practical examples:
Need to be common:
- The database being used
- The language being used
- The source control system
ok to be different:
- git tools - gui's, cli, etc. The end artifact (code is in git) is the same.
- Editor - there are many choices here
An important factor is sharing is freqently the editor. Basically if folks are good in different editor you have to accept it initially. On an open source style project it's most likely that people will stick to what they know and are comfortable.
If you need to pair on code you have three options:
- One person does the typing and uses the editor are comfortable and proficient with.
- Both people use a very simple editor (notepad, gedit, etc).
- One person invests the time to learn the editor that the other uses.
My personal experience for editors (while working in the Ruby on Rails community for the last few years) is that people are fairly split between editors (usually between emacs and vi). When it comes to writing code or even pairing, it doesn't matter that much, as long as the person coding is proficient in their tool and the person watching can follow along and see the code ok.
In your case, it's more about tooling than tools per se perhaps. The issue about which testing framework (phpspec vs. phpunit) to use when writing code, that's certainly tricky. I think this comes down to what's going to happen as you move forward. Will each group/person ever have to read or alter tests written in another framework that they don't know? Open source collaboration frequently requires this. If so you'll need to reach agreement on the framework. You'll need to work through the difficult and often contentious discussions. It's best to start out with agreement on things... that you can agree on... such as 'we do need to pick one' and 'whatever we decide at the end of the discussion, we all agree to be bound by it', 'first thing we'll do is listen to each other carefully', etc.
For this issue of different tools, I would put my efforts into showing why my tool works fine instead of others. For example with editor, its the same output at the end anyway. If tests are used to generate code (i.e. tdd) and discarded after, their implementation is less important. If they are retained afterwards and used as regression tests than it probably makes most sense to use the same framework.