I will second and third many of the above responses: Having each developer with an Apache instance on their workstation is not a bad thing at all.

When major code changes need to be made that will result in things being broken for a substantial period of time, it saves everyone a good deal of heartache.

In fact, I consider it one of the major advantages of using open source. If you were developing in Cold Fusion, you'd have to spend thousands of dollars a seat to give everyone a development environment they can wreak utter havoc on without fear.

In order to develop successfully with more than a few developers, however, you have to be able to transition code from workstation to production in such a way as to ensure that any one developers' tweaks do not break anything as they move from their customized workstation to a generic production environment.

That would entail:

• Good code revisioning; e.g., with CVS
• A multi-stage release process in which
  1. Developers commit working code to CVS
  2. The (working) code changes are checked out to a collective development environment which is maintained to be like the production environment, but which developers can feel free to make changes to (e.g., to the back end)
  3. Once the code passes muster on the development server, it is migrated by someone in charge of the release process to a QA server and a walk-through is done of the release process. The QA server should be kept as close to production as possible, mirroring the back end if you've got one. After the walk-through is successfully completed, the code changes are tested on the QA server. If either the walk-through or QA process is unsuccessful, the QA server is restored to its original state and you wash-rinse-repeat until everything goes smoothly.
  4. Only after the walk-through and QA are successful on the QA server is the code pushed to the production environment.
• A rigorous release process in which only one or two people have access to the QA and production environments. All code changes must go through that person or persons before being considered for release.

As a side benefit, your developers become much more familiar with the environment that their code runs in. They are better off because they have improved professionally, and you are better off because now you have a whole team that can help you diagnose critical production problems rather than just a handful of people.

Hope this helps :-)