From the category archives:

Web Tools

Open Source vs. Proprietary: Web Server Software

by Pearlbear on April 25, 2011

By Web Server Software, I mean the software used to serve websites/pages. This includes databases, operating systems and other software that is involved in that process.

On the proprietary side, there are two options. Proprietary Unix, and Microsoft Windows, and associated Microsoft Software. The current version of MS Server in use is Server 2008. Microsoft has web server software called IIS, and it’s database server product is MS SQL server, which people use for far more than just serving web site data. The primary web development framework used in this environment is .NET.

Proprietary UNIX has dwindled greatly in popularity with the increasing popularity of Linux. On top of proprietary UNIX, people will generally run associated open source server software for web, database and development frameworks.

On the open source side, Linux is by far the most popular, with BSD in second place. Both Linux and BSD come in several flavors (or distributions.) Apache is by far the most popular web server software. MySQL and PostgreSQL are the open source database systems most in use for web servers, with PostgreSQL being a pretty distant second to MySQL. Other database systems (such as NoSQL variants) are increasing in popularity, but are pretty far down from MySQL as well.

Also, it is possible to run Apache, most varieties of open source databases and web frameworks on Windows, and that is not uncommon.

It’s hard to know what the market share of server operating systems are, because there are different ways to measure it. You can measure how many units are sold. By that measure, Windows is first at about 49-67%, Linux is second at 16-23%, and proprietary UNIX is third at 7-22%. That underestimates things like self-installed OS systems (standard with Linux), as well as VPS systems. If you measure by surveying publicly accessible websites, you get Linux first at 41%-74%, Windows second at 20-42% and proprietary UNIX third at 2-5%. This underestimates servers inside enterprises. (source: wikipedia)

From my perspective, the underestimation of self-installed and VPS systems by the first measure far outweighs the underestimation of enterprise servers, because plenty of organizations and enterprises also install Linux behind the firewall. It would make sense to me that the true number is much closer to the estimation by publicly accessible websites, rather than the unit sales estimation. So on the OS side, Linux does look like it wins.

Apache is far and away the most popular web server software. It is way ahead of IIS. The most recent data from Netcraft shows that Apache has 63% of web servers, compared to 19% for IIS. Also, Apache is showing a clear upward trend, and IIS a clear downward trend.

 

{ 1 comment }

Tools I use: basic workflow

by Pearlbear on April 12, 2011

I was perusing Social Source Commons (something I don’t do nearly often enough,) and catching up on the SSC blog, and I thought it might be worth sharing with this audience what tools I use for basic consulting workflow. I’ll do another few posts for other areas, like development, system maintenance, personal web presence, and writing.

(If you want to look at my Social Source Commons toolbox, it’s here. It’s not so up to date, and it’s a list more of tools I have used, and some I still use.)

The center of my workflow, like for most consultants, is email. I’ve used a variety of email clients of one sort or another over time, and I have recently just decided to ditch them, and use gmail exclusively. I have definitely noticed that I’ve been migrating a lot of functionality of things that I do to web-based apps of one type or another, and this is one example of that. I use Canned Responses to provide HTML signatures when needed, and also forward all of my mail to gmail, then send out mail as other identities. (I’ve learned how to circumvent that annoying thing of “Sent on behalf of” in gmail – use the SMTP of the email alias you’re using.)

What’s also very close to the center is my project management tool, Redmine. (I’m actually now using a very recent fork of Redmine, called Chiliproject.)  I’ve waxed on about this tool ever since I’ve found it, and I would love to challenge a loyal Basecamp user to a point-by-point comparison of the two tools. I think it knocks Basecamp right out of the water. It’s core is a very powerful and flexible ticket tracker, but it includes all of the important project management features you want and need, milestones, time tracking, wikis, file repository, even discussion boards, and it connects with version control repositories. It works for multiple projects. And, it’s open source, and isn’t even that hard to get set up and running.

