Skip to main content

Big or small?

·2 mins

I’ve been thinking a bit about whether it is better to have one big code base that has a lot of different components and features, or whether there should be many small code bases that each do one thing well.

I don’t have any answers, but perhaps these half-formed thoughts will help: positive, negative and interesting things about having many small related projects. These thoughts are mostly inspired by working on a bunch of different testing-related projects.


  • "Do one thing and do it well"
  • Enforces a certain kind of interface discipline
  • Avoids/postpones scaling problems with big projects
  • - test suite run times - documentation navigation - bug triage - forking mailing lists etc.
  • Newcomers only need to "buy in" to one idea at a time
  • Aligns with conceptual understanding of the problem
  • Better separation of commit privs etc


  • Release overhead
  • Duplication of infrastructure
  • - buildbot / hudson / pqm - bug tracker - mailing list
  • Duplication of license / copyright games
  • Harder for newcomers to see the big picture
  • Problems caused by interactions between different versions
  • Depending on multiple libraries is a pain on many platforms
  • Lag with commit privs etc


  • Perhaps smaller & self-contained means easier to upstream
  • Some projects like adding only small dependencies, other projects like adding few dependencies

Do these make sense? What would you add?

Twisted is in a sense the opposite of the small/many paradigm, in that it includes a great deal of extra features along with its core.