[consulting] Drupal considerd dangerous
Sami Khan
sami at etopian.net
Tue Dec 26 03:12:37 UTC 2006
Kaliya,
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
it...
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.
Regards,
Sami
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