Tag: support

Supporting Open Sourced Clients

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?

2 November, 2011
Community Driven Design

WordPress 3.3 is on the horizon, and already there’s a minor kerfluffle over the flyout menus. Regardless of if you agree with the change or not (I do, Otto does not, for example), it brings to mind the reality that every time there’s a new change to the Admin UI, someone demands to know ‘Who’ requested the change. One time, the answer was ‘Matt.’

While WP is open source, and that means it’s community driven, that’s only to a degree. Remember, at the end of the day the folks with commit access are the ones who decide what they want to support and have in their app. Theirs. WordPress isn’t a Democracy, it’s at best a parlimented monarchy, but really more of a benevolent dictatorship. This is neither good nor bad, when you put it in perspective, and I’m afraid that with products, especially free and/or open-source products, we as a user base consistently lack that perspective.

The company I work for recently switched to Office 2007. Yes, I want you all to take a moment to reflect on the fact that we didn’t move to Office 2007 until it was 2010 (and didn’t finish until summer 2011), it’s important. The reason we didn’t switch sooner wasn’t for anything technical. In fact, we really wanted to switch so we could upgrade SharePoint and have functional integration. No, there were no app conflicts or weird database issues preventing the upgrade. It ran on our operating systems without issues. But why didn’t we upgrade? Because some of the people in “very important positions” had trouble with it, and we were concerned that the UI change, which was rather dramatic, would overwhelm our help desk.

To put this in perspective even more, there are about 20k employees at my company (give or take, I’m not counting consultants here, or non-computer-using people). Of those, about an eighth are what I’d call techies. That is, maybe 2500 of us are really nerdy people who use foam swords or even know who Stallman is. Another 2500 of us are technically inclined, and capable of trouble shooting the basics. Another 2500 are smart enough to know how to explain their problem to the techs. That means over half the company are ‘real users,’ you know, the ones we make fun of for deleting DLLs that are taking up space, or who reboot their monitor. Every time we make a change to software used across the entire company, we have to put that 50% clear in our minds. How will this affect them? What training to we need to provide? We’ve pretty much accepted that no change will be universally accepted, and at a certain point we have to agree that this is ‘good enough’ for people, and deal with the fall out.

Coming back to Open Source, when a project like WordPress or Drupal makes a major change someone’s going to hate it. This is just the way of the world, and even if you love the change, you need to work to make sure your replies to these people aren’t ‘haters gonna hate!’ or ‘you suck!’ Neither of these are productive. Part of the problem here is that people get passionate and sulky, like a nine year old who viscerally dislikes something, but lacks the language to fully explain it. This is not to say people are incapable of explaining themselves, but that part of their problem is the ephemeral ‘feeling.’ The other major part of the problem is that no two people hold a hammer the exact same way. And of course that people who are complaining at the ‘beta’ stage of the product are in too late.

Understanding how these designs get made goes a long way into making people accept changes they don’t agree with. It doesn’t make them like the changes, but understanding how and why they happened can get you to the ‘agree to disagree’ point. John O’Nolan (who currently is living on the road by choice) wrote an amazingly informative post about how he got involved in WordPress UI back in the 3.0 days. He lays out how you can get involved more, if you’re inclined. There’s a great Make WordPress UI P2 blog, and of course WordPress Development blog that you can follow along to see what’s going on and there’s always looking at the tickets in Trac flagged for Needs User Experience/UI Feedback, but I’ve found the first way you should get involved is to start using WordPress trunk: the live latest and greatest, but not ready for prime time players, version.

That seems like a departure from theme, but it’s not. We all start out as basic WordPress users. We use the product, we know how to add/edit/remove posts, we move on to using plugins, and eventually we hit a wall. Either we start to adapt and become power users, who understand how to tweak things in wp-config.php, play with SSH/FTP, and make a quick child theme, or we resign ourselves to using WordPress as it is presented. Neither use-case is better or worse than the other. If you’re a ‘hard core’ WordPress user, though, you will find yourself wishing for small fixes, and you’ll make a plugin for yourself. Then you share it, and then you start to suggest things in the forums, or report bugs in trac. Now we’re cooking with fire, and it’s not long before you start tossing out code or css ideas for trac.