Another important tool, which I use in my personal life as well as consulting life, is Evernote. Evernote rocks my world. The web interface is great, as is the desktop application (which I use cross-platform – the Windows version works great with WINE). I also access Evernote on my Android phone. It’s a great tool. I use it for to do lists, stuff like blogging calendars, and also the Chrome Evernote extension allows for clipping of whole web pages, which I love (there is a Firefox extension as well.)

A tool I’ve recently come to adore is Passpack. It is an awesome web-based password management tool for teams. I love the collaboration features. For sharing files, as well as providing solid file backup, I use Dropbox (it even works on Linux!)

And, like all consultants, workflow involves documents and spreadsheets, and for that I mostly use LibreOffice, although sometimes using Google Docs makes sense for collaboration. I use Google Reader for RSS feeds, and TweetDeck, or, more recently, HootSuite for Twitter (I really like the tabbed interface of HootSuite. It makes looking at the variety of lists I have a lot easier.)

 

Open Source vs. Proprietary: CMS

by Pearlbear on April 4, 2011

Content Management Systems are an essential part of the communications function of nonprofit organizations. There are a myriad of options, open source options are among the most popular, possibly the most popular.

I’m going to focus here on the nonprofit sector, and options that are most common among nonprofits.

On the proprietary side, there are a number of options, and they fall into three categories:

  1. Single-source proprietary custom CMS (from one web shop, or web host)
  2. Proprietary CMS as part of a large package (such as from Convio or Blackbaud)
  3. Proprietary stand-alone CMS (such as Sharepoint.)

You already know what I think about option 1, so I won’t belabor it here. Many people have found that option 2, using a large package, which includes donation pages, event management, etc. can be a really good option, and I certainly don’t want to say that this is not a good idea – I think it can be – but it also can be quite costly – and for many organizations, it’s overkill. And there are open source options that can do much of the same work for much less money.

There are not a lot of stand-alone proprietary CMS systems in nonprofits these days. Microsoft Sharepoint might be the most common I’ve heard of. Ektron is another one that I’ve heard folks talk about, as well as ExpressionEngine. The advantage of using Sharepoint for Microsoft-centric shops is that there is full integration with lots of internal network resources.

The open source options are many, but the big four: WordPress, Drupal, Joomla, and Plone, stand out from the pack. As you know, I am pretty loyal to Drupal (and secondarily, WordPress) but I have to say that Joomla and Plone are solid, wonderful projects, with great communities, and active development, and will serve you well. Check out Idealware’s newish comparison of the four – it can help you figure out what’s best based on your needs.

Other open source options that I think are worth looking at include: Alfresco, which is heavy on the document management functionality and DotNetNuke, which is based on .NET, and somewhat popular among Windows users. Two up and comers I am very interested in following include Radiant and Refinery, both based on Ruby on Rails. There is also Django-CMS, written on top of the django framework (a python framework.)

If you’re really interested in open source CMS options, and looking not for data on features, but for data on popularity, marketing, community and such (a good idea if you are, for instance, a shop deciding what CMS systems to develop with and support) check out this report from Water and Stone (a digital marketing agency.)

I think on the whole, though, the number and richness of options on the open source side is quite a bit better than that on the proprietary side, and until I get an answer to this question, I can only guess that open source options have won over proprietary ones in the nonprofit sector.

{ 5 comments }

Drupalcon Highlight Reel

by Pearlbear on March 31, 2011

I didn’t make it to Drupalcon Chicago, but, thanks to the organizers of the conference, it doesn’t mean I need to miss the sessions. I’ve been looking through videos both the regular sessions, as well as the ignite sessions (thanks, @gregoryheller), and here are my highlight presentations (this does reflect what I’m interested in more than it reflects what’s the best of DrupalCon):

Drupal/Salesforce Integration

by Pearlbear on March 23, 2011

A bit over a year ago, I wrote a post about the status of Drupal/Salesforce Integration. I figured it was time to do an update.

