As I’ve worked as a software engineer, I’ve noticed that individuals, teams and companies approach things differently with regard to code ownership. Most engineers and teams take pride in quality code, in solving real problems, and in shipping software.
The model of code ownership affects the dynamics of a team, of a company, and of the software that is created and maintained. I’m strongly in favor of collaborative ownership, with the understanding that individual engineers are stronger in some areas than others. I appreciate collaborative ownership because it engenders a culture of inclusion, participation, cross-functional learning, and openness to a diversity of ideas and experience.
On the other hand, I’ve seen it work for individual ownership of certain components of a software stack — as long as there’s a way for others to give feedback in constructive ways — i.e. the owner takes pride in his/her code, wants to learn and accept feedback so that their code can be the best that it can be.
It drives a wedge in working relationships when a code owner says “hand’s off!” or “how dare you touch my code without consulting me first!”. It also creates problems when a contributor says, “I’ll make changes when I want to, whether you like it or not!”. Such attitudes indicate a lack of trust and respect. Perhaps this is why distributed version control (with pull requests or patch submission) works well compared to the anyone-can-commit model more common with Subversion. E.g. with github or gitlab, anyone can contribute, but the code stewards get to decide whether or not to accept the request.
The same principles apply when outside team members attempt to contribute code to another team. Ideally, the recipient team documents code standards, design decisions, and if nothing else, during code review, they communicate the ideals to the team attempting to contribute the code.
Here are some articles that talk about the styles of code ownership, and the pros and cons: