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
    40 is not really large. Shopify recently posted an article about their repo with 1000 active contributors. – Qwertie Nov 26 '19 at 6:04
  • It depends on how the project is managed and if the project size needs this number of contributors – Ahmed Rebai Nov 26 '19 at 9:10

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
    reason for accepting this answer: while Micheal's answer is a great one. This answer highlighted the difficulty to manage this many contributors. And yes, we got chaos.... – Allen Zhang Nov 26 '19 at 19:32

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?
  • thanks for the great answer. It's my bad that it wasn't clear to everyone: this project isn't an open source project which openly invites more contributors - like Linux Kernel. But a good answer regardless. And yes to all points except the last one - and this actually causes endless problems. – Allen Zhang Nov 26 '19 at 19:34
  • The linux kernel has just one or a handful of people with authority to approve changes in a given subsystem, see kernel.org/doc/linux/MAINTAINERS. – closeparen Dec 15 '19 at 18:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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