<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
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.<br>
<br>
However, as with anything else, there are many lines of disclaimers
which go with the above statement:<br>
<ul>
<li>Will Drupal be clean in terms of only providing the functionality
you want and nothing else?</li>
<ul>
<li>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!<br>
</li>
</ul>
</ul>
<ul>
<li>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. <br>
</li>
<li>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.<br>
</li>
<li>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.</li>
<li>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.<br>
</li>
</ul>
Supply and demand factors<br>
<ul>
<li>Drupal is in high demand, therefore there is a shortage of
developers.</li>
<li>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.<br>
</li>
<li>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.<br>
</li>
<li>The above premise leads again to shortage of developers which
again increases the burden of dealing with Drupal.</li>
<li>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?<br>
</li>
</ul>
Open source budgets:<br>
<ul>
<li>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.</li>
<li>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.</li>
</ul>
Simplifying adds complexity - by example:<br>
<ul>
<li>My pal, Merlin, or Earl has developed the excellent views package.</li>
<li>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.<br>
</li>
<li>A single query to a table will take you a few seconds to write
up. SELECT * FROM {table} t LEFT JOIN...</li>
<li>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.<br>
</li>
<li>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.<br>
</li>
<li>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.</li>
<li>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.</li>
<li>I post the above with the disclaimer that it's only an example, I
love views and couldn't live without it!<br>
</li>
</ul>
Upgrading<br>
<ul>
<li>Each version of Drupal breaks the previous version:</li>
<ul>
<li>Every contrib module has to be updated and there is no
guarantee that it will be.</li>
<li>Any module you write has to be updated.</li>
<li>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.<br>
</li>
<li>The database that holds you content has to be updated.</li>
<li>The Drupal code base has to be updated itself.</li>
<li>This process is getting better, with install files, etc, but
still leaves much to be desired.</li>
<li>Trying to be cutting edge with Drupal is a bad idea.<br>
</li>
</ul>
</ul>
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.<br>
<br>
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! <br>
<br>
Peace,<br>
Sami<br>
<br>
Kaliya * wrote:
<blockquote
cite="mid5629f6750612241216x16cada78t88337156c20b3181@mail.gmail.com"
type="cite">Even,
<br>
I am with you on this. I find the community attitude quite arrogant and
<br>
condescending.
<br>
I am quite familiar with one of the startups 'hurt' by the choice to
use
<br>
Drupal. It was a mistake and they and likely several of the startups
that
<br>
choose Drupal as a base were sold on the platform really hard by people
in
<br>
the community. It was pumped up to be more then it was and they bought
it
<br>
and then got into it and it just was a mess.
<br>
All I wanted to do was nice clean simple neat social networking for
<br>
spiritual leaders and groups. Without a whole lot of cost and I
couldn't do
<br>
it in Drupal. I personally am waiting for a Ruby solution for my
needs.
<br>
=Kaliya
<br>
<br>
<br>
<br>
On 12/21/06, Evan Leibovitch <a class="moz-txt-link-rfc2396E" href="mailto:evan@telly.org"><evan@telly.org></a> wrote:
<br>
<blockquote type="cite"><br>
Kieran Lal wrote:
<br>
>> There are no qualifications or "it's not always the best
choice" type
<br>
>> honest comments anywhere to be found.
<br>
>>
<br>
>
<br>
> By targeting specific uses we tried to highlight it's strengths.
<br>
> Highlighting weaknesses is not very useful as it's frequently the
<br>
> limitations of the users ability to use a tool that are the real
<br>
> weakness.
<br>
>
<br>
Well, there we have it: "There are no weaknesses in Drupal, just
<br>
weaknesses in users' ability to master it."
<br>
<br>
You have me at a loss for words, I honestly have no answer to something
<br>
so incredibly arrogant.
<br>
<br>
>> Small businesses are explicitly mentioned as a target group
for whom
<br>
>> Drupal is the right answer.
<br>
>> In fact, the page offers no realistic appraisal of what Drupal
doesn't
<br>
>> do well, which is also what people coming to such a page are
<br>
>> looking for.
<br>
>>
<br>
> What do you suggest?
<br>
>
<br>
The kind of honesty that Bill suggested. An acknowledgement that Drupal
<br>
isn't for everyone, and a frank analysis of its advantages and
<br>
drawbacks. Respect for users' intelligence rather than contempt.
<br>
Emphasis on understanding what users need, rather than what you expect
<br>
of them.
<br>
<br>
- Evan
<br>
<br>
_______________________________________________
<br>
consulting mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:consulting@drupal.org">consulting@drupal.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.drupal.org/mailman/listinfo/consulting">http://lists.drupal.org/mailman/listinfo/consulting</a>
<br>
<br>
</blockquote>
<br>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
consulting mailing list
<a class="moz-txt-link-abbreviated" href="mailto:consulting@drupal.org">consulting@drupal.org</a>
<a class="moz-txt-link-freetext" href="http://lists.drupal.org/mailman/listinfo/consulting">http://lists.drupal.org/mailman/listinfo/consulting</a>
</pre>
</blockquote>
<br>
</body>
</html>