You’re hired to build a website and you decide that the best tool for the job is an open source application. So you install it, configure it, add in plugins, tweak the design, and make it a perfect site for your client. You explain how the CMS works, how they add pages, media, etc, and hand over the keys. Everyone’s happy.
Then a month or so later, the CMS releases an upgrade. Your client clicks the upgrade button (because most CMS tools have made that easy) and it installed, but now the site is broken. They contact you, complaining, and you end up spending hours of your time trying to calm them down, complaining to the CMS folks, and being grumpy.
And for a lot of you, this is your own damn fault.
I know a lot of website-building consultants, and I’m not saying this lightly. As a website builder, it’s incumbent on you, the person who installed the CMS, to make sure your clients understand the implications of that CMS, how upgrades work, and to arrange for support, just like you would for any vended product. Basically, if you don’t communicate and educate, you’ve done this to yourself.
Know This Is Not Different
Installing an Open Source product for a client is absolutely the same as installing a traditional, closed source, vended product. It certainly feels different, since there is a far more casual approach to a lot of things, but at the end of the day, your relationship with your client, and theirs with the software you install, is exactly the same, regardless of where the software came from and who wrote it.
A lot of companies worry about Open Source since it’s complicated and nigh impossible to sort out who you can sue if things go wrong. What happens if they vanish? What happens if it breaks? Really it’s not that different. If Microsoft went bankrupt today and closed all their doors, you’d still have everything you bought, but they’d be gone and you wouldn’t get any more help from them. Ditto Apple, and everyone else. In fact, it’s just as likely that a major Open Source app will vanish as it is a Closed Source, or bought out, or no longer supported. And at least with Open Source (and anything GPL’d), the code is mine to maintain as I see fit.
But really, installing a product is installing a product, and the work you do and the support you provide is the same.
Know Your Product
Never install a product you don’t know how to use. Personally, I never install a product I don’t use regularly (which is why I generally only install WordPress, and turn to Andrea if I need help with domain mapping plugins). My reason is that if you use a product, you know what you’re getting into, how it works, and preferably how to tweak it. Some of what you need to know about the product depends on how you plan to support it, but a good rule of thumb is that if you’re installing it for someone else, you either better be an advanced user of it, or know how to get answers, fast, without restoring to forum posts like “Help me ASAP! My client is down!” You’re a professional, you’re expected to learn to use your tools and act that way.
This doesn’t mean you have to know everything, but remember that your clients can use Google, and if they know your handle is ‘Ipstenu’ and they’re using WordPress, they just might search for “Ipstenu WordPress” to see what kind of person you are. So if they search for you and see you being snotty, or using l33t/IM speak in the forums, they might question your professionalism. But if they see you asking the questions they’ve asked of you, they may doubt you. A good idea is to be honest “I don’t know how to do that off the top of my head, so I’m going to research it and ask around.” Network. Ask your friends (you do have friends in your product’s community, right?) and keep in mind your visibility.
Know the Future
We can’t predict the future with any long-term accuracy, but we can prepare for it. If you choose to use a product, you need to know where it’s going. The day to find out about new features is not the release day, nor is it even the pre-release candidates or the betas! You need to be proactive, and keep in touch with the project, where it’s going, and how that impacts you. Every open source product allows for ‘nightly’ builds. These are the things you generally don’t want to run on production versions of websites, but that doesn’t mean you shouldn’t run them on your site. Install the nightly release on a server, set it up so it auto-upgrades every night (or if you use subversion, set up a pull every day or every x hours). Include some sample data, include all the plugins you use on your client sites, and test it at least every week.
Doing all that is a lot of why, which is why some people don’t offer ongoing support (more about that in a minute). Even so, the only way to know your product is to know it. If a product is important to your bottom line, then it’s imperative you know it well. Pay attention to what will and won’t be changing in the next version, and if possible, know why that’s happening, so if your client asks “But why?” you can answer.
This is where I feel Open Source has a clear advantage to closed source applications. Getting on the Microsoft Beta test list is harder than finding parking at the mall the weekend before Christmas. Getting on an Open Source beta test is about as easy as blinking. You can download and test all you want, every day, without asking special permissions.
Know What They Need
Before you go anywhere with a client, you need to ask them what kind of support they want. Are they going to pay you just to build the site, and then you walk away? Do they want to pay you a smaller fee per annum for support, a set fee for upgrades, or hire you at your normal rates to bail them out? Don’t let them drive your decision, though. You’re the one doing the work, and if you have zero interest in ongoing support, be upfront, tell them you’re just going to install it and they need to find other resources for help.
Don’t be a dick about it either, of course. Give them a list of people you know are good for help, some resources for the product, and maybe you can work out a deal with your friends. You get a small percentage of any client referred, for example, to your friend Bob who loves helping people dig themselves out of a hole.
Know What They Know
Any time you install software for someone else, you need to teach them. At the very basic level, they have to know how to use the product, otherwise you’ll get them emailing you new content to post for them. If you want to support that, great, but most people would rather not, so you explain how it’s used. Write up a very basic document for it, save it as a PDF, and include it in your deliverable. Update it when new versions come out and mail it to any client still on your list (i.e. the people who’re still paying you) or post it on your website for anyone to download.
Once your client knows how to do the basics on the site, go back to what level of support you’ve settled on. If they’re going to maintain the site themselves, you need to make sure they know the basics for that too! How to install a plugin, how to upgrade, and so on and so forth. This will make them appreciate you, and hopefully recommend your services to the next guy. Treat people well, it’ll come back to you.
For a product like Drupal, which doesn’t have a full-version upgrade as a one-click option, I usually tell people “Hire someone. It’s a pain.” Beyond that, however, you need to make sure they understand what new versions entail. A lot of people don’t know that WordPress considers a point release to be a major upgrade (i.e. going from 3.1 to 3.2 is a full new version of WP, but 3.2 to 3.2.1 is not). They need to understand that, so when they do upgrade, they know what they’re getting into and aren’t surprised by, say, a new admin menu.
This goes for plugins and themes as well as the basic product. Teach them how to edit themes the ‘right’ way. Explain that they may want to make a duplicate of their site to test upgrades on because, while most work just fine, you should CYA and so should they.
Know How To Communicate, Damnit!
Everything is built off of good relationships with your clients and the product. As we all know, the key to a good relationship is communication. If it’s not painfully obvious, you need to communicate clearly with both of them. Learn how to help non-techs, and learn how to report possible bugs to techs. Bridge the gap between the two, and learn how to translate, because sometimes that wild bug is from your client doing something no one predicted (it happens). You cannot exist in a vacuum, after all and no one’s a mind reader.
When you finish a project with a client, they should know exactly what to do to use the product, have directions on how to upgrade (or how to contact you), how to get help, and what to expect from you in the future. Clearly communicating these things will result in a happier experience for everyone. Or at least an opportunity to do the “I told you so” dance.
What Don’t You Know?
What are some of your tips and tricks for supporting your clients with open source products?