The Ethics of WordPress Developer Responsibilities

Earlier this week, I shared a post on You Can’t Ask Users To Upgrade WordPress To Fix Their ProblemsIn the post, I shared a few reasons as to why it’s dangerous to expect and/or trust your customers to upgrade WordPress.

You can read the full article for my reasons why, but Mike brought up an interesting statement in the comment feed that got me thinking about the ethics of our responsibilities a developers for building projects for clients.

Though ethics are subjective and that you’ll rarely hear me talk about them on this particular blog, I think that there is room for discussion as to what constitutes the ethics of programmers in the case of building, releasing, and maintaing software for others, and, in this case, within the WordPress space.

1. Building It Is Not Enough

I think that any developer would agree that the most fun part of any project is actually building something.

I mean, seriously: We’re taking an idea – something that’s completely intangible – and bringing it to life in order to solve a problem for someone else. There are very few careers that can breed such a satisfaction, right?

But the thing is, I think too many developers think that building is enough. We hand off the end result and then send our clients on their way and move on to the next project.

The problem is that themes update, plugins update, WordPress updates, and a business is depending on this application to run at least an aspect of their money, and if they are left to manage this themselves, they can do significant damage to their business.

2. An Insurance Policy

When you purchase an expensive product in a store, it’s not at all uncommon for it to ship with a warranty and/or an optional insurance policy and for obvious reasons, right?

Crash

Don’t let your users do this.

The keyword is that it’s optional, but everyone knows that if you’ve opted not to take advantage of the warranty or the insurance policy, then you can be out a significant amount if something breaks.

On the other hand, insurance is all about risk management – you’re paying for something you may never need.

I think the same mentality applies to software. Service agreements aren’t necessarily new to the industry. I could be way off base, but they haven’t seen to reach the WordPress community yet. 

Honestly, I’m still experimenting what this looks like within my own business.

But I know this: we’re building software and software breaks either via new releases, via dependencies, or via user errors. So we’ve got to have some sort of solution in place.

It’s a matter of exploring what that is.

3. An Ethical Stance on Development

Taking a stance on a subjective issue in a public arena – especially on the Internet – can be a dangerous thing because it often invites people to comment more about your personality than the idea at hand.

But I’m willing to take that risk.

Personally, I believe that we – as developers – have an ethical responsibility to treat our customers and our users with respect and with support to make sure that their experience with are products are as positive as possible. This doesn’t only include understanding their needs, providing a solid solution, but not abandoning them after the project is completed.

This isn’t to say that I believe we need to maintain a relationship for months or years after we hand a project over, nor do I believe that we should require our customers to sign up for an agreement.

do believe that we have the responsibility to educate our customers on the risks that happen after a project hand off and what options they have for maintaining the project.

But I’m curious as to what this may look like for others. Sure, I’ve my opinions, but I’m curious as to what you guys think or what you guys have done, as well.

So what are the ethics of a WordPress developer responsibilities?

9 Comments

Honestly, I don’t see us as any different than contractors or plumbers, to a certain extent. I’m starting to experiment with support contracts as well. I find that with larger organizations, they’re not a crazy thought. I’ve tried two different methods so far: 3 months of support included in the original estimate, and then a 6 month service contract. It hasn’t been long enough yet to see how either works, but so far I’m leaning towards the 6 month contract.

I love your point that we don’t leave the client after everything has been built. It’s a hard pill for me to swallow though because I, as you said, LOVE the actual building of the product. I dislike it when it breaks. But just like we bring a child into the world, we have to take care of the mess our kids make. We can at least get paid for cleaning up our code mess =p

    I’ll expound on my contractor/plumber comment too. I see us as a hybrid service provier/product maker. An architect and contractor builds a house, providing a service to create an end product. We build digital houses. I think we should offer the same level of service and guarantees as well. But that doesn’t mean we don’t just give it out: if the client didn’t pay for it, then it’s a shame. That’s where I think I’ll offer a period where I’ll guarantee the product, then after that they’re on their own.

      What I’ve generally found works well for support relationships is some type of retainer agreement.

      I usually bring it up as food for thought during the initial estimate and/or consulting and let the customer think about it over the course of the project.

      I also give them estimates of what the support retainer may look like based on a variety of conditions so there are options to consider.

