"Drupal distros sound great, but...."

Despite the great Drupal distributions available, most Drupal site builders have yet to start using them regularly for building client sites.

There seems to be a bunch of perceptions out there about the limitations and difficulties of using distros, some of which may have been true at one time but are increasingly less so. So, following up on my "There's a distribution for that" post yesterday, here's a top ten list of reasons given for not using a Drupal distribution, with some reasons you might want to think again.

  1. It's all or nothing

    Site builders might be concerned that using a distro means being locked into a monolithic site design with many non-optional features. Fortunately, that's less and less the case.

    Many distros are now built on Apps, with each app being an optional and stand-alone piece of functionality. You can pick what you want and happily leave the rest. Even distros not based on Apps usually have small cores enhanced by many distinct, optional features. It's even possible to mix Apps from one distro with those of another. Increasingly, distros are flexible enough that you can take just what you need and leave the rest.

  2. It's someone else's product

    There seems to be a perception that distros are proprietary "products", as opposed to modules, which are community contributions. It's true that some distros are strongly identified with particular companies. But so are many modules--and that doesn't keep us from using them. In fact, having one or more companies actively engaged in backing a module, theme, or distro probably increases the chances it's going to get the long term attention it needs.

    In my experience, distro maintainers are just as happy as any other Drupal dev to get community feedback, fixes, and improvements. Adopting and contributing to a distro isn't "helping the competition". It's using and improving our shared solutions.

    And, just like with modules or themes, some distro maintainers will be more than happy to add you as a maintainer once you start making steady contributions. So "their distro" becomes "our distro".

  3. I don't have the time to try out distros

    When you look at a new module or theme it takes a bit of time to try out and evaluate. Distros are no different. But since almost all distros come fully packaged, it's usually quick and easy to install one. Or you could jump straight onto the Pantheon system or another place where you get one-click distro installation.

  4. My site is unique

    True. But it probably shares at least some back end structure or features with other sites built for a similar purpose. When you use a distro, it's not a case of either/or. You can select just what you want from the distro and do any customization you need on top of it.

  5. I want my own look

    And you can have it. Most distros are very flexible when it comes to design. If you've got room in your budget for a custom theme, a distro will happily accept one. Some will even give you a cleanly designed starter theme specifically built for the distro.

  6. I'm skilled enough that I don't need to use a distro

    That's what a lot of PHP developers said when Drupal and similar projects first came out. Then after a few years they found that having to do everything themselves was wearing, while pooling efforts and collaborating was infinitely more rewarding. It's pretty much the same with distros.

  7. Using a distro would hurt my bottom line

    Custom site development is the bread and butter of many Drupal developers and shops, and distros may seem to threaten that. After all, if you don't get paid for building out basic site functionality, where will the revenue come from?

    But here's another way of asking the same question: Now that you don't have to charge out for all the preliminaries, what more interesting features may you be able to fit in? In what ways will you be able to give your clients better value for the same investment? How many items can you convert from "future wishlist" to "phase 1 deliverable"?

  8. It doesn't do everything I need

    No, probably it doesn't. But does it do a lot of what you need? Is it a good leg up?

  9. I tried it but I didn't like X

    For sure, there's going to be small or even large details about any distro that don't fit with the way you'd want things done. We each have our own way of doing things and distros aren't perfect any more than modules are.

    The good news is, just like any other Drupal project, you can help improve them. Got a better idea about how to present content, design a page, or structure a content type? Go ahead and post an issue. Better yet, work up a patch. Speaking for myself, I'm thrilled whenever someone comes along with a better way to do things.

    And you can customize. It's true there's probably not a lot of sense in using a distribution if you're going to override and customize everything. But you can get value out of a distro and still do some things your own way.

    At the easiest level, since distro features tend to live in code, you can simply override selected elements like views or content type displays. If you want to play by the book, you can put your customizations into a site-specific override module, using the standard alter hooks that are available to customize code-based configuration, like hook_views_default_views_alter(). Or you can try out the Features override module, which can automate the process of capturing your customizations in code.

    So, yes, you can have your code and tweak it too.

  10. A distro would take too much time to learn

    Yes, there's a learning curve in developing a site off of a distro. You have to spend the time to wrap your head around how the distro is structured. You might need to read some developer documentation or bone up on some modules in the distro that you haven't used before.

    But you might be surprised at some of the benefits. For one, the features built out in a distro often provide some great examples to work from.

    Basing a site on a distro has a way of enforcing some good habits, like systematically registering your customizations. The time you save in basic site development can help free up budget and development hours so you can do things right, rather than rushing to deadline.

    And developing expertise in a distro can be a long term boon, as it means your next project will go a lot quicker and smoother now that you've learned the ropes.