The point of this is that if you start ‘testing’ the new versions of WordPress at the beta or release candidate iteration, you are too late in the game to make a UI comment. The Beta and RC releases aren’t for making drastic changes, but for making the changes that are in there work correctly. Like how the ‘close’ button on the admin bar pointed isn’t working on IE 7 or 8. That’s a bug. But not liking the admin sidebar menu flyout and disagreeing with it entirely isn’t a bug. Did you know the head of the UI team didn’t like the Admin Bar back when it came about?

You don’t have to like everything about a product to use it, and sometimes changes mean you need to rethink how you use it. Also, WordPress has a policy similar to Apple and Amazon: Release, then iterate. That’s why in the last three releases of WordPress, we’ve had one major change and two noticeable tweaks to the whole admin UI. The 3.0 release was a huge overhaul, and in both 3.1 and 3.2 (and now 3.3) we’ve had significant variations on a theme. They feel big, but compare it to the 2.9 to 3.0 jump and it’s really pretty small.

If you want to guide WordPress’s UI, get in on it earlier than beta. If you want to iron out bugs, join at Beta, but take the time to learn the difference between ‘I don’t like…’ and ‘this is broken….’ If you want to get new features early, join at RC. If you want to wait till we’re ready to go, wait for the final release. If you just use WordPress and trust that most everything will work, use the final releases. If you’re annoyed that little bugs get missed, use RC. If you know you’re using a fringe case, or setup that uses normal WordPress but on an obscure server or configuration, RC or Beta is where we need you. Remember, not everything can be tested, but you can help test more. However. If WordPress is your life, if you live and die by WordPress and support people who use it or need to be testing it in your corporate environment, then you need to step up and start using SVN. Make a second install and set up a job to update every few hours, pay attention to release dates, and don’t treat this like ‘traditional’ software and wait for a release to be notified as to what’s going on.

But that is another post all together.

Perhaps the best thing about a cooperative design, like in an open source app, is that if you don’t like the changes, most of the time you can find someone else who doesn’t, and who wrote a plugin/extension to change it. When you compare that to, say, Microsoft Word, and remember that you, as a user, have very little say in things unless you luck into their market studies or beta tests, and even then, the locked down systems don’t always permit changes, well, you’ve actually got a lot of freedom. And if you’re not a techie, well, make friends with one or hire one. I hear a lot of them like beer.

26 October, 2011
Backup Where You Belong

I’ll make it quick: At the end of the day, there’s only one person who’s responsible for your backups, and that’s you.

Here’s the deal. WordPress does not have a 100% backup everything tool. Neither does Drupal nor Joomla.(All three of the big guys have plugins that can do this, don’t worry, I’ll get to that in a minute.) In fact, I don’t know of any app on the web that does. Even though Google says “You own your data!”, if you use their tool to download everything, it’s not in a form you can just slap back on the web. Their backups remain tied to themselves. You get the data, but then you have to parse it.

This brings up a bigger question, though. What is the point of a backup? In a worst-case world, your backup is to save your bacon for when you screw something up. It’s to restore from a crisis or to roll back a bad change. So why aren’t these sorts of things built into applications?

When you think about it, they’re not built into any application. From Microsoft Word to your favorite Twitter app, if an upgrade breaks something, there’s no ‘roll back’ option. You can uninstall and reinstall, but most of the time that means you have to reconfigure all your favorite settings.(This is actually why I try to make as few special config changes as possible.) Yes, in Microsoft Office, you can save your ‘document’ in total, but that isn’t a direct analog to Web Publishing, because there’s far more than ‘just’ your book, there’s all those settings and preferences. If you’ve ever tried to copy someone’s preferences and settings from one computer to another (and you’re not on a Mac, who makes that shockingly easy) you know what I mean.

