[consulting] Drupal considerd dangerous

Sami Khan sami at etopian.net
Sun Dec 24 22:45:08 UTC 2006

Drupal can and will pretty much do anything that a web application can 
do given it's in the right hands of people, this is in terms of 
functionality, ANYTHING!. If one of the core developers takes on a 
project that they're bound to finish regardless or any circumstance then 
yes Drupal can be developed into any type of application you want, period.

However, as with anything else, there are many lines of disclaimers 
which go with the above statement:

    * Will Drupal be clean in terms of only providing the functionality
      you want and nothing else?
          o Well yes and no, you can enable and disable the majority of
            modules but quite a few modules won't do everything that you
            want to do. Therefore, you will have to either fork the
            module or add to it, submit patches and hope that the
            maintainer commits those. If you don't succeed you will have
            to maintain the module and essentially carry around all the
            code of that module and maintain each one that you fork. If
            you decide to upgrade from one version of Drupal to the
            next, you will have to upgrade the module yourself. The new
            theming functionality is helping with this, but at times I
            have found people have changed the variables that go into
            the theming function (contrib), naughty, naughty!

    * Can Drupal do this task with this budget? Often people simply
      don't have the proper budget needed to work with Drupal and
      considering that you're hiring consultants, are they qualified,
      and how are you going to retain them if they get offered more
      money. Working with Drupal I have found that there are very few
      experts and most of them are busy, period.
    * What are my other option in terms of content management systems,
      in comparison to Drupal? I think when often you ask this question,
      you find that there aren't any other options in the open source
      space, and that's why you came to Drupal in the first place... or
      the other options are just as weary if not more so. The other
      option obviously is to roll out your own content management
      system. In order to do that, look at something like CakePHP, and
      look to hire a full time developer and at least have a budget of
      30,000$-60,000$ easily per year to pay them for their full time work.
    * Are their proprietary solutions that would be better for my
      project than Open Source solutions. Often, people only keep open
      source solutions in mind when other non open source solutions
      would suite their needs betters and already fit their needs to a
      point where they could really save on the cost of developers which
      are (often) the expensive equation to developing with Drupal.
    * Does Drupal in general model the problem domain well? In many
      cases you will find that it simply does and translating that
      domain over to the way that Drupal is modeled will add more
      barriers to developing with Drupal and these problems have to be
      solved by a single developer only adds to the mess.

Supply and demand factors

    * Drupal is in high demand, therefore there is a shortage of developers.
    * If you get a bad developer, it's difficult to ditch him or her and
      move on to a different developer as they might have done certain
      customizations that they didn't document well and that it's
      difficult for your new developer who is also pretty much a novice
      to get his or her hand around.
    * The Drupal code base tends of have a significant learning curve
      and a method of working with the system that doesn't let people
      jump right in and start changing things. Drupal also has a certain
      way that it's modeled and that model doesn't lend well to each and
      every problem domain or needs a conversion to Drupal.
    * The above premise leads again to shortage of developers which
      again increases the burden of dealing with Drupal.
    * A lot of developers that are working in the area are working in it
      as a hobby until they find greener pastures, therefore there is
      always a chance that a developer will quit and move on. When they
      do quit, how are you going to deal with it?

Open source budgets:

    * Often people come to open source with small budgets, that is to
      say that they don't have adequate funding to fund their projects
      with all the features that they want.
    * This is actually an extensive part of the problem, in that a
      developer will often require a significant number of resources
      that he or she does not posses in order to complete the solution
      and because of this, they will fail to bring about results.
      Multi-million dollar companies often do this, and so it can
      definitely be expect from developers.

