Yes, for OSS projects modularity is handy in terms of handling contributions, but modularity may not be the best way to deal with a problem in a certain market state and situation!

Research has shown (see, for example, “The Innovator’s Solution” by Clayton Christensen) that the “integrated” region over time actually shifts to a subcomponent of an original integrated component that has since gone modular. An interesting example of this for MySQL its pluggable storage engine interface since version 5.1. MySQL is more modular now, but individual storage engines are tightly integrated for performance reasons, and in some cases they are even proprietary. It’s important to realise that this too is just a phase and not a final state.

But sticking with OSS for this story, distributed version control with (among other things) decent branching/merging make contributions to the core are entirely feasible and even easy. It’s a matter of using a toolchain that supports the most suitable work process, rather than hinder it or force another unsuitable wok process. Good distributed version control systems: bzr (Bazaar), hg (Mercurial), git.

(note: svn/subversion, even with some “distributed” hacks on top of it, does *not* qualify as it’s architecturally unsuitable. The other tools have excellent migration plugins available to get your work process -and your code- out of svn hell. It’s a bit of work but can be a stepwise process to unwarp your work processes and get a sane and more productive development workflow.)

At Open Query we particularly like bzr, because with Launchpad it provides an excellent environment for tracking of bugs, features and ongoing work, merge reviews, and so on. The admin side of Launchpad has some user interface issues, but it is workable.

Sometimes the core of a particular component does need fixing – but the time may not be right for modularity, and it’s important to not get distracted by that geeky desire of “everything modular” as swimming against market forces can be very painful.