From the category archives:

CMS

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.

Tagged as: , , , , , ,

{ 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):

Tagged as: ,

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.

 

 

Tagged as: , , , ,

{ 2 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!!

Tagged as: , , , ,

{ 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.

Tagged as: , ,

{ 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?

Tagged as: , , ,

{ 24 comments }

Drupal 7

by Pearlbear on January 24, 2011

I’ve had a bit of time now to work with Drupal 7. I’ve been playing with it since it was still pretty experimental, but I finally put together a whole site with it recently, and am pretty happy with it. It’s gotten a big leg up in terms of usability – this was a major focus for this release. The basic user interface is much improved over Drupal 6, and unrecognizable if you’ve only been using Drupal 5 or earlier. In my opinion, the advantages some CMS had over Drupal (I’m thinking specifically of Joomla and WordPress) in the realm of usability have been diminished or even eliminated – especially in the case of Joomla. WordPress still has a usability advantage if you are creating a simple blog site. But if you’re using WordPress to make a more generic website – I’d look twice or three times at Drupal 7.

There are also some pretty serious under the hood improvements as well. I’m looking forward to when all of the modules that I depend on are up to speed. Some of the most important ones made it into core, and many others were released with Drupal 7. Some others are close, like Ubercart, which has a version in Beta, and Views, which surprisingly is still in Alpha.

If you are running a site in Drupal 5, you need to migrate your site at least to 6, but possibly to 7, if you can. Drupal 5 is no longer supported – which means that if there are security issues, they won’t be addressed. There will be no more updates to contrib modules in Drupal 5 (in fact, many modules for Drupal 5 were abandoned a while ago.)

Lullabot has a nice article on upgrading your site from Drupal 5 to Drupal 6, in case your site isn’t ready for Drupal 7.

{ 3 comments }

Salesforce as a CMS?

by Pearlbear on September 22, 2010

Salesforce is a very powerful platform onto which one can build a large variety of interesting kinds of custom applications. I’ve already talked on this blog about Salesforce integration with Drupal, Plone, and others. Today I’m going to delve into Salesforce-based CMS systems – systems built as applications on top of the Force.com platform.

First, what are the advantages and disadvantages of this approach? The disadvantage is that primarily, Salesforce was not designed as a CMS – it was designed as a Salesforce automation and customer service tool. It has become a powerful platform, and there is a lot you can do with it – but it was never designed with content or visual design in mind.

What are the advantages? If you’re running database applications (tracking donations, events, programs, clients) and want deep integration between your web content and your data, it is an approach that is hard to beat. Certainly CMS/CRM integrations can go a long way – but ultimately, using Salesforce as your CMS platform will provide a kind of power that is not easily replicable using an integration. But with that power, may come some sacrifices.

What are the options for doing CMS-like things on the Force.com platform?

  • The native capability of something called “Sites” – which is a publicly facing version of what’s called “VisualForce” – a markup language that includes HTML as well as APEX code (Force.com coding language). This requires a lot of custom code, and becomes unwieldy when you get to more than a few pages unless you write a mini-CMS yourself to handle things as a site gets more complex. But there is a lot there.
  • CMSForce – This is an “open source” (in quotes because although you can get the source code, do what you’d like with it, and contribute to the project, because it’s written on a proprietary platform, it’s not really open source.) I’ve spent quite a bit of time with this one, and more to come, I’m sure – like any open source project, there is a lot that could be done to make it more usable. But it certainly is something to evaluate, and contribute to, if you find it useful. It is written by Force.com Labs, so it’s got serious Force.com developers behind it.
  • OrchestraCMS – This is a paid app – with discounts for nonprofit organizations. I’ve taken just a test drive, but it’s pretty impressive – it has it’s own UI, and is well developed. There were a few hiccups in getting going, but I suspect it was because I only spent a little time with it. A partner we work with has done a lot of work with this application, and we’re pretty interested in it.

There are a couple of others, and I’m sure more in development. Salesforce has a rich enough data model and development platform to sustain a solid CMS – the big question is – is this the right fit in terms of integration? Salesforce-based content management is embryonic in comparison to CMS systems such as Drupal or Plone (or even WordPress for that matter) but being able to draw data directly in and out of salesforce very easily, for some organizations running Salesforce, might well be worth it.

And, it’s also possible to have one’s main site in a solid CMS, and instead of using complex integrations, have a mini-site with the same look and feel based in Salesforce, for the data needs you have. Again, it depends on what your use cases are, but that’s another way to go.

Tagged as: , ,

{ 6 comments }

Amazon S3 for web server backup

by Pearlbear on June 30, 2010

I’ve been getting to know Amazon S3 lately, and there are some great things about it. I think it is one of the long list of unpredicted successes that resulted from the near-ubiquitousness of open source software on the server side. We’ve been using it for “offsite” backup for drupal sites for a while now. We have a script going which runs by cron daily to do the backups.

There are a number of ways to do this. We started using S3fs as a way to mount an S3 bucket in the filesystem, then just copy the files to S3. One of the scripts we’ve use is here. (We also use rsync.) However, S3fs isn’t very actively supported or in development. So we’re thinking of moving to use S3cmd, which works really well, and is still under active development.

Tagged as: , , , ,

{ 4 comments }

Drupal 7

by Pearlbear on March 16, 2010

I’ve been doing a bit of playing around with Drupal 7 in my copious spare time (not a whole lot of that!) I’ve also been keeping track, a bit of how the development process is going, and what things will look like. One thing to say – it feels like as big an improvement as Drupal 6 was to Drupal 5.

Of course, mostly, Drupal is only as good as it’s contributed modules (that’s a bit more of a stretch, now, because many of the key contributed modules, like CCK, are now in core Drupal.) So when folks like us, who build sites that depend on Drupal 7 can start using it is a bit up in the air, although there is a movement to get many modules ready for Drupal 7 at it’s release. But some may well not make it. We’re guessing that we’ll start building production sites in Drupal 7 starting in late summer, early fall, depending on requirements.

A note: the standard process for deprecation of old Drupal versions is that when a new version of core comes out, the one two versions back stops being officially supported. So Drupal 5 will no longer get security updates and the like. Already, many module developers have stopped supporting versions of their modules that work on Drupal 5. (The salesforce module maintainers recently made that decision, as have others.) So certainly a site running Drupal 5 won’t stop working, but it will become vulnerable without security updates to core or modules, and it will get increasingly difficult to maintain and add features to. So it might be a good idea to budget the time and money to upgrade as soon as possible if you are on Drupal 5. If you are on Drupal 6, you’ve got a while yet, but Drupal 7 certainly has some great advantages, particularly in user experience, to look at.

Tagged as: , ,

← Previous Entries