The Drupal Attitude

I’ve been doing some geekery with Drupal lately. Drupal is a free, open-source server application that makes it easier to build really complex Web sites. It allows you to create complex data types and establish relationships and do fancy database stuff… without actually touching the database. That’s not too shabby. Drupal is rapidly becoming more popular, but there are a few things standing between Drupal and world domination. At the top of the list is the Drupal Attitude.

I will illustrate with an example. Things will get geeky for a while as I set the stage, then mellow out as I focus on the human interactions between various groups.

From a technical standpoint, Drupal’s biggest flaw is that it sucks when it comes to many-to-many relationships. Imagine I have a data type called “shirt” and another called “color”. It is very easy for me to set up “shirt” so that it can have several colors. So, when I look at a specific shirt in my database I can see that it has red and yellow in it. That’s all pretty straightforward.

The catch comes when I want a list of all shirts with yellow in them. If I had direct control over the database, many-to-many relationships like this are trivial and do not diminish the performance of the server. Drupal has no built-in way to get a list of all shirts with yellow in them.

But wait! Drupal is open source, and better yet has been built to be easy to extend by outside programers. Into this glaring hole in Drupal several folks have stepped forward with modules that solve the problem in a variety of different ways. Some of these methods are clever (one uses the indexes built by the search engine, for instance), but all have trade-offs and weaknesses.

So, you’re a Drupal developer, and you want a list of shirts with yellow in them. Which module do you use? Each module works differently, each requires some installation and fiddling to get working. Then there are the two modules by the same guy that are for similar but different purposes, yet the actual differences are not spelled out very clearly. What would help a lot would be some concrete examples of when to use which.

Now we’re getting closer to the Drupal Attitude. Remember as I rant about this that all the modules I’m evaluating are free, posted by geeks who wanted to contribute to make Drupal better. So, some slack-cutting is in order. BUT…

I had already spent more time than I had available trying to figure out which module to use, when I found a question posted by a guy asking “can I use this module for x”, where x was very similar to what I needed. “Aha!” thought I, “Now we’ll get a definitive answer!” Except that the response to the question was, “In this discussion (the article was about the differences between two modules) we want to focus on generalities, not specific applications. You should download both modules and fiddle with them for a few hours to determine which is right for you.” Or something like that. Notably absent from the answer was a pointer to where specific questions would be answered.

The guy who asked the question responded a bit harshly, pretty much saying, “Would it kill you to just answer my question? I don’t want to spend hours learning something you already know and could tell me in fifteen seconds.”

Well, this is just the sort of uppity user that the Drupal community loves to hate. Several people piled on in defense of the developer who had refused to answer the question. “He’s doing this for free, he’s helping the community, you should be grateful, blah, blah, blah.” None of them deigned to answer the original question either. There is a real, entrenched cadre in the Drupal community that says, “we learned things the hard way, and you should too.” Who needs documentation when you can read the source code?

Let’s step back for a moment and ask ourselves, “Why did the developer give this code back to the Drupal community?” The obvious answer, the one everyone talks about, is that he wants to make things easier for other Drupal users. That is a noble motivation and one I wholeheartedly support. He wants to be useful. Perhaps he just isn’t aware that a huge part of utility of software lies in the documentation. Perhaps he isn’t aware that a few choice examples of what his modules are meant to accomplish would have cost him an hour of his time and improved the acceptance of his work dramatically. He’s a coder, after all, not a marketer or a technical writer.

Even with all that, however, when someone, in the form of a question, contributes to the documentation by providing a specific example, he didn’t answer the question. No light came on that even if that was not the place for the question, then spending five minutes creating an FAQ would have helped the community far more than adding a new feature to his software. So an opportunity to spend just a few seconds and make his contribution to the community better went completely ignored. His supporters congratulated him for not capitulating to the demands of his potential users for more clarity.

