[consulting] Drupal considerd dangerous

Sami Khan sami at etopian.net
Tue Dec 26 03:12:37 UTC 2006


 From what I can understand in terms of what you wanted to do... it 
seems to me that at this point Drupal would be able to do what you want 
of it, which if I am reading correctly means changing a create content 
page for the blog content type to something different? Essentially the 
Form API in 4.7+ allows you to change the forms without hacking the 
core... I believe that in the past, you could've done the same with a 
static form without hacking the core -- again your developer has to be 
relatively experienced to know that... Drupal in the past did not use 
any special keys, etc, in order to verify that it generated the forms... 
it can and does now.

The direction that Drupal is going is not necessarily that it will cure 
all (or any) ills out of the box, but instead it will let the developer 
change it to meet the specific problem in a non-hackish way. But again I 
don't think that the budget is going to be on the excessive low end 
still -- regardless of how much time goes by... What you actually need 
is someone who's a Drupal coder and is committed to your cause... or you 
can convince them to get involved in your cause... Apart from that, you 
will be spending a decent amount of money for both the actual 
functionality and the appearance of your site.

Looking for a Ruby solution is essentially looking for the same problems 
from a different language and a different community which may or may not 
be weaker than the PHP/Druapl community (don't want to start a flame war 
here). The cost to maintain either or to develop them to your vision I 
think will be similar, if not more so with Ruby. The reason I make such 
a blanket statement is because one, Ruby is still early as a language, 
deployment can be an issue with Ruby as support isn't as common as it is 
for PHP, as well as scalability, though I have seem some evidence to the 
contrary that says that Ruby can scale decently to a point. The second 
is because I don't know of any other Open Source projects that are as 
mature as Drupal or even provide as much or similar functionality in 
terms of creating an on line community based website that have been 
written in Ruby and released to the public -- but I do want to be 
corrected if I am wrong. Perhaps with RoR you can roll one out in no 
time, but I think it's more likely months if you're using a single 
developer. Ber knows the community better, so perhaps he can comment on 

A good example of what I think might be your direction is this: 
http://www.mothersclick.com/ ... It's in Drupal, but again likely has a 
decent budget. Usability is essentially forms, menus, themes, and in 
general the UI... We're getting to the point (if we're not already 
there) where you can change all of Drupal without touching the core... 
But still each time you will have to upgrade your modules, themes, etc, 
to match the latest version of Drupal... which is going to come at a 
cost... and you have to bear it, or get a person who will bare it for 
you. Upgrading may be as expensive as deploying a unique solution, but 
the tradeoffs in terms of existing functionality, community, and 
security might be worth it... But I can't do any sort of TCO without 
knowing the alternatives and how well they have functioned in the 
past... and perhaps that's needed to make a fair comparison and not be 
unnecessarily harsh to Drupal or the community that makes it happen.


Kaliya * wrote:
> On 12/24/06, *Khalid B* <kb at 2bits.com <mailto:kb at 2bits.com>> wrote:
>     Kaliya
>     I can't comment on the specifics of the case you mentioned, since
>     there is so little mentioned as to what went wrong, why it went
>     wrong, ...etc. As much as I want to respond to that part, there is
>     not much to go by here.
>     However, you are making a worse mistake by saying that you are
>     "waiting for a Ruby solution for your needs".
>     None of the issues you (or Evan or others) alluded to are
>     technology/platform based, yet, you think that another
>     technology/platform is the cure-all for your ills. 
> I don't think it is a 'cure-all' for my ills. I want to build 
> something very specific that i have in mind. I attempted as best I 
> could to get that vision to manifest in drupal and it cost me a lot 
> and I didnt' get to far. It also was clear that although Dries has 
> said useability is important. It really was not going ot change at a 
> end-user level for quite a while (years).  So after hacking out the 
> 'creat content'  page that my end-users would see if they wanted to do 
> a blog post...to instead jsut go to a 'post a blog page' and facing 
> the fact that I would need to re-hack this sort of BASIC usabilty 
> again and again in the future. I just said you konw what. I am going 
> to wait.  For two reasons the market I was approaching was not ready 
> and the tool I was attempting to manifest what i watned was going to 
> be to costly.
> =Kaliya
>     Choosing a solution for its technology, and not based on business
>     needs, is BAD BAD BAD, and can only lead to problems. Clients care
>     less if your solution runs on COBOL and uses flat files. What they
>     care about is features THEY can use.
>     So, please be more specific and you will get a responds to that,
>     and do not fall into "technology X is sexier than technology Y" trap.
>     On 12/24/06, * Kaliya ** <identitywoman at gmail.com
>     <mailto:identitywoman at gmail.com>> 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
>         <mailto: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 <mailto:consulting at drupal.org>
>             http://lists.drupal.org/mailman/listinfo/consulting
>         _______________________________________________
>         consulting mailing list
>         consulting at drupal.org <mailto:consulting at drupal.org>
>         http://lists.drupal.org/mailman/listinfo/consulting
>     _______________________________________________
>     consulting mailing list
>     consulting at drupal.org <mailto: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

More information about the consulting mailing list