At the moment, if you want to integrate Drupal and Salesforce, you have three options:

  1. Use the contributed modules (or have a developer install and configure them for you).
  2. Use Jackson River’s Springboard.
  3. Roll your own (or have a developer roll your own for you.)

I’m going to talk in much detail about #1 in a bit. I’ve not had any experience with Springboard, but it’s important to understand that it is not open source, and is only maintained by one shop. That is going to be an inherent weakness – no matter what. I don’t know enough about it to match it to the contributed modules, but it’s hard to imagine that it’s possible for it to keep up, given the nature of open source development. All of that said, it’s supposed to be an interesting all-in-one sort of option, so it’s probably worth a look.

Rolling your own is always a precarious proposition. I frankly can’t imagine much of a situation where  it would be preferable to modifying what’s available and contributing the mods back.

So what is the status of the Drupal modules? Right now, there is an alpha release for Drupal 6, which is alpha in that very humble open source sense – it’s being used in quite a number of production sites. It includes some great stuff. You can see an overview here, in the slide deck for a talk given at NTC last week, which compares the integration of Salesforce with 3 of the big open source CMS platforms, Plone, Drupal, and Joomla.

There are four major projects:

  • Salesforce Suite, which includes:
    • The API – the core module that does the communicating with the Salesforce API
    • Contrib – a module that provides support for import/export from contributed modules
    • Export Queue (experimental) for queuing exports
    • Import – importing data from SF
    • Match – for matching objects before creating new ones
    • Node – for linking Drupal nodes to SF objects
    • Notifications (experimental, sort of – it’s worked quite well for me) – allowing Drupal to handle SF outbound messages
    • User – matching users to SF objects
  • Salesforce/Ubercart – provides integration for Ubercart. Uses the Salesforce Suite API
  • Salesforce Feeds – allows for feeding SF records into Drupal via Feeds. Also uses the Salesforce Suite API
  • Salesforce Webform – Allows for passing data from a Drupal Webform to Salesforce. Currently does not use the Salesforce Suite API, and cannot be used on the same site as the Salesforce Suite, but hopefully that will change soon.

All of these modules are actively maintained, there is an active base of folks using and contributing (including me) and there are plans afoot for Drupal 7, with big improvements. Of course, there are still some snaggy spots, and it helps if you know some about Salesforce to have this work really well, but I’ve gotten good results doing two-way sync of user and node data with the Salesforce Suite, as well as used the Salesforce Feeds module some.

If you use Salesforce, want integration, and are pondering a CMS choice, definitely check out the overview slides. If you are using Drupal, want integration, and considering a CRM, definitely consider Salesforce. And if you are already using both, and looking to find ways to integrate them, drop me a line, I can either directly help you, or point you in the direction of folks who can.

 

 

{ 2 comments }

Open Source vs. Proprietary: Nonprofit CRM

by Pearlbear on March 16, 2011

CRM systems (which I am defining rather loosely, rather than tightly, for the purpose of this post – as the tool or set of tools used to track constituents, donations, perhaps even events and volunteers) are arguably the most important technology tools that nonprofits use. Organizations use this tool to track donors, send out newsletters, track the success of campaigns, track who is engaged with the organization in what ways, etc.

And, in my experience over the past 15 years, it’s where organizations are willing to spend the most money on technology – often more than on their website or other technology tools – for good reason. Because of this, the deck has always been stacked against open source tools in this arena. The sheer number of vendors providing this toolset for nonprofits is huge (although rapidly shrinking.) Two of them (Convio and Blackbaud) are even publicly traded companies, which says a lot about the profit potential of this vertical.

On the proprietary side, there is a wide range of available tools, from the relatively inexpensive, like Salesforce (web-based, including Convio Common Ground and the Nonprofit Starter Pack,) eTapestry (web-based, now owned by Blackbaud), Democracy in Action, and GiftWorks (desktop) to the egregiously expensive (you know which ones I mean.) Both NTEN and Idealware are the best sources for information about the range of options for this toolset – that’s out of scope for this post.

