I recently got an email from Mark Shropshire (apparently emailing from the depths of a secret research lab at UNCC) asking about an article I had written giving feedback on one of IBM's Developerworks articles, where I talked a bit about some best practices around multisite, symlinks, etc.

The bit that got him interested was this paragraph:
Overriding a core module is no problem. Any core module you place in /var/www/html/sites/domain.com/modules will override the main install core module. This is a safe way to have patched core modules without having to wonder if you'll run into trouble updating your main Drupal install.

Yes, it's true. With the power of Drupal's magic multisite file path scanning, you can place a module in your local sites/domain.com/modules directory and it will override modules that are "higher" up the search path. But, Drupal tries to thwart you by sneakily caching the file path to modules in the system table, which only refreshes when you go to the Admin / Modules page. Here's how to get that "local" module enabled instead:

0. Put your site in offline mode
1. Go to admin/modules (4.7 and earlier) or admin/build/modules (5.0 and up)
2. *Disable* the core module you want to override and submit the page (you should already have the override module in place)
3. Re-enable the same module, and you should now be running the "overridden" version

Bryght started with a simple idea: what if we could take a powerful, complex framework like Drupal and make it available to everyone... with or without technical expertise. This was closely related to our belief that eventually static HTML pages on the Internet will be replaced by dynamic pages. Dynamic pages means web applications.

We've seen a lot of this occur over the past several years. When we started, Drupal was making the transition from Drupal 4.4 to 4.5. Multisite was just a glimmer in people's eyes, and the concept of install profiles was nowhere to be seen. Bryght worked on Drupal core to include multisite capability out of the box: all of a sudden, it was a bug if a module didn't support operating in a multisite environment.

Drupal-as-framework was in a much different state back then. Developers constantly hit cases where the core code didn't have enough "hooks and interfaces" to cleanly override everything. We ended up building a series of tools and daemons around Drupal in order to enable mass hosting. This tool is called HostMaster, and is Bryght's answer to mass hosting Drupal. It's built around Python and PostgreSQL, and has had the concept of "install profiles" for about 2 years. We originally had dreams of perhaps licensing or otherwise making money directly off this code. But in reality, this concept is foreign to our open source beliefs: the bits don't matter. Eventually, we put HostMaster under the GPL and made it available at https://svn.bryght.com/hostmaster (yes, you still need to request an account).