Plugin Abandonment


My take is that though this is a great idea (setting up an adoption program for old code/plugins), there are three larger problems at play here. Theses problems have to do with the sociology and economics behind the systems in which plugin developers interact.

  1. Quality/scope of the idea.
  2. Quality of the code.
  3. Type of consumer.

Let me explain:

  1. By quality/scope of the idea I mean that there are usually three plugins per idea. i.e. I was recently looking at a plugin for using SMTP to do my mail rather than the default php mail(). There are three or four plugins for this – from a consumers point of view this is really absurd. Why do we need three or four plugins for one simple task? we really don’t. Some code should just be sunset and forgotten about. But this means managing the problem-space and finding reliable solutions for given problems. However, if we look at how plugins come about it is because a developer gets a contract. So rather than augment a plugin for a particular client they just up and create a new one. There are several reasons for this:

    A. The implementation task is perceived by the client to be too much or difficult and therefore is contracted out or

    B. To achieve the contracted result the developer could spend billable/unbillable time researching the available plugins or they could spend billable time to develop a plugin. At the core of what a plugin in the community of wordpress people it is a feature which is implemented for an end user. This is really different than say a Drupal module which is usually a bit of a framework which can pull things together to present multiple options to end users. The target audience of a Drupal module is usually a developer, not an end user. So it goes back to how is the community going to respond to managing the problem space? – Look a the resume/hresume/portfolio problem space there are a lot of plugins in that sector, but they all look at solving a particular problem not a presenting users one of a variety of solutions for a single problem space.

  2. Quality of the Code: is pretty understandable in that some code is crappy or follows a really different coding/data management style. Dissidence at this level drives developers apart. The WP community could take a stronger stance on the quality of code issue and sunset or force adaption and download through the SVN rather than the /extend for code which makes two calls on functions which have been retired from WordPress. This way “old” and therefore “bad” code can be removed from the UX of searching for a plugin which does X.
  3. Type of consumer: There are really two types of consumers of the WP code those who can code and those who can not. Look at the forums and the kinds of questions being asked. So who is the target audience of the plugins and themes repo? It feels like it is trying to pander to the consumer-end user, the “do-it-yourselfer” and facilitate the conversation with the developer…. and Automattic sits in the middle.

So, I think that in perspective, that this abandonment problem is a by product of how the community of developers approaches the problem space. In a way it is a UX problem because we as developers are not presenting user plugins which serve large enough solutions. – but is it in our financial interest to do so?

It is true: There needs to be an official referral system to a successor plugin.

Leave a Reply

