No one answer could possibly handle every situation. I've seen the "benevolent dictator" thing work, and I've seen it fail. I've seen "core teams" where every

No one answer could possibly handle every situation. I've seen the "benevolent dictator" thing work, and I've seen it fail. I've seen "core teams" where everyone has equal commit privileges, and some of those produce good results, but some don't. Then there are hybrids, where you have a big company and stuff gets sliced up. eng/foo is owned by one group, but eng/bar is owned by another. Then there's hr/secret which is owned by a third group and isn't even readable outside of that group. The trick is that someone in eng/bar can submit a patch to one of the owners for eng/foo, and if that person cares to approve it, then it can be applied. Can this be abused? Sure. Get approval for your change and then modify it to be evil before you check it in. If the systems in place aren't specific about what approval means and the people have bad intentions (or maybe are just clueless), then it's possible to make all kinds of disasters. The better question is: who or what is going to make sure someone actually owns something? Just having some code in your depot is no assurance that anyone is taking care of it. You might not find out that it's broken until long after the last developer has moved on to greener pastures.