Collective code ownership means that everyone is responsible for all the code; this, in turn, means that everybody is allowed to change any part of the code.
That also means that everyone has to change any part of the code when it is required. Developers cannot shield themselvs behind a "he did it". Even if you didn't partecipate in the writing, the code should be clear enough to allow you to understand it and change it confidently.
By giving every programmer the right to change the code, there is risk of errors being introduced by programmers who think they know what they are doing, but do not foresee certain dependencies. Sufficiently well defined unit tests address this problem: if unforeseen dependencies create errors, then when unit tests are run, they will show failures.
That's true, but... who controls the controller? Just today, after other colleagues were trying to integrate two systems without writing tests (boo!) we wrote a (supposed to be) failing unit test and... it didn't break as it should, as we were testing for equality objects that we clearly knew were different. That was because we forgot to change the equals and hash code methods after adding an attribute to the result class of which our tested method returned an instance, and we didn't have a test on equality on the result class because all the code was generated by the IDE. Nevertheless having a bunch of tests sped the process of finding and fixing the error: if we didn't write a failing test before proceeding we would have spent a lot of time before we managed to find our (not too subtle) bug - time our colleagues actually did spend.
So... always write your tests! That's another supporting example for the "we tried baseball and it didn't work" post: Collective Code Ownership also works because of other practices, such as coding standards, pair programming and unit testing. I'm still convinced of what I wrote, but I certainly agree on the fact that you cannot simply pick random XP practices and hope everything will go well.