As you can tell, I’ve lumped SaaS tools like Salesforce, DIA and eTapestry in with proprietary in this post – that’s because that’s what they are – proprietary. However, Salesforce in particular has a leg up that most other proprietary tools don’t have, because of their open APIs and their incredibly robust development platform. That combination is impossible to beat if you need integration, ease of data movement, and a lot of customization. From my perspective, open data (via open APIs) can sometimes be more important to consider than whether or not a tool is open source – since integration with other tools, as well as using external tools of various sorts is critical. Closed data systems, difficult to integrate systems, or systems that require payment to get access to your data should be avoided at all cost.

On the open source side, there are a number options: you can choose an open source CRM package (designed for business), like SugarCRM, and use it or customize it for use in a nonprofit, use CiviCRM, or choose the desktop-based nonprofit CRM called MPX (built by a company called Orange Leap.) I’m excited about a new Drupal project called “Red Hen CRM” but it’s very fledgeling.

CiviCRM is a web-based open source nonprofit-focused CRM/Donation management tool. It’s been around for a while now, and is used by many organizations, some quite large (like the Wikimedia Foundation.) It is quite broad in its feature set – it has donation pages, event management, e-newsletter functionality, even a case-management system. I’ve installed, configured and administered CiviCRM many times, still work with it, and I have, like most developers, a love/hate relationship with it:

  • I love that it’s open source/free software
  • It’s got a great community of developers and users
  • I love that it’s feature rich – you cannot find the whole set of things it does in any proprietary tool that I’ve seen.
  • It is a tool that has unmatched cost-effectiveness for small organizations
  • It’s great that it integrates with both Drupal and Joomla (although the Drupal integration is by far the most solid – and it is a very nice integration – hard to get with proprietary tools.)
  • It is relatively easy to set up for most functionality

But …

  • Data migration into CiviCRM is often nightmarish (this is really where the hate lies)
  • Reporting tools are improving, but don’t match the proprietary versions
  • It can sometimes be pretty tough to handle complex issues
  • It can be tough to troubleshoot issues

MPX is a desktop tool, and although it is open source (GPLv3,) unlike CiviCRM, or SugarCRM, it is built on top of a proprietary stack (.Net/MS SQL Server.) It has primarily been used in faith-based organizations (that is Orange Leap’s primary client base.) But it’s a very full featured product, and quite mature.

So if you are a small organization that perhaps is still working with spreadsheets, CiviCRM is a great idea to check out. But in general, there are a lot choices and, sadly, few of them are open source.

 

{ 6 comments }

Alternatives to MySQL

by Pearlbear on March 14, 2011

For those of us that depend on MySQL everyday, the buyout of Sun (which had bought MySQL) by Oracle did not bode well. A decidedly biased survey by the folks behind PostgreSQL suggests that many people worry about the health of MySQL in Oracle’s hands. I’ve mentioned this before, and I do think the conventional wisdom is that open source software (which includes OpenOffice.org, MySQL and Java) will not flourish at Oracle. It makes sense – Oracle has never had a culture of fostering open source software, and it seems unlikely to obtain one.

So what does someone do who builds their houses right on top of the LAMP stack (M standing for MySQL)?

For most folks, especially if they build on shared hosting infrastructures, this just isn’t an issue. They depend upon their hosting providers, for whom it may or may not be an issue – but they won’t have to think about it. For those folks in a position to choose which database software to use, (for example, you use VPS systems like Amazon, Slicehost, Linode, etc.,) then I think there are two pretty good options:

  • Go with MariaDB, which is basically a drop-in replacement for MySQL (and conveniently starts with an “M”.)
  • Switch to PostgreSQL.

MariaDB is a branch of MySQL that came about because of the uncertainty relating to Oracle’s ownership of MySQL. From the website:

