Category: Uncategorized

It's been a "best of times, worst of times" year for Apple.  There's no denying the swell they're seeing from the iPhone, new iPods, and a new release of OSX.  Apple stock looks pretty golden in a fragile market.

And yet, if you're paying attention, there are some cracks in the facade.  One by one, people are starting to notice the little problems that other companies get crucified for.

Early examples were problems with iPhone activation, phone bills, and firmware updates.  Recent examples:

• Fear and Loathing Is Not A Great Brand Image

• Update: More Leopard Problems Plague Apple

• A true story about my Mac

• And finally, me.  A few weeks ago, I lost a hard drive.  I have a backup of all of my important stuff, but I didn't have a backup of this drive, because it contains stuff I can generally replicate from other sources.  This drive had my iTunes music on it, which I could generally reproduce by re-ripping all of my CDs, or (I thought) just plugging my damned iPod back in to my computer.  I was wrong on that last count.  I plugged my iPod back in after I rebuilt my PC, and iTunes said, "I need to purge this foreign content -- everything must go!"  I literally couldn't sync my iPod again until I wiped it and reloaded my music.  On top of everything else, I also lost all my song rankings, so I've got to "re-train" my iPod to know the music I like most.

So what?  Lots of companies have problems like this.  They work through them, and the move on.  Why would Apple be any different?

Apple's different because they convinced us that they're better.

In late September, Robert Scoble posted when some people's iPhones were bricked during an update.  I blogged a response back then, and I left a comment explaining why people were more upset about these problems with an Apple product than they'd be with someone else's product:

But Apple?s supposed to be better than Microsoft. That?s their hook.

[...]

Let?s face it - an important part of the Apple mystique is the experience. Stuff just *works* when it?s from Apple, right? When people start to question that image, it?s a blow to the brand.

I suspect this isn't something that Scoble didn't already know, but I'll take credit for planting a seed, because he came back and hit this topic again this week (The brand promise of Apple).  Here, Robert starts to look at a new facet of this dynamic: Apple users love Apple so much that they'd sooner believe they're idiots than to think that Apple's done something wrong.

Wow.

If there ever was any question about the marketing prowess of Jobs, this should put that to rest.  This is really good stuff.  Since the very first marketing consultant crawled out of the primeval soup and began surveying dentists, this is the holy grail they've sought.  It's lightning in a bottle, and it's the engine that drives Apple.

A handful of brands have achieved a measure of this success over the years.  Saturn was there when they first hit the scene, and to a lesser degree, the new Beetle.  When you hear about kids beating other kids to steal a pair of shoes, this elixir is at work.

When it happens, it makes people a little nuts.

And so it is with Apple.  People see only good, and look past the rotten, let alone evil.  When iTunes refuses to recover my music, or even my song ratings -- content that I generated on their hardware -- I'm not supposed to feel angry or alienated or betrayed.  I'm supposed to subserviently ask for forgiveness on behalf of my ill-behaved PC.  I had it coming for running Windows, anyway, right?

As soon as people start to question the infallibility of Jobs, Inc., the whole brand begins to look vulnerable.  This is a fragile ecosystem, and it's dangerously close to meltdown.

How do you feel about Saturns today?

Don't think that I'm writing this because I hate Apple.  On the contrary, I think the magic they've shown us over the last five years or so is the stuff legends are made of.  Very, very few of us will ever have a chance to achieve anything like the run Apple's had recently, so I believe we've all got a lot to learn from them.  Among the things we can learn, though, is how tough it is to do what they've done, and how quickly it can be lost if you're not careful.

For another great analysis on this balance, check out this article: Apple: What Could Go Wrong

Architecture has always been a tough sell.  Except in rare cases, it's not a feature that makes the front page of the color glossy sales brocures.  Even though a failed architecture is deadly, it always seems like a struggle to allocate time and budget to invest there instead of adding more features.

