Getting Locked Into Third Party Web Tools How It Can Kill Your Site

Filed under: Site Management

Most website developers or even end users that don’t dive deep into code are at serious risk when it comes to depending on third party tools to distribute content. The risk comes when a main tool that you depend on is no longer supported by the developer or when upgrades are delayed making the current product unusable.

Often there are work-arounds or other aps that can fill the void but sometimes the popularity of the tool is so great that no other developer will approach making a similar product.

Unfortunately this happens most often with Open Source / Public Domain type products that may see widespread use but often do not account for sufficient income to support the developer. This is not to say that commercial software can not let you down in the same way.

Our site like millions of others that make use of the WordPress publishing platform and the millions of other sites that make use of Drupal, Joomla and other offerings also depends greatly on third party plugins.

In addition to publishing platforms you have many other products such as shopping carts, webforms / bbs type aps, classified ad programs, website galleries, directory listings  and other applications that can be a large part or even a primary part of a site and each one of them can have their own third party plugins.

And something we almost never think about is the software that sits behind our sites.. the Databases and Webservers along with programming languages like PHP, Perl and the rest.

All of these products along with every third party ap or plugin that our sites depend on can cause a serious outage if the projects are not continued and updated by the developer but is it really the responsibility of the developer to provide continued updates, patches and support?

We don’t think it is their responsibility especially if they are not getting paid to do it.

Where does that leave us?

NPSites runs a number of sites other then this one and each one has its own requirements. To manage each of them with only in-house tools would mean extreme delays in upgrades and new offerings. It would also require limiting our support for others and would most likely cut into our content deployment.

As a matter of fact with the new oAuth requirements from twitter we have been forced to completely halt content building in order to address this single problem.  At this point we have about 70% of our sites patched but some may not be fully functional for a couple weeks.

Now we could point a finger of blame at twitter for not announcing the oAuth requirement 6 months prior to its enforcement … we actually never got notice until 3 weeks after it was implemented which is pretty sad for a company that is professionally run and so popular.

But Twitter is not alone. Although Amazon will give you six months to a year lead time they have never provided new code samples and documentation in a timely manner for their API changes. And we have seen  base server aps not provide documentation to address major changes only to need to resort to googleing for any insite that a random person going through the same problems might have posted…

Conclusion

Maybe it is our own fault for getting too adventurous in our site offerings.. after all couldn’t we use some basic html to display one large image per page and then dare I say image maps to make links?

No that is not reasonable and blaming a third party developer that may just not have the time to deal with upgrading free code due to other things going on in their life is also not reasonable.

I think what we all need to do is announce these problems in the proper forms.

If you find a patch then implement it and share it with others.

If you know of a big change coming then let developers know so maybe they can schedule a weekend to make updates and not look like the bad guy for not having time to upgrade an ap the last minute. We know how long these things take and if a company is changing an api they are not going to do it overnight unless its an emergency security situation.. so give developers time and the tools.

And when a commercial business changes their API they should work with open source projects and their third party developers to make sure everything is working prior to the change over.

It is inexcusable for Twitter to not contact developers prior to the change over especially when they know millions of sites and tens of millions of people will be effected… but again although this is another huge FAIL .. they are not alone..