In most respects MariaDB will work exactly as MySQL: all commands, interfaces, libraries and APIs that exist in MySQL also exist in MariaDB. There is no need to convert databases to switch to MariaDB. MariaDB is a true drop in replacement of MySQL! Additionally, MariaDB has a lot of nice new featuresthat you can take advantage of.

The problem is that the major Linux distributions (Ubuntu, Debian, RedHat) don’t yet have MariaDB in their repositories, so it will be a while before MariaDB is an easy apt-get or yum away from installation (there are some independent repositories and builds.)

PostgreSQL is a different beast entirely. It’s been an also-ran in the open source database race, and I was, for many years, quite faithful to it. It’s a very solid database, and it was ACID compliant before MySQL was. It’s major weakness (and why the LAMP stack is called that and not the LAPP stack) was that it was a fair bit slower than MySQL. But  that weakness has long been taken care of, but the damage was already done.

Many open source web database systems can use PostgreSQL instead of MySQL at this point. But PostgreSQL doesn’t have the same large user base, and doesn’t have many of the same web-based and desktop tools that MySQL does. There are differences in the SQL commands and such, and the command-line interface looks different. There is also a big difference in how Auto-numbered fields get handled, but that’s not really an issue that folks who don’t dive into deep database and code need to deal with.

So which to go with? It probably makes sense to wait a bit, first for MariaDB to make it into mainstream repositories, etc., and also to see what the fate of MySQL is. And checking out PostgreSQL is always a good option, it’s a very good database system, and the likely flight from MySQL might do the project some good.

{ 3 comments }

The Good, the Bad and the Ugly RFPs

by Pearlbear on March 3, 2011

In my time working on web development for nonprofit organizations, I’ve seen more RFPs than I can even begin to count. I’ve even written a few. And, especially since I’ve primarily been someone in the role of having to respond to an RFP, I’ve gotten pretty good at spotting RFPs that I feel don’t serve either the organization, or the developers well. Here is, in my estimation, the good, bad, and ugly in the realm of RFPs.

I’ll start with the bad. A mistake I see very often in RFPs is an imbalance in what is articulated in the RFP, and the kind of work that is required to pull off what’s needed. Let me give an example: An RFP for a new website has 2 pages describing in detail needs provided by any modern CMS (web based WYSIWYG editing, drop down menus, new pages easily added, contact forms, etc.) and then a phrase dropped in like “integration with our CRM,” or “event management system,” without any detail as to what these things really mean (like, what is the CRM and what kind of integration is needed, etc.) This invites a world of hurt, as you can imagine. Kind of like the sound made when the Man from Mars starts eating guitars in the Blondie song.

Then there is the ugly. The mistake that organizations most often make is that they have a five- or six-figure imagination, and a four-figure budget.

So what’s the good? What makes a good RFP?

  • Do your homework: know what kinds of software options available to build the kind of system you want, and know what their capabilities are, and how much it generally costs to implement those basic capabilities. Learn about how hard customization of those platforms are (some are much easier than others.)
  • Understand that integration of most any two different systems is going to be four times as hard as you think, cost at least three times as much, and will do 1/2 of what you expect or want.
  • Hire a strategic consultant who really understands technology and the technological details of what you are looking for to help you figure out whether or not you can afford what you really want, and how best to articulate those needs in an RFP. Even an hour or two of their time will save you money and headaches. Someone who is a developer or who has been one in the past is a good bet.
  • Read this slide deck by Gunner of Aspiration!!

{ 2 comments }

How to deal with technology change

by Pearlbear on February 18, 2011

I saw a call for a ColdFusion developer on an email list I’m on, and I couldn’t help but think about technology choice and change, particularly in the website world, and how nonprofits deal with technology change (or, don’t deal with it.) ColdFusion has been around for 15 years (more than a century in Internet time), and although it has improved and developed, technologically, it has been surpassed by its successors (including PHP, Java, Python, RubyonRails, and even .NET.) But this article isn’t about CF, it’s about technology change.

