One of the most challenging components to making decisions in web development is determining when and how strongly to rely on code written by other people.
Most of the code we rely on for a website was written by someone else. WordPress itself, large scale plugins, small plugins, extensions to large plugins — the average website is full of code from dozens of entities.
Deciding on which tools to use, based on who built and maintains them, is pretty important.
Of course, there is no guarantee that the code we write for ourselves will be lasting, but there are considerations to make, when choosing to use code from a third party. Here is an order of operations of sorts that I would use.
- Is the functionality a core component of the website, or if it went away, would it be easy to move forward?
- If it’s a core component, who is the author?
- If it is a company, how core is this plugin to their primary focus as a company?
- If it is an individual, what is the likelihood the individual can spend significant time maintaining the plugin? Is it their livelihood (they have a commercial version)?
- If it’s not their core focus, how is it overall supportive of their business?
- If it’s not overall supportive of their business, how much of a common good is it that the plugin is maintained?
The farther the code gets away from its maintainers core focus — as in, what is paying the bills, and adding value to the entity — the less likely it is to be maintained and cared for over the long term.
And that’s when you should raise a red flag, and consider whether the plugin is the right choice.
I have, multiple times, made the mistake of thinking that a company releasing an official extension for WordPress to integrate with their service was the right move. Over and over again, I am proved wrong.
The official Facebook plugin, MailChimp plugin, now the Shopify plugin, and more — have received essentially the same treatment. They either built them internally or hired someone to build it, and promised that it will be supported over the long haul. Since they are the primary company, it seems like they would be a better option than some third party. But it’s just not true.
Because WordPress is not the businesses primary concern, their own SaaS or service is. An integration with WordPress, unless it is a significant driver of users and value back to their platform, will not win internal battles for attention, care, and maintenance.
Today, I’m much more likely to support an independent developer who is committed to earning a living creating the connection between a service and WordPress.
The same applies to WordPress-centric companies. If a large company like Automattic, or a medium sized company like Yoast, or whoever, has half a dozen, or even dozens of plugins — it’s important to consider how important the plugin is to them before you decide to put your eggs in that basket. Often times interests align, but plenty of times they don’t.\
I mention those companies because they both have good examples. Automattic has several plugins that have gone by the wayside over the years; Edit Flow is an easy example. And for Yoast, they ended up selling their Google Analytics plugin despite a lot of users. In both cases, the plugins were valuable, and popular, but were not primary focus points for the organizations.
Of course, there’s no guarantee code we write ourselves will stand the test of time any better. But you at least have control.
Some readers may wonder if I’m putting too much stock in this decision. But if you maintain clients over a long haul, or if you’re like me and maintain a single site for many years, these decisions add up in importance, and technical debt becomes a real thing.
Next time you are looking at options for what plugin to use, consider the potential life cycle of the website, as well as the providers of the code you’re using.
Also, Joe and I talked more about this in the upcoming podcast on maintaining legacy sites.
