[consulting] Drupal considerd dangerous

Michael Haggerty mhaggerty at trellon.com
Tue Dec 26 21:02:45 UTC 2006

> With that said, we now have to admit our past weaknesses and market
> how our new strengths can over come, to ensure significant investment
> continues to be made in Drupal as a platform.

If 4.6 was a 'weak' release and businesses were not able to operate on it
effectively, please explain the Onion's Web site. Wasn't it built on Drupal
4.6, and isn't it in the top 1% sites on the Internet in terms of traffic?
If Drupal 4.6 was appropriate for the industrial strength needs of a high
traffic site, how come it was not appropriate for these startups? What were
these startups looking to do that exceeded the Onion's needs?

I understand the business issues that affect startups and am completely
sensitive to the needs of small organizations. But blaming a version release
and providing historical context from a core development standpoint doesn't
really answer anything. Why would some sites fail and others succeed? If a
choice of technology platform was directly responsible for a catastrophic
business event, wouldn't it impact all businesses, regardless if they are a
startup or not? Why would anyone still be using Drupal if it was
fundamentally flawed in such a way that it automatically lead to business

Startups rarely fail because of any single factor, and choice of technology
typically falls behind things like lack of management, unrealistic market
goals, inflated burn rate, lack of capitalization and hundreds of other
perfectly logical reasons. Making blanket statements that the platform was
flawed or overhyped really speaks poorly about the people making decisions
in these situations and does not give one confidence that other critical
business needs were being efficiently addressed.

Thank you,
Michael Haggerty
Managing Partner
Trellon, LLC
(p) 301-577-6162
(c) 240-643-6561
(f) 413-691-9114
(aim) haggerty321 

> -----Original Message-----
> From: consulting-bounces at drupal.org [mailto:consulting-bounces at drupal.org]
> On Behalf Of Kieran Lal
> Sent: Tuesday, December 26, 2006 12:25 PM
> To: A list for Drupal consultants and Drupal service/hosting providers
> Subject: Re: [consulting] Drupal considerd dangerous
> On Dec 26, 2006, at 5:29 AM, Morbus Iff wrote:
> >> out about it when the got stuck and had to pay some core developers
> >> really high rates per hour to get them unstuck. Of course core
> >> guys can
> >> build what ever they want. The swim in the code all day long and have
> >> done so for years. This does not mean it is the right choice for a
> >> startup.
> >
> > I'd like to point that it is VERY unlikely that "paying a core guy"
> > would actually cause THEM to modify *core* (where "core" is
> > described as
> > anything that ships with Drupal). Any decent Drupal developer who
> > thinks
> > the solution is modifying core is *not a decent Drupal developer*.
> > Your
> > admonition that "knowing core" is required to be good at Drupal is
> > incorrect: core developers, and the code they write, serve the lofty
> > goal of making it easier to *never modify core*. Quality Drupal devs
> > know how to do magick using only the APIs that core provides.
> I am now in contact, or about to be with at least six different start-
> ups that are using Drupal.  I am trying to get to the core of these
> problems, but I already have some suspicions.
> The web 2.0 bubble has been in play for at least three years.  I
> suspect that many of these start-ups that were hurt were early
> adopters and picked Drupal in 4.5 or 4.6.  In particular, the 13
> month release cycle of Drupal 4.7 meant that companies that started
> on Drupal 4.6 or Drupal head in September 2005 did not have the
> ability to use the Forms API to override things.  In many cases, it
> may have made sense to hack core to satisfy a client or CEO in 4.6 or
> Drupal Head pre-forms API.
> A classic example is the LogginTobbagan module which attempted to
> override a consumer unfriendly login in Drupal 4.6 and to some extent
> 4.7.  This demonstrated it was possible to override basic
> functionality in core, the user module, but it has not got the
> maintenance and support it needs.  In the hands of Jeff Robbins,
> Chad, and Angela it made sense to extend Drupal this way.  For the
> lead developer of a Drupal start-up who's management is interviewing
> off-shore developers for 1/20th of their salary, it made sense to
> hack core (patch user.module) and be done with it.
> When we hear these complaints about Drupal we are thinking about what
> Drupal can do in 5.0.  Not what Drupal was doing 20 months ago when
> that start-ups burn rate was $50-100K a month and Drupal 4.7 was no
> where in sight.  I suspect that for Drupal failures to become common
> knowledge that these technology choices were probably made 20 months
> ago, Drupal didn't meet expectation, and business funds weren't able
> to recover from the expenditures made.
> I hope that provides some context.
> With that said, we now have to admit our past weaknesses and market
> how our new strengths can over come, to ensure significant investment
> continues to be made in Drupal as a platform.
> Cheers,
> Kieran
> >
> > --
> > Morbus Iff ( rootle-dee-tootle-dee-toot! )
> > Technical: http://www.oreillynet.com/pub/au/779
> > Culture: http://www.disobey.com/ and http://www.gamegrene.com/
> > icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
> > _______________________________________________
> > 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

More information about the consulting mailing list