Technology is a rapidly moving beast. And the pressure to move forward, fast, is right there, always. It’s part of our culture, from the advertisements to the neatest, newest, coolest phones, to the new TV you should have. And then there are those of us in the Nonprofit technology community who are constantly on the bleeding edge of the next thing, whether it be hardware, software, or web services, are constantly talking about it, and how it’s going to make it easier/better/faster to change the world. Although I often get snarky about this, I am aware that I am guilty of this, too.

Most nonprofits are not run by geeks. Most nonprofit leaders think of technology as something in between a useful tool to be leveraged, and a necessary evil. They are resistant to rapid changes in their technology, as well they should be. And, they depend on geeks to help them get things done.

I have a story about nonprofits with a website they can’t leverage for their mission. Although complete fiction, this story will feel quite familiar. And I know I’ve been a guilty party in a real story at some point in my career.

A small nonprofit has a small staff who know a lot about their mission, but nothing about how to create a website. A friend of one of the board members is a web developer. They hire that web developer to put a new site together. The developer waxes poetic about the capabilities of this platform, called AmazingWebCreator. They imagine the developer knows what they are talking about. The developer builds the website, then goes away. The organization is happy for a while, they have a website with pages they can easily edit using a web form, which is more than they had before. Then in months, or years, they want to add some new pages, or a new section to their site, and a widget on the side. But they realize they don’t know how to do that. They call the developer, who is busy now using AmazingWebCreator on some huge project, or has moved on to SuperDuperWebCreator, and doesn’t have time for them. They have to bring in another developer, who knows AmazingWebCreator, which may cost them time and $.

Of course, the critical factor here is what is “AmazingWebCreator”? If it is a relatively new CMS (like WordPress, Drupal, Joomla and others) they may not need to bring in a new developer – they may just be able to get a book, or buy a video to teach them how to use the web interface to create new regions and widgets. If “AmazingWebCreator” is a platform like RubyonRails, Django,  .NET, Java, or ColdFusion, they are most likely going to have to hire someone to do that work for them, and depending on the platform, those developers may be either few and far between (ColdFusion) or in high demand, and therefore relatively expensive (RubyonRails, Java.) Worst, of course, is if AmazingWebCreator is a proprietary, custom CMS that the developer wrote themselves in 2002, and no longer supports.

How is an organization supposed to know how to make an informed choice about a website platform? I have a few suggestions:

1) Assumptions: First, assume the person/people who develop your site might not be around in a year or so. And assume there are things you can’t conceive of now that you’ll want to do in a year. Don’t assume the platform that your buddy chose for their organization’s site is the right one for you. Don’t assume that the most popular platform is necessarily the right one, either.

2) Feature set: Garden variety website, or  very specialized functionality? (By “garden variety” I don’t mean brochureware. I mean average, normal features of most nonprofit organizations. These include such things as donation buttons/pages, membership lists, blogs, etc.)

3) Platform choice: Look at a number of things – if it’s open source – how many developers are there? How many people use it? How easy is it to find developers? Will most new functionality be able to be added via web interface, or will it require back-end coding? Is it a custom CMS, written, maintained and supported by a single shop? (NEVER, EVER, EVER CHOOSE THESE. Here’s why. Luckily, they are an endangered species.) If it is proprietary, or software-as-a-service, are the extra features really worth the cost? Are there many consultants and developers who can assist you with this platform?

4) Lifecycle: Is it early in the life of the platform, at it’s peak, or late (or very, very late)? Bleeding edge might hurt, aged platform might crumble underneath the weight.

There are lots of folks (I do this on occasion on this blog, and Idealware is a great resource) that can provide you with information about specific platforms, and comparisons between them. Read, read, read, and ask many questions before you decide.

{ 2 comments }

WordPress vs. Drupal … fight!