The best backup tools are things like Microsoft’s cloud backup, or Apple’s Time Machine. Both make a massive copy and then incremental updates to your entire computer. They are, as we say, OS (Operating System) backups. All your documents, all your applications, all your settings, are backed up. No individual application has ever bothered with this so why should a web app?

The argument goes that you should be able to pick up your web app and put it down on another server via exporting. I can think of one app off the top of my head that can do that: Cpanel. I’ve never tried it myself, but I’ve been told it works pretty well. Still, Cpanel actually falls under the weird realm of operating systems, as it’s really a server management tool. It’s where you logically expect to see things like your backup tools, db access, etc etc and so on and so forth.

In short, it’s the right place to see your backups made.

How do you backup a webapp?

Step 1) Backup ALL the files on your server.
Step 2) Backup all your databases.

That’s kind of it. For most well written apps (WordPress, Drupal, etc) to ‘restore’ these backups, you just copy them back up. For the database stuff, you may need to make a second database and edit your files to point to that DB instead of the original, but it’s pretty fast. Professionally, we have one-click rollbacks installed on databases, but even then, we tend to go ‘Oh, that didn’t work.’ and rename the NEW DB (databasename_date_BAD) and re-upload the old one. Why? Because it works. When the DBs are too big, we have incremental backups and rollbacks set up. Files ditto (actually for files, we ALWAYS have step one ‘make a copy of the old folder structure…’ and the rollback is just renaming things).

We rarely rely on the applications themselves to perform these tasks for one simple reason: They’re BAD at it.

I’ve always been an advocate of the right tool for the right job. A web app is good at its job. A backup tool is good at its job. The two may cross, but there’s nothing wrong with using a backup tool to make backups and a writing tool to write. I don’t use any plugins on my apps to make backups, I do it via the tools built into my server that are, expressly, for making backups. Ditto my computers at home. I know what the right tool is, and I use it.

11 August, 2011
How to Ask for Help

Imagine you’re at the coffee shop and you make your order. Plain coffee. The guy behind you jumps up, RIGHT as they’re making your order and shouts “I want the exact same thing, but a latte with no foam!” Then the guy behind him chimes in “I want an espresso!” and “I want a hot cocoa!”

What happens to the people behind the counter who have just gotten a dozen different orders all at once?

You end up with a bad coffee, that’s what.

That’s why I tell people to make their own topics.

7 July, 2011
How (Not) To Ask For Help

I wrote about this once in I’m not a coder and I need help! It’s come up again.

I was a bit torn about posting this, given that it’s a guy acting like a real jerk in public, and I’m still pretty sure his problem is that he doesn’t understand what we’re saying. But. I think it’s good to have a concrete example of how you don’t ask for help on a forum.

The story so far: WordPress 3.2 was released on July 4th, and we knew there would be some minor issues. Most of them are related to the fact that WordPress no longer supports IE 6, PHP4 and MySQL 4. Before it was released, I decided to be proactive and take the lessons learned from 3.1 and make a Troubleshooting Master List. I posted to the forum mailing list and got advice from everyone there. As soon as 3.2 was let loose, I posted and started checking the forums.

Then I found this guy.

Yes, I did get really annoyed/upset with this guy. Full on anger. My face went hot and I felt myself typing furiously. And I deleted what I’d written at least a dozen times in order to keep as cool as I could. I knew I was mad, I knew I was writing in anger, and I backed away. That’s why my replies got shorter and shorter until, finally, I walked away and let the rest of the community hit him with a brick. I did come back the next morning and close the post, but only because it had become impossible to help the guy. And yes, I would have left it open to help him. It’s what I do.

So taking the cue from his post, let’s run down the ‘what NOT to dos.’

Cursing

The actual title of his post is Upgrade to V3.2 and my site is f**ked. Except he said ‘fucked’ but we modified that. The URL still says it. Just don’t do that. It’s rude. If I have to explain why it’s rude, you need more help than I can give. And I say this from the point of view of a foul mouthed tart. There is a time and place to swear, and the free support forums ain’t them.

Mouthing off

