[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!
Upgrading
* 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!
Peace,
Sami
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