by Pearlbear on February 15, 2011

As a user and developer of WordPress since 1.x something, and a developer and user of Drupal since 4.7, I figured that with the release of Drupal 7, this would be a great time to do a comparison of the two.  If you want a really detailed look, please read the very exhaustive, recently released, updated Idealware report on OpenSource CMS, which includes Drupal, WordPress, Joomla and Plone. I did the research for the original report released a couple of years ago, so it’s been a while since I’ve come back to comparing these two platforms. Also, this is primarily going to be from the developers point of view, although I’ll talk some about user interface and experience.

(A caveat: I have more experience, especially with larger sites, in Drupal than in WordPress, so there are things that I may be missing. Feel free to make comments on what I got wrong.)

WordPress started out with a focus on ease of use for bloggers and content creators, and secondarily providing a platform for developers to build plug-ins and such. WordPress was born as a blogging tool, primarily, and has expanded outside of that realm, to encompass different kinds of content management use cases. Drupal started out primarily as a web content development platform, with a strength in community features. A focus on ease of use didn’t come about until Drupal 7.

At this point, both Drupal 7 and WordPress are pretty easy for end users to add and edit content, and do pretty simple administrative tasks (moderate comments, etc.) They both have a very nice array of canned themes available to use, and they both have some customizable themes (themes that make it easy to customize without needing to know much HTML or PHP – like Thesis) available. Getting a site up and running in both platforms is pretty easy, although neither are really ready for non-techies to take on. That said, most good webhosts have one-click installs of both CMS platforms.

WordPress still has only two content types: Blog Posts and Pages. You can’t have different kinds of pages, or different kinds of blog posts, or some other content type (news, events, etc.) that aren’t one or the other. That is a deal-breaker for many kinds of sites. There are plug-ins that allow you to create custom content types – I haven’t tried these, so I can’t comment, but it seems a big deal that this is core for Drupal, and an add-on for WordPress. And it seems that this, and the absence in WordPress of a way to easily control the way that lists of content are presented and viewed are the major platform differentiators. That said, many, many websites need neither of these features.

And if you want to get more deeply under the hood, both platforms require some understanding of the respective platforms (how plug-ins work in WP, how modules work in Drupal), and probably a bit of PHP, HTML, or AJAX to add bells and whistles to the theme. Given some big changes in the core of Drupal, such as adding fields to nodes, as well as image handling in core, some things are much easier dealt with in Drupal  7 than previous versions, getting close to the ease of use of WordPress in that regard.

Kinds of sites probably best done in WordPress:

  • Blogs
  • Community Blogs
  • Simple brochureware websites

Kinds of sites best done in Drupal:

  • Large community sites where you need different kinds of content generated by users (blogs, wikis, job postings, etc.)
  • Complex, document-heavy library sites, or sites that need document management
  • Sites where you want complex control over multiple content types – how they are created and viewed
  • Magazine/Newspaper like sites where you want to control how lists of content are displayed and ordered
  • eCommerce sites
  • Sites with deep integrations to CRM platforms and web services

Kinds of sites where it’s a tossup:

  • Medium or large websites with lots of content, but relatively simple organization
  • Community blogs with many authors and identified, authenticated users

Bottom line: They are both such amazing, solid platforms, with rich, deep ecosystems of plug-in/module developers, implementors, designers, etc. that it’s hard to go wrong picking either platform, as long as you are clear on the feature set needed.  They have rock-solid core development teams, security updates, and over all good code, which you could hardly say about either platform 4 years ago.

Also, I have to say, as much as I have respect for other Open Source CMS platforms, IMHO, 98% of websites can be served by either of these platforms. That’s what’s true right at this moment. 3 or so years down the pike, I’m going to be looking at platforms based on Ruby on Rails – as Rails gets more mainstream, and solid CMS platforms start to mature, that will be the space to watch for. But that’s another blog entry, isn’t it?

{ 24 comments }