Simplifying adds complexity - by example:

    * My pal, Merlin, or Earl has developed the excellent views package.
    * The views package makes you life easier when trying to do quite a
      bit of work, so you decide to use views in your project, except
      you want to add additional tables to views -- now you have a problem.
    * A single query to a table will take you a few seconds to write up.
      SELECT * FROM {table} t LEFT JOIN...
    * Adding the table to views (so you can do the same thing and
      possibly much more using views) can take you a week if you don't
      know what you're doing with views but know Drupal. It will take
      you probably something like 3-4 months or most likely more if you
      don't know Drupal. You will have to do this without much
      documentation to guide you... there are no easy recipes to follow.
    * Once you've added a table to views, something might change in
      views and therefore you have to figure out what changed and make a
      similar change to your package. This obviously is not happening as
      often as code matures, but still could happen.
    * Certain things in Drupal are very well documented, other items
      aren't. Where items are documented, there is a lot to be desired
      and therefore you must be comfortable with reading code in order
      to work with Drupal.
    * Once you have added the table or module to views, you must then
      maintain your code against Drupal and now against views, each time
      views changes, you have to make sure that any functionality that
      it's using from any contrib module is also maintained.
    * I post the above with the disclaimer that it's only an example, I
      love views and couldn't live without it!


    * Each version of Drupal breaks the previous version:
          o Every contrib module has to be updated and there is no
            guarantee that it will be.
          o Any module you write has to be updated.
          o Your theme has to be updated. If you've written function
            calls to other contrib modules, you have to update those
            calls in your theme.
          o The database that holds you content has to be updated.
          o The Drupal code base has to be updated itself.
          o This process is getting better, with install files, etc, but
            still leaves much to be desired.
          o Trying to be cutting edge with Drupal is a bad idea.

Those are my thoughts on some of the problems with Drupal and the 
problem with the problem domain, the rest is how you deal with it. 
Drupal is a hacker distribution for a CMS (at least thus far), in the 
fact that it's a hacker distro lies it's power, in the fact that it's a 
hacker distro lies its weakness. Drupal is willing to try anything new, 
and throw out the trash each and every time at any cost -- and that 
means you. As for not comparing and being short on limiting Drupal's 
scope, well I think due to how much time Drupal takes and what it can 
do, there are quite a few developers that don't work with anything but 
Drupal, and therefore have tunnel vision. It would take a significant 
amount of time and effort to be any sort of expert in multiple systems 
to be able to properly direct people to all of their choices. I guess 
that gives Forrester Research something to do but you often find that 
they too are limited in the same way -- often worse.

There is room for something like Wordpress.com for Drupal. But 
wordpress.com is limited to blogging, and any such deployment would have 
to limit its problem domain which is often not possible with Drupal as 
there is so much you can do and so little time!


Kaliya * wrote:
> Even,
> I am with you on this. I find the community attitude quite arrogant and
> condescending.
> I am quite familiar with one of the startups 'hurt' by the choice to use
> Drupal.  It was a mistake and they and  likely several of the startups 
> that
> choose Drupal as a base were sold on the platform really hard by 
> people in
> the community.  It was pumped up to be more then it was and they 
> bought it
> and then got into it and it just was a mess.
> All I wanted to do was nice clean simple neat social networking for
> spiritual leaders and groups. Without a  whole lot of cost and I 
> couldn't do
> it in Drupal.  I personally am waiting for a Ruby solution for my needs.
> =Kaliya
> On 12/21/06, Evan Leibovitch <evan at telly.org> wrote:
>> Kieran Lal wrote:
>> >> There are no qualifications or "it's not always the best choice" type
>> >> honest comments anywhere to be found.
>> >>
>> >
>> > By targeting specific uses we tried to highlight it's strengths.
>> > Highlighting weaknesses is not very useful as it's frequently the
>> > limitations of the users ability to use a tool that are the real
>> > weakness.
>> >
>> Well, there we have it: "There are no weaknesses in Drupal, just
>> weaknesses in users' ability to master it."
>> You have me at a loss for words, I honestly have no answer to something
>> so incredibly arrogant.
>> >> Small businesses are explicitly mentioned as a target group for whom
>> >> Drupal is the right answer.
>> >> In fact, the page offers no realistic appraisal of what Drupal 
>> doesn't
>> >> do well, which is also what people coming to such a page are
>> >> looking for.
>> >>
>> > What do you suggest?
>> >
>> The kind of honesty that Bill suggested. An acknowledgement that Drupal
>> isn't for everyone, and a frank analysis of its advantages and
>> drawbacks. Respect for users' intelligence rather than contempt.
>> Emphasis on understanding what users need, rather than what you expect
>> of them.
>> - Evan
>> _______________________________________________
>> consulting mailing list
>> consulting at drupal.org
>> http://lists.drupal.org/mailman/listinfo/consulting
> ------------------------------------------------------------------------
> _______________________________________________
> consulting mailing list
> consulting at drupal.org
> http://lists.drupal.org/mailman/listinfo/consulting

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/consulting/attachments/20061224/e0a10648/attachment-0001.htm 

More information about the consulting mailing list