I’ll agree that we have responsibilities, whether it’s to clients we built a project for, or maintaining a plugin over time for the benefit of the WordPress community. On the other side of the coin, users and clients have responsibilities as well. In the WordPress ecosystem, the understanding of these responsibilities tends to be non-existant for many.

When buying a car, we don’t expect the owner to know how to build an engine, but we do expect them to know to change the brakes every x miles, change the oil every x miles and refill the gas when the tank is low. At least in WordPress, many don’t know these basics. Maybe they’ll update WordPress because a giant banner tells them to, then their theme breaks and they wonder why, but they haven’t updated the theme since it was initially installed.

I’m not saying it’s necessarily our responsibility, though maybe it is, to teach others how to drive the car they bought before handing them the keys (other than the things specific to this car/project), but it does seem to me that these drivers need to learn this information before putting rubber to the road.

    On the other side of the coin, users and clients have responsibilities as well. In the WordPress ecosystem, the understanding of these responsibilities tends to be non-existant for many.

    This is true, but I think this has to do with a gap in education being created somewhere a long the way. I don’t know where or why, nor do I know why it’s more acceptable in some industries and not others, but I feel a burden of responsibility to do what I can to help those who I do work with to understand a little bit more with what it all entails.

    And you’re right – we expect the owner of a site to perform certain maintenance on their car, but maybe we – as developers – don’t do such a hot job of letting them know what they should do with their site. Maybe we should be responsible for monitoring their site’s version, etc. and writing code to prevent them from ever seeing that updates are available.

    Grey areas, to be sure, but ultimately I think we have more of a responsibility than we want to take on.

At one point, I did have some clients on a small retainer fee for upgrades and maintenance, but the difficulty was in having clear boundaries between what was included and what wasn’t.

I see myself more as the architect/builder. Once the construction is done and you move in, there’s a period of warranty on any defects that you might find, but then if you get a blocked toilet because you flushed too much paper, call a plumber :D

    You’re right – the terms have to be solid and clients receive said terms differently, so it’s not always an easy thing to manage.

    I usually try to gauge feasibility and interest based on my experience while working with them through development. For the most part, it’s really been 50/50 in terms of it working out.

Based on my experience with this, I have yet to see a client update their site on their own. I may return to the WordPress dashboard of their site months or years later and see update notifications all over the place. It’s amazing how they can continue to use the site and not flinch at these messages. I personally can’t stand them there. Whenever I need to go into the backend or work on a few minor updates for a client I will let them know that I will be updating the system and I’ll usually add between 1/4 – 1/2 hour depending on the amount of updates and testing that need to be done. At this point, if it’s only a couple things I may not charge at all and simply click and go and never even tell the client I updated things. I need to make sure the site runs well as long as I am in the picture so I have happy customers. It could be a good idea to write something in the proposal of any WordPress project that the site will require updates and maintenance after the project from time to time and if there is no maintenance contract in place then they will be liable for whatever happens. As far as a retainer goes, I have some ideas for folks out there…if there is one in place make the hours that were pre-paid available for anything that is billable. When that amount is depleted have them re-charge it.

    It’s amazing how they can continue to use the site and not flinch at these messages. I personally can’t stand them there.

    I agree with you. They’re nag screens and they do their job.

    The thing is that I think that most people aren’t particularly worried about upgrading because they aren’t sure of what will happen. The consequences of not upgrading outweigh the consequences of the uncertainly of upgrading, so it’s easier to leave it alone.

    At this point, if it’s only a couple things I may not charge at all and simply click and go and never even tell the client I updated things. I need to make sure the site runs well as long as I am in the picture so I have happy customers

    I’m still hit or miss with this, though the longer I work in this particular area, the more I lean in the direction of charging simply because it’s time and it’s a commodity that I could be using to work on something else.

    This isn’t meant to, y’know, gouge anyone, but it’s meant to simply provide a service.

    At any rate, thanks for the comment – definitely provide some good thoughts here.

Leave a Reply

Name and email address are required. Your email address will not be published.

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>