Even if you’re not swearing, there’s a huge difference between being polite and being a cretin. People are taking time out of their day to help you. Treating them like they’re worthless and insulting them is not a good thing to do. Being polite, even when you’re very angry and upset, is hard. I’m aware of this. But that doesn’t excuse your behavior. You’re the one who decided to show your fanny. It’s like what they say on Reality TV. The people being filmed will blame the editing, and the editors will point out ‘We didn’t MAKE you pee on Joe Bob there, you did that on your own.’ Yes, selective quoting and editing can make you look worse, but frankly, you’re the one who put it out there.

Not taking the time to read

I think this falls under ‘Not taking the time to think.’ We told the guy multiple times ‘You need to reset your plugins.’ We linked him, multiple times, to directions on how to do that when you can’t log into your back end. Three times he complained that he couldn’t get to the back end of his site before he finally up and said he wasn’t going to.

Most of the issue was that while we told him what to do, he was blinded by his own interpretation of what we meant. He would have been better served by simply saying ‘I don’t understand what you mean by FTP’ … except he did.

Not following directions

This is really simple. If you’re asking for help, you’re assuming the people who answer know more than you. If you refuse to follow their advice, you’re done. Seriously.

Getting derailed

You may have noticed how he started picking on my language (I used ‘seriously’ twice, and apparently that was too many times), my nationalism (I’m a dual-citizen as it happens), politics (Afghanistan), and so on and so forth. A lot of energy was wasted by his anger and the resulting attitude from it.

The entire reason I did not snap back and point out where his gross assumptions were wrong is because it was not productive. It would just make him madder (yeah, think about that for a second) and make the situation more volatile. Don’t feed the fire.

It’s NOT all about you

I cannot stress this enough, every single volunteer on the WP forums knows and understands exactly how important your site is to you. I have this problem in my day job too. I work with hundreds of very important people (they actually are – the office would come to a standstill if any one of them broke). They are all incapable of understanding that everyone is just as important as they are. I have been known to snap at people and point out that more than one VIP is having a problem, and I am working on the issue, but if you’d like to tell them that YOU are more important, go for it.

No one ever does. They usually shut up, which tells me that really they’re like a kid who fell down on his tush. He’s fine, just crying for effect. You may think that the squeaky wheel gets the oil, but you forget about the boy who cried wolf. At a certain point, we stop listening to you until you come in with a broken wheel.

What else?

Obviously this list can’t be exhaustive (I’d run out of internet before I ran out of examples). The real basic rule is ‘Don’t be a dick.’ Everything else is an extension of that.

If you’re helping someone who treats you like crap, you’re allowed to walk away. At work or at play, you don’t have to deal with it. Just walk away. Of course, at work, you need to tell your boss, and on the WP forums, I tend to email or ask people directly to step up for me please and thank you. In fact, watching the community get my back in that post was both pleasing and very sad. I was sad it had to happen, and I remain sad that he couldn’t be helped.

5 July, 2011
Responsibility, Responsibility, Responsibility!

So you’ve put your blood, sweat and tears into a site. You finally made it popular. You have regular visitors who comment, retweet, like and share your stuff. You’re getting traffic and the ads are actually paying for things! Everything should be smooth sailing, right? Wrong.

Last year, I touched on the Dangers of an Unchecked MultiSite. While that was specific to the trials and tribulations of WordPress’s (then new) feature of MultiSite, it hammered home the lesson that you, who runs the site, are responsible for what goes on there. There’s a reason I have a comment policy on this site and a terms of use. I am aware of my responsibilities, but I don’t take responsibility for everything.

You have to look at your website like a business. If you ran a business, you would be responsible for whatever crap your employees looked at on-line, how they used their phones, etc etc. If someone uses your services to do something illegal, you’re responsible. That’s why you have to sign your life away in blood. Not that anyone reads that stuff for most things, but you do agree to not break the law when you install your operating system, for example.

At the end of the day, when you’ve made a site, you become responsible for the content (with some exceptions). You’ll note that the Terms of Use for this site have a pretty hefty bit of disclaiming going on, and outright says I’m not responsible for the contents of any message (i.e. comment). That’s a mostly legally safe claim to make, and I’m being up front saying ‘Hey, if someone’s a dick in the comments, that’s on them.’ Later on I say I reserve the right to delete anything I damn well feel like, and I do, but the point is I’m still responsible for your antics! That’s why a big part of running a site is moderating the community.