Any of them could have stepped up and helped the newbie, probably in ten words or less, but none did. None of them wanted improved documentation. “We had to learn it the hard way, so you should too,” with a side order of “we make lots of money because we’ve figured all this stuff out.” Ladies and gentlemen, the Drupal Attitude.

If the guy posted his module but doesn’t seem interested in making it useful, then why did he post it? Well, he’s certainly getting lots of love from the people who figured out his work the hard way. They can all feel good about how smart they are.

And in the end, should I be thankful this guy shared his work with the rest of us? Actually, no. In my case, the presence of his modules ultimately had negative value. They cost me time, and never getting an answer about which was appropriate for my task, I went with a module developed by someone else.

So, Drupal contributors: If you don’t want to document your module, and you don’t want to answer straightforward questions from people who need to get a job done in limited time, don’t bother posting your fucking module at all. I don’t have time for endless fiddling and I sure as hell don’t have time for the Drupal Attitude.


9 thoughts on “The Drupal Attitude

  1. All I can say, is use the not free but well documented ASP.NET ObjectDataSource. That is all.
    You need to put a little logic to develop the query (and this is always database schema dependent — a universal option is just not possible, write the f’in query (is it that hard?) and return a list of the business objects which match your query. It is probably free if you use Mono and (what the hell is the free dev environment, Eclipse? and one of the free C# compilers instead of Visual Studio 2010).

    I just rewrote the store that I work on as a “Mark II” model and it took me about two weeks to redo the entire store with a new look ‘n feel. It took about 3 months to do the first round because I did it in the old stupid way (ASP “classic” style) in C# ASP.NET. Now all I have to do if I want to change the look ‘n feel of the damn thing is change the markup and/or the CSS. I would be great if MS made a truly CSS compliant browser (have layout? WTF is that?) but they really, really promise that IE9 will be. Yeah, right.

    • Generally it’s not my choice what Web app to use. Drupal is all about “you focus on the front end and let us worry about the back end.” There are plenty of ObjectDataSource-like frameworks that are (reasonably) well-documented and also free, that work pretty well.

      Like you, I come from the “write the f’in query” school, because then I can optimize the expensive queries. (Performance will be the next focus for my observations about Drupal.) Still and all, though, Drupal promises a hell of a lot and delivers 60% of that – which is still a lot. There’s a reason it’s so popular. It would be twice as popular if the people who code for it realized that they are their own worst enemies.

      My last experience with Microsoft tools was horrible. Granted, that was a long time ago, and they’ve had a lot of time to steal ideas from a lot of other people since then, but I’ve never been the least bit tempted to lay down the cash for their stuff.

      As for IE9, I’m not sure why anyone uses Explorer for anything other than corporate intranets built entirely on Microsoft technology. In that context, it’s the right choice. Anywhere else, it blows. I write to standards; I make no effort whatsoever to make this site IE-friendly, and I wish more designers did the same. (Of course, clients who pay me to build Web sites will always require IE to work, and I will always accommodate them (after a brief lecture about how it will increase the cost of the site).)

    • Oh, and hey, remember all those years ago when you helped me buy way more camera than I would ever need? Good times, man, and now… I’m outgrowing the camera. Crazy. So if I never thanked you for getting me set up, let me do it now:


  2. It’s a shame you did not look into the installed by default modules.
    Taxonomy comes out of the box and solves all of your shirt coloring problems.
    1. Create vocabulary colors
    2. Add terms yellow/blue
    3. Tag your shirt with a color.
    Automatically drupal will show a link (on tagged nodes) to a view with all stuff tagged with colorx.

    • I am familiar with taxonomy, and while that can work around some issues, it’s still not a many-to-many relationship. It’s categorization. My example was intentionally kept simple, but there are plenty of places where that breaks down. What if there are 10,000 colors?

    • Or, as another example, what if I want a many-to-many between complex data types, like person and location, where a location can have any number of people, and people can be associated with any number of locations?

Leave a Reply

Your email address will not be published. Required fields are marked *