Steve McConnell manages to capture the "pay me now or pay me later" dynamics of architecture far better than I ever was able to in this article about Technical Debt.  By recasting a technical subject in terms taken from the Wall Street Journal, he captures the business risk involved here in a way that a CFO can grasp.

If you're an architect, you've got to read this article.

Over the last couple weeks, I've seen some announcements in the blogosphere that tell me that some winds of change are a-blowin', and we're going to see some really positive developments in ASP.Net tools and techniques in the coming months and years.  These improvements aren't about adding capabilities, they're about making the capabilities we've already got accessible to more developers.

The C# / ASP.Net platform circa Fall, 2007 is  astoundingly capable.  If there's something you can't do with this platform, you just haven't tried hard enough.  But this power too often comes at the price of coding complexity, or just as bad, coding overhead.  If I've got to write seven layers of infrastructure to get something done, I'm not too excited about doing it anymore.

The promise of a platform like .Net is that it should support both low-level code jockeys and higher-level applications developers who are working with the business on a daily basis, because the end-game is business productivity.

Enough preamble.  First development: Scott Guthrie's ASP.Net MVC Framework.  If you've read this blog for any length of time, you'll know that Scott's blog is a must-read.  His announcement of an MVC framework for ASP.Net is major news, though it was easy to miss.  So what's the big deal?  Lots of people have done some form of MVC in ASP.net -- why's this one any different?

The simplest answer is that this one, with any luck, will be the one MVC Framework to Rule Them All.  In short, there's a lot of value in having this become a standard for ASP.Net development just so that people don't have to worry about trying to do this themselves anymore.  Unless someone has needs so completely out-of-the ordinary that this framework is off the table, it's in as a default.  Fewer decisions = more productivity.

As a second-order benefit, I hope to see UI development move away from the "one big ASPX file per web page" model, toward a more component-oriented view.  Think about the way a screen is constructed in a CMS or something like Facebook or Myspace.  This is a whole lot more modular and flexible, but it'll require a shift away from the way most pages are put together.  Go read this and see if it sparks some ideas.

The second big news flash is related.  There's a guy named Rob Conery who's been working on an open-source data-access toolkit called SubSonic.   I almost referred to SubSonic as an ORM, but I think that wouldn't quite capture the spirit of SubSonic.  In any event, the news here is that Rob is going to work for Microsoft.  He'll be working in Scott's group, in fact.

Again, so what?  Again, it's about throwing enough weight and credibility behind SubSonic that it becomes an acceptable, if not brain-dead architecture choice.

Let me explain.  There are lots of other tools and frameworks out there that compete with SubSonic on some level.  I don't care if one of them is seven percent faster or requires eleven percent fewer lines of code.   What I care about is that SubSonic (and many of the other tools in this space) are better than working with ADO.Net alone.  But while this product space is fractured and chaotic, none of these tools will be a clear leader.

For me as an architect, that means that every time I'd like to use one of these tools, I've got to explain to someone that (1) it's a really good idea, (2) it's better than any of the other seventeen alternatives - including scratchbuilding, and (3) it's going to stand the test of time.  Let one of these tools win, and that argument goes away, and I can get on with building systems for business users.

And that makes me happy.

So all of this stuff is a done-deal, right?  No, of course not.  We'll have to watch these developments play out a bit.  Scott's blog targets the first-half of next year for the MVC Framework.  Rob is at Microsoft now, but we won't see any industry consolidation around SubSonic for a while yet.  But Microsoft's endorsement, even if only implicit, gives SubSonic some momentum.  I can't wait to see these bits working together.

Further reading:

How MVC, jQuery, and SubSonic Will Make You Smile

SubSonic: MVC Preview Video

Code Magazine ASP.NET MVC article

Microsoft's interesting "embrace" of Windows Open Source

When Microsoft introduced the .Net platform, they clearly wanted to reach out to the developer community and build some connections.  The "Start" page in Visual Studio and the "Community" menu sort of show what they were aiming for.  About the same time, the "gotdotnet.com" site showed up.

