Consider a complex and extensive software component; for example a multi-language text rendering engine, an IPC framework, a scheduler that can handle multiple time zones, a module full of complexities caused by the need to stay backwards compatible, etc... It requires a lot of knowledge of the details to maintain and extend such a component without introducing bugs with every code change. It is also often helpful to know the bug history when receiving a new bug report. Moreover, it requires thorough knowledge about the component's design to be able to maintain its consistency after future extensions, and it is good to know the rationale behind past design decisions. You might try to document this kind of knowledge, but it would require a lot of time and effort, it would rapidly become outdated and hence untrustworthy. Worse, everybody would still need to keep that written documentation in his/her mind.

It seems to me that for such components, it is best to have someone that has in-depth knowledge, as one cannot thoroughly know and keep up with the code produced by a whole group of people without an excessive communication and learning overhead. I wonder whether the practice of collective code ownership allows for such experts, as it seems to me that it would require some kind of "weak code ownership". And if not: how can it succeed without a massive amount of duplicate work?

  • Collective code ownership does not mean exclusive rights to modify the code, it means shared responsibility. E.g. if the "main owner" of a particular piece of code cannot/will not fix a bug in it, another developer can and should step in and fix it to the best of his/her abilities.
    – quant_dev
    Jan 10, 2012 at 14:26

2 Answers 2


In practice, the programmer(s) who created a source file is the one(s) who will most likely make most of the changes in that file. Collective code ownership doesn't mean that tasks are assigned without considering who is the most competent person for that task.

But if another programmer needs a change and is able to do it by himself, he is allowed to do that without asking the original programmer for permission.


I think that the notion of collective code ownership is really just trying to combat the diseased notion that "I cannot touch that module, because it is Bob's code":- There does not (to me) seem to be any technical reason why you cannot have collective code ownership (in the sense of everybody being able to modify everything in the repository) AND experts with primary responsibility for a particular library, module or products. The main challenge is one of man-management & organizational psychology; and how one would promote the appropriate attitudes in the development team.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.