If someone makes a comment you (or your visitors) deem to be offensive, it’s in your best interest to quickly take decisive action. Make a choice, pick your stance, and stick by it. Don’t waver or feel guilt. This is your site, your responsibility (there’s that word again). If it makes you understand it better, this is your job. The easy part of the site is building it, the hard part is maintaining it. For those of you who just spent months getting your site to look just right, the idea that something is harder than that may be daunting.

First you put in the sweat equity to make the site. Then you spend hours researching and writing posts. You’ve already found out about how much time you have to put in fighting spammers. Now here I am telling you that you get to spend even more time and energy keeping the community of your site going. It’s okay to hate me. I actually spent more time these days keeping people in line and tending to them than I did anything else a couple years ago. That’s the real reason a lot of sites go in for moderating teams. It’s a lot of work to keep track of everything. Since then I’ve turned to what I call ‘community moderation.’ Plugins like BP Moderation (for BuddyPress users) and Safe Report Comments let your visitors flag posts for you to come back and review.

Regardless of this, there remains one person responsible for this site: Me. I’m responsible for what people who have accounts do here. I’m responsible for what I say and what they say. I’m responsible for your comments and the ads on this site. Everything here is my responsibility and I take it seriously. To carry it up a level, if your site sells a product, you are responsible for all of that product.

Recently there was a kerfluffle when Joost de Valk announced that his SEO plugin was being infringed on by WPMU Dev. Of course there was a public rebuttal by WPMUDev and a response to the rebuttal. Even WPCandy stepped in.

Before everyone gets het up about this one, I honestly don’t care who’s right or wrong for the purpose of this post. My opinion, and yes, I have one, doesn’t matter.

See, no matter what else, at the end of the day, a company is 100%, totally, unequivocally, responsible for their own products. Full stop. Everyone can agree to this (and as far as I can tell, everyone does agree on this point). No matter what, WPMU Dev is responsible for their products. No one is arguing this. The fact that they pushed a flawed product that slipped through their checks and balances is the point. They can’t blame the developer without blaming themselves for not checking his work. Regardless of if they failed to check the plugin, or forgot to tell the developer to always attribute his work, or whatever it may be, the company who hired the developer assumed all responsibility for the work which was then pushed forth in their name.

They weren’t the first people to make this sort of error, and they won’t be the last. Making the error, in and of itself, is monumentally stupid, but you know what? We’ve all been there. We all take responsibility for these screw ups. It’s horrifying, the first time you realize you’re responsible for something that you’re not in control of, but there you are. You run a company. Sometimes things go wrong in ways you never predicted and should have, but didn’t. In 2009 Microsoft yanked code they’d stolen. I know, stealing is a dirty, hot-button word, but that’s what it is. PC World says it right:

Third parties or not, though, Microsoft is responsible for making sure its software isn’t stolen, and it’s simply not doing the job. (Microsoft yanked code they’d stolen – PC World)

Think it’s just software? Think again. Last winter, a small magazine called Cooks Source lifted someone else’s work, wholesale, and put it in their magazine. The author was attributed, certainly, but not compensated. When the author found out, she contacted them and asked for a $130 donation to the Columbia School of Journalism. She got a pretty awesomely horrible reply, and posted it on her livejournal. From there, the Internet exploded. (If you go to http://illadore.livejournal.com/ you can see the crazy first hand.) How far did it all go? Well the magazine is no more, after the Internet got their hooks in it. People called up the advertisers to tell them that Cooks Source was a plagiarist, and more than one advertiser bailed. Then it turned out they’d stolen multiple articles from multiple sources, non paid, and photographs as well. Let’s not get into the website, which had stolen content all over the place.

It’s your site. It’s your name. You are responsible. Make all the excuses you want, but it doesn’t exculpate you from that role.

13 June, 2011