Collective ownership of code reverses the isolated development models of the past and means that any person can change the application code at anytime. Here's the catch: If you own all the code, you are responsible for all the code as well. The good news is that so is everybody else on the team. Pair programming supports the idea of collective ownership, as well.
The opposite of collective ownership is where individual developers are assigned as "module owners" or "subsystem owners." This has a ring of control and safety about it. However, the truth is quite the contrary where key team members hold information in their heads and might inadvertently hold the project team to ransom. One sick day or vacation can throw the entire team out as they try and overcome integration problems with missing team member's code. The "it's not my code" defense is not only frustrating, but works against any sense of team that you've managed to establish.
If your project uses collective ownership, and not the other XP practices of pair programming, testing, and coding standards, your efforts will end in chaos.