At our DrupalCon process session, I talked briefly about how we approach modules at Aten; short version: we try to use modules modularly. We had a lot to cover in a short session, so I didn't go into a lot of detail there, but I can write a short novel in a blog post, so I'll go into more detail here.
The idea of modules being modular seems kind of obvious; that's what "module" means, after all. But it doesn't always happen in practice, and it's worth looking at what constrains modularity in Drupal and how we can improve things. Some upcoming changes in the Drupal community will directly affect the modularity of modules, and it's worth looking at ways we can help keep things as modular as possible going forward.
Why Modularity Matters
The idea of modularity was summarized well by Doug McIlroy, in the context of Unix: "Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features." Replace "program" with "module" and this is a good description of how Drupal's module system ideally works. Many modules in Drupal do one thing well and leave the rest to other modules. Voting API, for example, creates a system for managing votes, but leaves the actual voting UI to other modules, e.g. Vote Up/Down or Fivestar.
The benefits of this modularity are enormous. One of the huge advantages of Drupal for Aten(us?) is the flexibility we have in completely tailoring the user experience to what we hope will work best. We are able to do this precisely because Drupal code is generally modular, so we can replace the pieces that don't work in a particular context without rebuilding entire systems. It's also a lot easier to contribute to modules that are more focused on specific goals.
Making Modules more Modular
But this system doesn't achieve its full modular potential. On the other side are some less modular modules. The FAQ module, for example, both manages FAQs and handles the UI for administration and viewing of FAQs. And some modules, e.g. Strongarm, actively interfere with what other modules are trying to do.
These modules have legitimate reasons for being less modular, and modularity shouldn't trump all other concerns, but ideally things could be made more modular without sacrificing elsewhere. The whole point of Strongarm is to override what other modules say, so it wouldn't make much sense for it be more modular, but why does it exist at all? Oddly enough, Strongarm seems to exist as the epitome of a non-modular module, only because Drupal isn't more modular. It's a symptom, not a problem. From the description on the project page:
An example of such a variable is site_frontpage. In Drupal this defaults to node, which ensures that the front page gets content as soon as some exists, but for many Drupal sites this setting is simply wrong. Strongarm gives the site builder a place in the equation - an opportunity to set the site_frontpage to something that makes sense for their site.
If Drupal had a way to distribute control of such variables to modules, a more modular system, Strongarm might become unnecessary.
In looking at how we might make something like the FAQ module more modular, it's hard to imagine a FAQ API resulting in the same kind of variety of UI we see around Voting API. The lower modularity here seems to be a simple cost-benefit balance; there's cost to making FAQ more modular, and little apparent benefit. That cost might as well be applied to recreating a FAQ system from CCK and Views. The whole point of the FAQ module is to reduce this work.
The benefits of modularity will naturally increase as Drupal is used for in a wider variety of scenarios, but reducing costs of modularity in Drupal could use more attention. One of those costs is a more complex installation process. All things being equal, I expect most would rather install one module that does several things than several modules that collectively do the same things. That's because each individual module install in Drupal currently requires work. A plugin manager in Drupal core, however, promises to improve this by automating the process. If installing several modules can be made as easy as installing one, that's one less reason to avoid breaking up modules into more modular pieces.
Enter Distributions
All of that assumes we're building a site. But the interests of people who are simply using a Drupal site are completely different, and don't directly benefit from modularity at all. As site administrators and visitors, we just want things to work. If anything, having more independent parts under the hood just makes it more difficult to know what to do when problems happen, so people tend toward non-modular systems when not tasked with maintenance.
Drupal is increasingly being used in this kind of don't-worry-about-how-it-works scenario. Products like Development Seed's Open Atrium and Aquia's Drupal Gardens, while built on top of Drupal's heavily modular structure, expose Drupal more as a unified whole to a lot of people, largely hiding Drupal's modularity. Such Drupal-based products are a good thing, but it's important not to lose sight of the modularity that enables them.
Drupal founder Dries Buytaert recently addressed this risk regarding distributions:
As a community, we have to take responsibility, and make sure that distributions collaborate rather than compete, much like the way that we attempt to work together on modules.
I'd suggest another risk here beyond distributions themselves failing to collaborate is distributions reducing Drupal community interest in collaboration on the module level. In both Open Atrium and Drupal Gardens, you can still swap out modules that don't suit you, but that's becoming increasingly uncommon. It's easy to see how products might be built on top of Drupal that go even further, for example wrapping the entire products' functionality in one central "module" that isn't remotely modular. It's a well-known truism in the Drupal community that you shouldn't "hack core" because doing so results in a large code base that can't benefit from community contributions. It's becoming important to remind ourselves that non-modular "modules" kill kittens carry the same risk.
One good way to protect against this risk is already happening. Full Drupal Distributions on Drupal.org should encourage closer integration between distributions and the modules they use, making it less likely that any individual distribution will start using modules in less modular ways.
And all signs suggest the people involved in distributions so far, as much as they can, want to keep Drupal modular. Even Microsoft, often mistrusted for engaging in precisely the kind of "embrace, extend, and extinguish" scenario we might be worried about, is taking a decidedly modular approach in their early steps toward Drupal involvement. Still, it's worth remembering the risks here.
The Modular Future
As always, the future of Drupal is very much in flux. But while there are reasons to be cautious, it seems very likely Drupal will become even more modular. The great thing about Drupal is we can all help move it in that direction. By avoiding changes that harm modularity, and supporting changes that help modularity, we can gradually make Drupal more modular, more awesome.