Is it a bad thing to have a large number of contributors in a code repository?
My current company has a really large repo. This repo has over 40 contributors.
And there’s a debate about whether or not it’s a bad thing.
What do you think? What’s the good practice about it?
2
This will probably trigger a lot of opinionated answers which, in this case, may not be so bad. Here’s mine.
In general I would say yes, 40 contributors for a proprietary application is a lot. By the time you have this many contributors you’d better be sure to have a lot of safety measures in place that limit the room for individuals to do their own thing. In that regard I agree with Michael. My main concern would be control of design issues, making sure things do not get off the rails. You will need a gate keeper, someone familiar with the overall design who is in control of what goes and what not. He will grow to trust a couple of individuals down the pyramid, a pyramid that will have to grow steadily. Then it can work. You do not want groups of people developing stuff independently from each other where each group is unaware of what other groups are doing.
The more people come in, the more management this will require. It takes time for things to settle in and for people to become effective, like in any organization. Just starting a project and throw 40 people at it immediately is not likely to succeed. So yes, it can work but only if you start small and take it one step at a time.
I do not believe is shared responsibility so I say you will need a pretty rigid hierarchy, a technical owner to rule all contributions. If you do not have this you will either get chaos or the inability to make big changes when needed.
1
There are projects that have many hundreds of contributors . The Linux Kernel is one that springs to mind, so no having 40 sets of eyes improving code and fixing bugs is not a bad thing.
However, what does matter are the change management processes, and the controls in place to ensure that a few bad commits by one developer do not bring the entire development crashing to a grinding halt.
These may help to ensure that more developers can work together:
- Does the code have unit tests?
- Are the unit tests run before commit?
- Do developers work on their own branch?
- Is code peer reviewed as part of a branch merging strategy?
- Is the code modular? in that each individual change only affects a few isolated files?
2