Over the past few years I’ve developed my fair share of WordPress plugins. Not just as projects for myself but also for bigger firms. And especially for those bigger firms I’d like to have some sort of continuation plan. Not so much for myself but more for them, just in case the plugin could use some improvements due to advancements in WordPress itself or if there’s better ways of achieving the same outcome. And to me personally there is no better way to do this then to make the plugin publicly available so others can use it, fork it and what not. I like to educate my clients, teach them that they reap what they sow and that giving back to the community will ultimately be beneficial to themselves as well.
I’ve heard many reasons why clients didn’t want to go forward with this. Ranging from a simple “No!” to a “We’ll sue you if you publish anything regarding this project”. Luckily I’ve mostly been blessed with clients that were more than eager to do this. Some of them published the plugins in the WordPress plugin repository, others on Github. Basically I shifted from selling a product to selling a service and it helped me to establish a, hopefully, long and healthy relationship with my clients.
When should you convince a client to contribute to the community?
In my humble opinion, always! But simply put, if you feel like there’s more people out there that would benefit from a similar solution just tell your client to go for it. Help them set everything up, get them involved. WordPress is not just “free” software, it has an amazing community. You and I know this, it’s time to let our clients know this as well. Even if you and your client don’t feel like there’s a real audience for the plugin it might still be wise to at least have a few peers review it. Just have a fellow programmer check your code, glance over it and take his or her advice to heart.
When should you not do this?
If the plugin relies on any private APIs sharing your hard work is probably not the right way to go. This might speak for itself but what about dependencies on 3rd party plugins? Just like with any other plugin you’ve created you have to be sure to keep everything up-to-date and secure. I recently came across a plugin that still included a vulnerable version of TimThumb and although the plugin itself was “safe”, its dependencies weren’t. This could been a world of hurt for the client if anybody with bad intentions had noticed. If you choose to include other libraries in your plugin you’re also responsible for any security issues those might bring along.
So what are the cons for your client?
The only real disadvantage for your client might be that the plugin might have to be generalized a little, made for a broader audience to get more, and better, community feedback. Then again, it might also save you from “options hell“.
But more importantly, how do you convince your client?
Every project has their own benefits when sharing with the community but in general it all boils down to the ones below.
- Your feelings might, and probably will, get hurt. It’s not uncommon for developers to check eachother’s work. But it will make you a better developer and your client will have a better product for which they already payed.
- “Free” updates for your client. When people contribute, or file bug reports they’re helping you to improve the plugin at less effort then it would have cost you by yourself. Think of it as a helping hand for you and a ‘discount’ for your client. Clients love discounts.
- Giving back to the community increases your and your client’s standing in the community. And I mean the open source community in general, this is not limited to WordPress per se – the US Government has made some great contributions to Drupal in the form of plugins.
- It has all the potential in the world to increase the trust your client’s customers or visitors invest in them. Your client’s new found transparency is in no way a reflection of the confidentiality of the material the plugin deals could deal with. If the plugin shows use of best practices and a high grade of security then this can only make the end-user feel like they made a good choice trusting your client. Everybody’s happy.
Wrapping up
I’d like to leave you with some suggested reading. Boone Gorge’s excellent patronage model is a handy little guide for free software freelancers and it deals with some other aspects you might run into like licensing choosing whether or not to work for a certain client.
So, how do you feel about the above? Have you ever had a similar situation or choice to make? Leave your feedback in the comment section below!
Image copyright: shho / sxc.hu