GotDotNet was a community site built for MS developers by MS developers.  To be honest, I don't know what involvement, if any, Microsoft had with this site, but it was clearly a good thing for Microsoft, since it gathered like-minded developers together and gave them a place to share tips and techniques.  There's no doubt that it added value for Microsoft by promoting its tools and covering some support burden via peer-to-peer support.

Time marches on, though, and a year or so ago, the folks running GotDotNet decided to ramp it down.  Other sites were to take its place, like Codeplex to host community-build code bases, and so on.

One big problem remains, however: GotDotNet continues to dominate search results for the stuff it used to have, and there's no forwarding address if you want to find this "old" material.

Case in point: Code Snippets for C#.

I'm dropping some timing code into a project, and it's repetitive work.  It occurred to me that this was exactly the sort of thing I'd expect a "snippet" to handle:

DateTime timr = MyLog.BeginTimingMessage("Unnamed timer", 0);

<< code to time >>

MyLog.EndTimingMessage("Unnamed timer", 0, timr);

So I Google "c# snippet", and the top results point at a blog hosted on MSDN.com (so I assume he's an MS employee, MVP, or equivalent).  The post is dated 2005, and it talks about a snippet editor called "Snippy".  It's apparent at this point that snippets are slightly more complicated than just chunks of text - hence, the need for an editor.   That's fine, I thought - I'll just go grab the editor and be on my way.

So I follow the link in the blog to GotDotNet, and see this "so long, and thanks for all the fish" message:

Great.  I did my best to find a breadcrumb trail leading out of this abyss, but to no avail.

In this case, it turns out it wasn't the end of the world.  I never did find "snippy", or any other snippet editor, for that matter, but I found the MSDN documentation that let me create the XML from scratch.

But the thing that really bugged me was that Microsoft would let this play out the way it did.  How much effort would it really have taken them to step in here and find new homes for the files on this site and to provide forwarding links to guide people to the new homes?  Don't they have interns??

Here's a site that's got a bunch of top Google spots for searches about Microsoft development topics.  All sorts of Microsoft developers are going to hit these links, and they're going to be spending real time navigating around on a wild goose chase for community content, all the while muttering about how they wouldn't have this problem if they were looking for something on Sourceforge.

It's a blown opportunity for Microsoft to take care of the developers who are driving the demand for their products.

Easy come, easy go.

There's a huge amount of news today about Google's new OpenSocial platform API.  It turns out that everyone but Facebook has already announced that they're on this bandwagon.  So what?

Does anyone remember the big news about Facebook just before this whirlwind hit??  Remember Microsoft paying out buku-buku bucks for a percentage stake in Facebook?  Remember that??  Facebook valued at $15B??

I'm really surprised that nobody's asked this yet, but do you still think Google would've rolled out OpenSocial if they'd won that bidding war instead of Microsoft?

Pause for effect.

Ok, so realistically, there's probably still a decent chance Google would've introduced this platform at some point, but I'd bet that Facebook would have been on board.

What's going to happen here?  If OpenSocial shows any signs of momentum at all, Facebook is gonna be on the thing eventually.  But -- Facebook loses its big shot at world domination.  After all, a couple weeks ago, people were talking about Facebook knocking Google off the top of the hill, and they were almost serious.

That's gone now.

You know what else is gone?  Facebook's $15B valuation.  Poof!

Ballmer's got to be three shades of purple in the face right now.

It's a big-stakes chess match out there, and this was a money move.

The first time I ever saw a Wizard dialog used in a software product, I thought it was a pretty good idea.  If memory serves, this was right around the introduction of Windows 95, and Paula Abdul was still a singer.  Software designers were still coming to grips with the graphical user interface, and let's face it - the toolbox wasn't too extensive at this point.  You could build any interface you wanted as long as it was gray and consisted of text boxes, radio buttons and check boxes.

Users were also still learning Windows, so as forms grew in size and complexity, their eyes began to glaze over.  The wizard appeared in this barren land, and it offered hope.  Bite-sized chunks of user interface, punctuated by "Next" buttons (perhaps inspired by the rash of "to be continued..." TV episodes that also seemed popular at this time).  The best wizards also featured colorful graphics to decorate the panels - all very slick.

Wizards, of course, became a victim of their own success.  They multiplied until they reached critical mass.  Wizards were everywhere -- especially, it seemed, where they weren't really needed.

Time and technology, of course, continued to march inevitably forward.  Our tools improved.  Our toolboxes grew new UI widgets.  Al Gore invented the Internet. 

Slowly, designers moved on to embrace these new tools and take up the banner of Usability.  Alan Cooper taught us about affordances.  Wizards were so Windows 95.

 

Appropriate Wizard Use

So has the Wizard been forevermore wiped from our pallet?

No - in fact, there are still places where a Wizard UI makes sense.  They're still quite common for setup or configuration changes where you may want to go back to where you started if you screw up along the way.  They're also used for editing business objects where a "valid" state requires a lot of data entry, and you don't permit "invalid" data to be saved.  I'll talk more about this case later.

  What factors tell you you've got a candidate for a Wizards?

• Complex operations.  Your app needs to collect a lot of information.  Maybe the data from one field affects the options available for another field.
• Transactional operations.  There are distinct sections or steps in an operation, but they all should occur together in order for the operation to be considered complete.
• Ordered operations.  It matters which things are entered first, second, and so on - again, perhaps because the answers on page one affect options on page three.  Generally, wizards let you go backward to edit prior answers, but they won't let you skip forward.

Generally, at least one of two of these should be true before you use a wizard.  The wizard features some UI elements and characteristics that uniquely satisfy these needs:

• Segmented UI.  Complexity is managed by separating a big ol' hunk of data entry into bite-sized panels.
• Contextual "Next", "Back", "Cancel", and "Finish" buttons.  These buttons appear only where they make sense ("Finish" won't appear until all required information is gathered, for instance). 
• "Cancel" and "Finish" make the wizard transactional.  The whole wizard either succeeds, leaving you in a "good" state, or it rolls back to where you were prior to starting the wizard.  There's no such thing as bailing out in the middle with half your data set up.

 

Wizard Misuse

So, where do wizards not work?

The biggest problem I've seen with wizards are using them as a general data entry strategy.  I'm trying to unravel a UI right now that had been designed to feature very prominent use of wizards.  Add and edit screens, for instance, were designed as multi-page wizards -- and this was done for all of the objects in the system.

How does this violate the usability principles above?  In most of these cases, there's a lot of data to enter, but the relationships really aren't very complex.  There's no order; in fact, the wizard allows the user to skip to whatever step she wants.  News flash: this isn't a wizard anymore; it's a funny-looking tab control.

To make matters worse, this UI is on web application, which forces the web app to incur a ton of extra overhead to accommodate the transactional expectation of the wizard.  In one case, the UI even calls for a nested wizard, where you start one wizard from the middle of another one.

This would be awkward in a Windows app, where you've got real modal dialogs, and the rest of the rich UI tools needed to make this work technically.

In a web app, though, you've got the competing expectations that when you move from page to page, your work is saved; yet, when you hit "cancel" on the last wizard step, you're supposed to roll back your changes.  What a nightmare!

 

Wizards for "Must-be-valid" objects

Earlier, I pointed out that one of the places where wizards are commonly used was to make sure that a complex object has been properly entered and validated before saving it.

If this is really a legitimate requirement, then a wizard control might be a good choice for you.  I believe in most cases, however, you're really doing your users a disservice by "protecting" them this way.

I've seen these dialogs really frustrate users who get 3/4 through setting something up, only to find that they're missing a piece of information.  They then have to abandon their work to go figure out how to get past that hurdle.  In most cases, the system is much more usable if it allows the user to save whatever they've typed, and simply tracks the fact that this object isn't valid in its current state.  Let the user come back and fix the broken bits later.

 

What are your wizard nightmares?

I've been implementing SugarCRM in a hosted environment, and in contrast to my earlier post about great open-source customer service, this is a case where customer service is dragging down a product that would otherwise be quite good.

In fairness, I'll start with the good news.  Setup happened really quickly, with SugarCRM already loaded and running.  Mail worked, and I was able to set up ZuckerReports, which I'd been worried about, since I'd had trouble with that on a local test system.  Speed seems great, too.  There's no indication that the servers are taxed, no matter what time of day I check.

So what more could I want?

The problem is subtle, but really nagging.  The permission and ownership settings are all fouled up.

I'll try to describe the problem without dwelling too deeply into Unix / Linux tech-speak.  Linux files are owned by a combination of a user and a group, expressed as "user:group".  Permissions for these files are expressed in terms of who can do what, depending on whether you're (1) the owner of the file, (2) a member of the group that owns the file, or (3) anybody else.

Processes run as users in Linux, so I can log in to a Linux machine had have a set of permissions as "me", but when I do something via a web page hosted on that machine or an ftp session with that machine, I'm working through the web or ftp service, and I'm subject to the permissions granted to that service's user.  This is one of the ways Linux keeps itself secure (you may be able to compromise one account, but you wont be able run amok).

So here's where the trouble starts.

First problem: The web server is a different user than the user we are when we log in via ftp.  Different groups, too.  So when I ftp something up to the web site, it gets saved into the web file area, but the directories and files belong to "me", not the web server.  This isn't a problem unless it's a directory or file that SugarCRM wants to be able to change itself, and there are a surprisingly large number of those.

SugarCRM exacerbates the problem by (frequently) politely swallowing error messages, so what you see is a system that's happily puttering along while things frustratingly fail to save / update.

Next problem: Some SugarCRM customizations need to modify files on the server.  SugarCRM has a (generally) really nice feature called the "Studio" that lets you accomplish many customizations via meta-data and custom files right on the SugarCRM server, in near-real-time.  This makes short work of simple jobs like adding a field to a screen or customizing lists or drop down values.

When you make these changes, however, the web server has to be able to save them, and in some cases, this requires the web server to add one or more directories in order to maintain its structure.  Sadly, this also isn't working on our host.

I can frequently tell when I'm dealing with one of these problems, because they're goofy (something that should obviously be working just as obviously isn't) and because the exact same thing works on my test system.

Here are the two most recent cases where this setup has bitten me:

• I needed to modify the Leads listview to include another column. Normally, this is a five-minute fix in SugarCRM's studio, so I went in and customized the listview to include the extra field.  I saved the view and went to test it, and no change had taken place. I went back into the Studio and found that my changes had reverted.  I did the same customizations on a local test system, and they worked just fine. I noted the most recently-modified files and saw that custommodulesLeadsmetadatalistviewdefs.php had been changed.  Back to M8 - I used file explorer to look at the directory structure on the production server, and found there was no "metadata" folder beneath "Leads". When Studio tried to create that directory so it could store the newly-customized file, the web server process had been unable to make the directory. If the directory had been created, I don't know if the web server would have been able to create a new file there, but I wouldn't be surprised if that failed, too.  I was able to get the changes to show up only by manually creating the folder and then uploading the file I modified on my test system.
• I tried installing Ken Brill's advanced search module.  Now, I know that Ken knows how to package modules, and this one went in without a hitch on two separate test systems, but when I installed on the production system, I got an error complaining about permissions.  The workaround in this case was to CHMOD 777 for a couple of big chunks of the directory tree, and then set permissions back to "normal" after installation.

Now, I've begged and pleaded with M8 to get shell access so I could chown these files and directories properly, and they finally granted this to me, but my login didn't have permission to chown to the proper user and group so the web server would be happy again, so I'm still stuck!

This is driving me nuts, and I can't seem to get M8 to understand the problem.

Has anyone else experienced this with M8 or other providers? I'm afraid if this doesn't get resolved soon, I'm going to have to look for a new home for this site.  Needless to say, if anyone knows a good SugarCRM host, I'd be interested in that, as well.

I subscribe to Scott Adams' blog feed, and his posts are usually amusing to some degree or another.  What may surprise you, though, is how often there's a nugget or two in one of his blog posts that can actually make you stop and think.  Today's post, for instance, was intriguing in much the same way that an unidentified odor is intriguing.  Like the odor, I'll be thinking about this for a while.

Scott thinks he can solve all of our problems.  I think he might be right.  (sniff...)

Here's the plan: Scott turns our national problems into a reality show.  Panels compete to solve the problems, judges zilch the William Hung solutions, and we vote on the rest.

Crazy?  Crazy like a fox, if you ask me.

Software people should be able to appreciate the opacity problem with today's legislative system.  Wayyyy too much stuff is happening in smoke-filled rooms to have any hope of a good outcome.  Like open-source software, I think there's goodness to be had in opening the legislative process.  Let's go ahead and look into the sausage factory.  And no, I'm not talking about CNBC.

It's pretty easy to lash out against something like this on the principle that it just can't possibly be right.  You might not be able to put your finger on the problem right away, but it just can't be right.  After all, the panels aren't elected, the judges aren't elected, and how would you police voter fraud?

But here's where the stink wafts into the room again.

Despite these flaws, I think I'd trust this system more than I'd trust Congressmen making backroom deals with lobbyists, while political contributions are rewarded with pork barrel spending and all sorts of palms are getting greased, none of which belong to me.

At this point, you might be oddly excited that Adams has found a better form of government, or you might be despondent over the fact that our government is so deeply fractured that a whacked idea like this can even elicit a moment's consideration.

Me?  I've got to go find a can of Lysol or something.  This smell is making me nuts.

My, how the mighty have fallen from grace.

Not long ago, Apple (especially the Mighty Mr. Jobs) could do no wrong at all.  They were the cool geeks, leading the world out of the dark canyons of Wintel captivity.  But slowly, ever so slowly, chinks have appeared in their iArmor.

You've probably seen the latest - Apple is fighting like hell to punish the free spirits who've dared to unlock their iPhones.  One update after another is pumped out by Apple, preventing people from loading their own MP3s as ringtones, and now bricking the unlocked phones.

But now, reports are starting to come in that some people who haven't tampered with their phones are having problems with these updates, too.  This is going to really hurt Apple.

These are some of the same people who stood in lines for hours and hours just to buy one of these new phones.  Why?  Because Apple wasn't just another phone company, and they weren't going to treat their customers like regular phone customers.  No, these people were special.  They were the iFaithful.

Sorry, folks.  Apple's chasing those bad, bad iUnlockers with such vigor that they're running over their best customers.  That's going to leave a mark.

In case you're keeping score at home, kids, here are some of the lowlights Apple's hit over the last few months:

• Jobs stock option scandal.  Teflon Steve seems to have wriggled out of this, but we'll see if he stays clean.
• iPhones can't be activated (link no longer active).  Apple sells half a million phones, but only 146,000 are activated because AT&T customer service bites.
• No open platform for iPhone (link no longer active).  In today's Facebook and widget environment, more people than ever understand why open is good.  Steve doesn't.
• iBills come in boxes.  Not looking too green, Apple.
• Ringtones are locked.  Then they're unlocked.  Then they're locked again.
• New iPods have problems.
• Apple bricks unlocked phones.
• Apple messes up "good" phones.

Let me know if I missed any.

So I really think someone should jump on this and make a new "Mac Guy" vs. "Motorola Guy" or "Sprint Guy" or something like that where the Mac Guy is stuck in jail, or Steve Jobs comes out with a hammer and pummels his phone or something.  Let's see who's got the moxie to take the first shot - I can't wait!

You can tell the difference between a Kia and a Mercedes with your eyes closed, can't you?  It's more than the look of the car; it's a host of little experiences that tell you how the car was built, and that someone really sweated the small stuff.

You can feel quality when you reach for a knob - it's in the right place, even though you've never thought about what the right place is.  You can feel it when you twist the knob or flip a switch - you can tell that knob is going to be working just fine the umpteen-thousandth time you reach for it.

Doors are a good place to look for quality.  I owned an Acura a couple years ago, and it had a little electrically-actuated finger that grabbed the door when it reached the door frame and pulled it in tight to latch.  I hardly ever noticed it until I got rid of the car, but then I really missed it.  Other high-quality cars pride themselves on a solid, muted "chunk" that could just as easily come from a bank vault.

Software has quality, too.

You may not be aware of the dozens of subconscious signals that transmit software quality to you, but they're there, too.  The first thing that people think about when "software quality" comes up is coding quality - how many bugs are there?

You've probably seen the jokes that talk about using the horn, turn signal, and gear shift to restart the car when it breaks - that's a reference to coding quality.  We don't want our cars to leave us stranded by the side of the road, and we don't want our software to puke its guts out all over our screen every time we look at it sideways.

Coding quality gets a lot of attention from QA departments who want to automate them away, and from development departments who want to unit-test them away.  Coding quality improves when teams work together, and when individuals learn the craft of software development (hint: pick up a copy of Steve McConnell's Code Complete).

But coding quality isn't the end of software quality.

Design quality is perceptible in the layouts of screens and the ease with which new users find themselves around for the first time.  It's like the bank vault car doors.

What is platform quality?

Platforms show their usability in all these ways, but there are other aspects of platform quality that are more subtle.  I've been working pretty extensively with two different platforms over the last several months, and I am struck every day with the difference in "feel" I get from these two platforms.

Drupal is a Content Management System (CMS).  It's the software that powers  this blog, and I've also deployed it into a couple other environments.  I have worked with other LAMP-based CMS systems (PHP-Nuke, PostNuke), and I have no problem putting Drupal on a pedestal above those other platforms.  Drupal does enough things so very, very well that I've begun to think of it as a general-purpose web platform rather than just a CMS.

I like it a *lot*.

SugarCRM is a Customer Relationship Management System (CRM / CRMS).  It's a Salesforce.com competitor, and it's available in open source (Community) and two paid versions (Pro and Enterprise).  Even though I'm going to pick on some aspects of SugarCRM, I have to begin by saying that I really admire what they've done.  The value to be had here by customers relative to the commercial alternatives is impressive.

But where Drupal inspires confidence to look for new places to use it, SugarCRM makes me want to stay in its comfort zone.  I'm pretty sure SugarCRM is going to do well at the things it does natively, but extending it hurts.  Salesforce.com is actively working to transform their CRM platform into a general-purpose web platform, but SugarCRM isn't ready for that yet.

Even though these are two completely different applications, they are similar in the sense that in most implementations, the "stock" product isn't quite right for the job.  That's clearly true for Drupal, where you are very likely to customize the UI and add modules to get the right mix of functionality for your site.

SugarCRM is more likely to have most of what you need out of the box, which is a testament not only to the complex nature of the CRM space, but also to the high level of functionality in the box.  It's probably also fair to point out that the business processes and data relationships in CRM are more complex than for CMS, but for now, I'm going to ask to have my cake and eat it, too.

I'm going to compare these two platforms in a number of areas, pointing out the ways that each of them build up or tear down my confidence in the platform, and where applicable, showing where an idea from one would work really well in the other.

(stay tuned for more on this in future posts)