In the open source development world there is a lot of emphases on developing software to solve specific problems, there is much less emphasis on solving those problems well. That is, solving those problems so the most people are serviced, or so that users of software have the flexibility they need (there is also often a lack of commitment to User Experience Design but this is a shameless side plug). And there is often a real lack of collaboration around competing solutions. This is evident in the software which is created for use by linguists (usually also coded by linguists for solving the linguists’ challenges) but this is also evidenced in a different sphere of programing in the WordPress eco-system. In the WordPress eco-system there is a plethora of plugins which are abandoned. WordPress is GPL’d and so these plugins are GPL’d too. However, the repository – the human visual interface to the repository – allows for coders to grab code, and modify it for their ends, but it doesn’t allow for merging once the plugin has been “updated”. (It is true that not all changes are “updates”, sometimes people need one-off solutions.) But the net result is that early 1/3rd of all plugins for wordpress are abandoned. Their developer has been paid and has now ended their relationship with the commissioning client, or the WordPress eco-system no-longer requires the service options provided by that plugin. Matt Jones created an info-graphic to illustrate this point and to bring awareness to the problem. My comments below are my reply to him, with some minor corrections .

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.