So if you haven't started building distro-based sites, now might be a good time to consider starting. At their best, distros are just another facet of what community open source is all about: pooling efforts and collaboratively building great solutions.

Feed: 

Comments

I am never sure how to

I am never sure how to maintain a distro. Should I just take contrib updates as they happen or wait for a new distro that may have them built-in. I can't use my normal update tools as they tend to replace everything, maybe something I already got rid of because I don't need/want it.

Some quick pointers

Definitely updates are something to keep in mind when planning a distro-based site. I wrote about this last year in Tips for building a site off a Drupal distribution--see in particular the section on "Doing updates". The short version is: unless you're heavily customizing the site, your best bet is probably to wait for a new distro release that will come with updates of contributed modules and themes. That way you won't lose any patches included in the distro and, with any luck, issues in the update will have been addressed already by the distro maintainers.

Agreed. For a while w/

Agreed. For a while w/ Commerce Kickstart 1.x, I was recommending people just unpack the distro and move the modules from the profile directory over to the sites/all/modules directory and carry on. Fortunately I get to work with Damien, who devised a much more intelligent way to handle updates so the distribution could be more than just a bare launching point.  ; )

What we do now in Kickstart (pretty sure it's both branches) is hide the profile modules' update status unless a security release has come out that hasn't been rolled into a new release of the distro. The idea here is that we expect users to update each point release of the distribution, getting the minor updates of dependent modules at the same time. By hiding non-security releases, we mitigate that awkward situation where a point release of a dependency actually breaks some feature on the site (it happens : ), but we won't suppress any security update related warnings.

From a documentation standpoint, it should also be made clear where site maintainers should be putting these updates if they need to do them before the distro itself is updated. Don't wanna end up with duplicate versions of the module between the profile modules directory and sites/all/modules.

Thanks Ryan, I hadn't noticed that in Kickstart

Sounds like the right balance of retaining security information while not giving unnecessary update prompts. I'll have a look. I guess this is some of the territory that Phase2 had in mind when they drafted the Distro module, , but that's not been pursued. Similarly, Apps is supposed to come with update functionality eventually but doesn't yet.

Really these are issues best solved for Drupal as a whole. See Webchick's comments on Apps and the drupal.org infrastructure. A current initiative that could help pave the way is Deploy Project Browser Server and drupalorg_pbs on d.o.

What do I do if I want the

What do I do if I want the features of two different distros, e.g. Commerce and something else? The last I looked Commerce has core patches, and others may have contrib patches, and they may be such that one overlays the other's patches so there is no correct order.

Possible but not as easy it it could/should be

The Apps model in particular is supposed to promote interoperability such that apps from one distro could be seamlessly mixed with those of another. But the current reality falls far short. I outlined some of the issues in a previous blog post about apps. See also the articles on distros in the recent Linux Journal special edition on Drupal, including my article on writing interoperable distros and apps.

Patches are one issue. You'll also run across duplicate role and field names, different layout approaches (Panels vs. Context), and duplicate or conflicting module choices. See for example this inventory of different role names in distros. Most of these issues can be addressed, if you know what you're doing and carefully select features or apps from distros that at least share some common assumptions, like they both use Panels rather than Context for layout. But, for now, blending features from different distros tends to be an intermediate or expert task rather than a simple point and click.

This seems to go against

This seems to go against point #1 in your blog post.  I'm hoping the Apps workflow continues to improve, but lets not paint too rosy a picture too early.  That's what happened with Features.  People started saying that it's a great way to develop sites without also initially talking about the numerous gotchas and showstoppers that were involved.  I'd rather work on functionality for a client's site rather than trying to work around a not-fully-baked process.

Well...

There's an important difference between building a site off a single distribution and building one by mixing and matching parts of different distros. The first is getting better. See also this recent blog post about OpenPublic. The second, yes, is still a challenge, though there have been some improvements. Have a look at my blog post on Apps for details.

Still, choosing to build off a given distro rather than building a custom site won't typically make it a lot harder to integrate pieces from other distros. It just might not help as much as it could or should.