-Daniel

For some (older) opinions on Drupal and corporate use, see my notes after last years OSCon in Vancouver. Here’s a snippet:

“After spending the week in Vancouver, I made the following report to our management team. If we are to go forward using Drupal, we need a dedicated support-and-development team of 3 people. (And my eyeball prediictions of such things are ususally pretty accurate.) The team lead will have, as one of his/her main responsibilities, the task of being our public face within the Drupal community.”

A year (!) later, guess what. We have roughly 3 people working on Drupal full-time, plus my, the Drupal guy. Oh, and for scale, we’re over 205,000 nodes and 166,000 users at SavannahNow.com already.

That said, back on topic, I think Drupal is great for prototyping new ideas. It’s very fast once you know what you’re doing. But, in many cases, I would remove the Drupal scaffold and replace it with a custom application that does only what’s necessary.

Personally, I like drupal, even with all the frustrations. It was definitely worth the trouble to learn how to use it. I’ve deployed six sites, with more to come.

In my opinion, the people who want to set up new corporate sites using Drupal seem to be asking for trouble, because they read somewhere that Drupal will do such-and-such and so-and-so, and for some reason they think this means that it will cost next to nothing to have those features. Perhaps, perhaps not, it all depends…

Tools is tools, Drupal is a good one. Long Live Drupal!

In any case these issues are not so easy to deal with in a community based system run mostly on an unpaid basis

In the case of the performance issues tuning databases and modifying queries to support high performance is not an easy thing and is a bit of black art, and in any case it is not specific to Drupal alone.

There is also the issue of caching and one that has caught my eye is http://drupal.org/project/boost. Coupled with a system that allows logged in users to decide what type of info to cache and not to cache it can will along way if successfully implemented.

That said. Drupal is NOT the cure all CMS (Whether C means Community, Collaboration or Content). It does have it’s drawbacks, and it is not easy to learn how to use to 100%.

Drupal can probably damage your start up, if you don’t know how the system AND the community works.
You will NEVER get your Usability issues addressed the way you want by the Drupal community. Drupal is 98% developers scratching their itches. They are smart geeks, but the approach to usability is only changing slowly. I know because I’ve been part of it since 2002, and I’m not a programmer but a communications guy and a strategic web consultant.
There have been several attempt at solving the usability problems in Drupal - and TOP GUN information architects and usability people have given their feedback. Some of this has been implemented, and more will in the future.
BUT - you cannot sit back and expect the Drupal community to implement all of your wishes within 3-6 months. It takes time time time - and some work behind the scenes. What you need to do, is to change the perception of the influential people in the Drupal community, which is hard work, OR you need to do it yourself/pay someone to do it - and show the improvements.
It is not a FLAW in Drupal - it is the way such a community works, and should work. If you expect it to work the way a commercial company works, the flaw is in your thinking.

So my understanding is: “Not understanding how OSS communities work - considered harmful to startups depending on Open Source!”
And that is not a question mark!

But drupal cannot scale to millions of records; it’s not built for that. So if the content company is set up to have more than say, 300,000 records, over the life of it’s business, drupal is not the right choice.

Another problem is usability. Often what works for users, or the changes needed to make something usable for people, requires deep architectural changes. Change something in drupal, or “uncheck” it, and it would appear it can be put back or checked again, and yet, when the change it made, it screws things up so much, you can never get the original state back without reinstalling (not an option). Recode the change needed, and drupal doesn’t like it most often. Very little about drupal is compatible with regular user needs (in other words, engineers think they know what users need, but it’s really what engineers need that is adequately addressed in drupal).

I don’t think it’s always a disaster, but I think drupal is often a disaster. Making a startup is hard enough without adding the difficulties of drupal.

I would not recommend it for any serious venture.

I use Drupal and I have found Drupal to be easily configurable and with its modularization presented me with many options to consider. It is all based on focus, willingness and know how to persevere through difficult struggles. If I fail it will not be because of Drupal it is because I lost focus or ambition or both.

I started the http://for-my-kids.com site with WordPress and was less than empressed with the options I had. I went searching for something else, found Drupal, converted the site using already provided tools (thanks to a Drupal module contributor), and have the site in good working order.

I do think the point could be made by saying something like this: The start ups don’t fully understand that it can provide a basic framework but should not see it as more than that. If you start from scratch 80 percent of your time and energy will be spent creating the core system or the systems represented by Drupal Core. Its the other 20% that makes their start up a unique business and this 20% is 100% of what they should be focusing on.

Another way to look at this would be Drupal VS. Scratch. I contend that excect in rare circumstances starting from scratch is an competitive disadvantage and can’t think of one inherent benefit

The big assumption here is that they want to use the functions and not creating a software distribution for actual resale. That analysis is slightly different but not completely..