Le référentiel de plugins WordPress en vaut-il la peine ?

Si vous êtes un développeur de plugins WordPress relativement expérimenté, vous vous êtes probablement déjà posé cette question – peut-être plus d'une fois.

Si vous êtes un développeur de plugins WordPress relativement nouveau , vous vous demandez probablement « Attendez… pourquoi ne voudrais-je pas que mon plugin soit dans le référentiel ?!

Les deux questions sont valables.

Comme pour la plupart des choses dans la vie, il y a des avantages et des inconvénients à télécharger un plugin sur le référentiel officiel de WordPress.org. Dans cet article, nous examinerons les deux côtés du débat.

Les avantages du référentiel sont assez transparents et évidents, tandis que les inconvénients sont à la fois moins évidents et sans doute plus importants. En conséquence, cet article consacrera plus de temps à ce dernier qu'à celui-là.

Il est important de noter dès le départ que nous examinons le référentiel ici uniquement du point de vue du développeur - et non de l'utilisateur final (bien que certains facteurs centrés sur l'utilisateur aient un impact sur le développeur à long terme). Ainsi, bien qu'il existe un certain nombre de problèmes liés à l'utilisateur avec le référentiel - des problèmes qui méritent clairement d'être examinés de plus près - ces problèmes ne sont pertinents pour ce message que dans la mesure où ils ont un impact sur le développeur.

Alors, comment décidez-vous si le référentiel WordPress vaut la peine pour votre plugin ?Tweet

Commençons par examiner ses avantages.

Les avantages du référentiel de plugins WordPress pour les développeurs

Les développeurs de plugins bénéficient d'un certain nombre d'avantages en utilisant le référentiel pour héberger leurs plugins. Selon que vous êtes un développeur de plugins professionnel avec de nombreux produits ou que vous le faites juste pour l'amour de WordPress, ou pour un autre objectif, chacun de ces avantages peut avoir un poids différent pour vous.

Au départ, il est important de noter une exigence critique pour l'utilisation du référentiel en tant que développeur : chaque plugin du référentiel doit être gratuit à télécharger et à utiliser. La vente incitative est autorisée, mais il y a des limites.

Par exemple, vous pouvez créer deux versions de votre plugin. Le premier – celui hébergé sur le référentiel de plugins WordPress.org – doit être gratuit, mais il doit aussi être fonctionnel. Ainsi, vous pouvez créer une version de votre plugin qui n'est pas aussi complète à télécharger sur le référentiel, puis proposer la vente incitative à l'utilisateur pour la version complète, soit pour un paiement unique, soit sur la base d'un abonnement. AKA le modèle Freemium.

Il y a donc un avantage pour les développeurs désireux de prendre ces mesures supplémentaires : vous bénéficiez de tous les avantages du référentiel pour une version gratuite "légère", et la possibilité de vendre ensuite votre version premium aux utilisateurs de la version gratuite.

La théorie de travail derrière cette configuration est que les utilisateurs de votre version gratuite seront satisfaits de sa fonctionnalité, et donc ils sont plus susceptibles d'être disposés à débourser de l'argent pour utiliser la version premium. Cette configuration elle-même est certainement un avantage pour le développeur. Cela facilite la conclusion de la vente et augmente considérablement la taille de l'audience qui a été déplacée vers cet endroit plus facile à convaincre dans le cycle d'achat.

Le référentiel WordPress augmente la taille de l'audience qui peut potentiellement être déplacée vers un endroit plus facile à convaincre dans le cycle d'achat.Tweet

Et cela nous amène au deuxième avantage clé pour les développeurs utilisant le référentiel : l'exposition à un public vaste et diversifié. Comme le souligne "Comment créer un plugin WordPress, partie 2" de Scotch.io, le référentiel est bon pour les développeurs car vous devenez "une partie de la communauté WP".

C'est particulièrement vrai si l'on considère que la communauté WordPress comprend des personnes d'un certain nombre de pays différents qui parlent de nombreuses langues différentes : "Il est très logique d'avoir votre plugin facilement [translatable] sans avoir à toucher à son codage de base."

Cette communauté peut également aider à accélérer le processus de débogage et de développement futur - indéniablement un autre avantage de l'utilisation du référentiel.

Les développeurs peuvent certainement déboguer et affiner leurs propres plugins. Mais il est indéniable que le processus est beaucoup plus rapide, plus fluide et plus approfondi avec l'aide d'une large base d'utilisateurs actifs.

C'est quelque chose que beaucoup de développeurs - en particulier ceux qui n'ont pas de versions premium à vendre - ne peuvent tout simplement pas reproduire de manière rentable ou rapide. Ce n'est tout simplement pas pratique.

Et puis, il y a aussi la tendance que nous avons tous dans une certaine mesure : devenir « aveugle au code » dans notre propre travail. Tout comme les rédacteurs ne peuvent souvent pas voir leurs propres fautes de frappe ou de grammaire, les développeurs peuvent parfois manquer des problèmes dans leurs propres plugins - des problèmes qu'un groupe d'utilisateurs engagés peut plus facilement trouver et identifier.

Le référentiel peut également offrir à un développeur de plugins un accès à des commentaires d'utilisateurs opportuns et nuancés. Comme le note Speckyboy dans cet article décrivant certains des avantages et des inconvénients du développement de plugins hébergés sur un référentiel :

La solution logicielle Trac qui active le référentiel est en fait assez apte à laisser les utilisateurs commenter les fonctionnalités d'un plugin ; les utilisateurs du plugin pourront interagir directement avec le développeur du code, et ils pourront à la fois commenter les fonctionnalités et les réviser en utilisant le système de commentaires de base qui est aussi utile qu'intuitif.

Lorsque cela est facilité, les utilisateurs sont plus susceptibles de fournir des commentaires significatifs, ce qui ne peut qu'améliorer votre travail.

Enfin, il existe une perception intégrée des utilisateurs pour les plugins de référentiel selon lesquels ils sont de meilleure qualité et plus fiables que les plugins qui ne sont pas répertoriés ici. (La question de savoir si cette perception correspond à la réalité est une autre question que nous explorerons plus tard dans cet article.) Cela rend globalement plus probable qu'un utilisateur télécharge, active et utilise votre plugin.

Voilà pour les avantages. Quels sont les inconvénients ?

Le support est une lourde charge à transporter

En exigeant que le développeur fournisse le support nécessaire pour prendre des mesures pour « obtenir » les demandes, le référentiel exécute un système d'extraction, par opposition à un système qui « pousse » les notifications au développeur.

Si votre plugin n'a que quelques dizaines de téléchargements et que le développement de plugins n'est qu'un passe-temps pour vous, ce n'est peut-être pas un gros problème. Mais s'il s'agit de votre entreprise et/ou si vous avez plusieurs plugins, dont quelques-uns particulièrement populaires, un système pull peut vraiment faire des ravages sur votre productivité, votre emploi du temps et votre santé mentale.

Avouons-le : il peut être long de proposer un support pour les plugins gratuits, même si le développeur souhaite proposer un support.

Offrir un support pour les plugins gratuits peut être très consommateur de ressources, même si le développeur est enclin.Tweet

Sous les plaintes de nombreux développeurs concernant le référentiel, il y a une perception d'un manque d'intérêt pour le développeur.

Souvent, les critiques de ces développeurs se heurtent à une version de « Si vous ne voulez pas passer du temps à supporter un plugin gratuit, évitez le référentiel. Publiez-le sur GitHub.

Mais même si les demandes d'assistance raisonnables pour les plugins gratuits ne vous dérangent pas, vous vous battez toujours contre ce que beaucoup pensent être une plate-forme malheureusement conçue pour l'assistance, qui impose aux développeurs l'obligation de surveiller et ne fonctionne pas nécessairement avec votre flux de travail établis.

Système d'examen/de notation susceptible d'être abusé

De nombreux développeurs conviennent que le système actuel de révision et de notation est tout simplement trop susceptible d'être manipulé par ceux qui ont de mauvais motifs ou ceux qui n'ont tout simplement pas compris ce que faisait le plugin, comment l'utiliser ou demander de l'aide.

James Laws de WP Ninjas l'a bien dit dans un article de ManageWP :

Le problème est qu'il n'y a aucune responsabilité lorsque quelqu'un fait ces évaluations. Les utilisateurs disent que quelque chose est cassé simplement parce que cela ne fonctionne pas dans leur configuration particulière, mais ce n'est pas toujours le cas. Parfois, quelque chose d'autre est cassé dans leur configuration, ou ils ne comprennent tout simplement pas comment utiliser correctement le plugin.

Problèmes de qualité avec les plugins

Alors que les utilisateurs peuvent percevoir les plugins hébergés dans le référentiel comme étant de meilleure qualité, ce n'est pas nécessairement vrai pour les développeurs, dont beaucoup ont commenté la présence de plugins de qualité douteuse dans le référentiel.

Un exemple de cette perception peut être trouvé dans le post "What Lurks in the WordPress Plugin Repository?" qui détaille les enjeux suivants (certes, en 2011) :

1. "Plus de la moitié des plugins du référentiel ne sont pas compatibles avec WordPress 3.x"
2. "85% des plugins que j'ai testés avaient des avertissements, des erreurs et des avis PHP"
3. "Avec un peu de recherche, j'ai trouvé un plugin dans le repo avec une faiblesse et j'ai pu l'utiliser pour pirater un site et le transformer en drone"
4. "Seulement 32% de ces 15 000+ plugins ont été mis à jour en 2011"
5. "... les deux tiers de tous les plugins n'ont pas été mis à jour cette année, et un tiers n'a pas été mis à jour depuis 2009."

Mika Epstein a récemment fait une présentation spectaculaire sur l'ensemble du processus d'examen depuis le POV des volontaires (cinq, croyez-le ou non - seulement cinq) qui examinent les plugins soumis pour le référentiel (en moyenne, 35 par jour).

D'après cette présentation, il est clair que la révision est un processus long, ardu et axé sur les détails, conçu pour détecter les problèmes de code, ainsi que les violations des directives du plugin telles que le nom, la marque, etc.

Est-ce que ça réussit ? Pas entièrement. Bien sûr, tout système géré par des humains sera susceptible d'un certain niveau de faillibilité.

Le processus d'examen lui-même

La présentation de Mika expose également bon nombre des problèmes liés au processus d'examen. Fondamentalement, avec une équipe de cinq membres bénévoles et 35 plugins soumis en moyenne chaque jour, travaillant sur une plate-forme BBPress obsolète, il n'est pas raisonnable de s'attendre à un processus rapide, rationalisé et orienté développeur.

Le résultat final : sur la page « ajouter un plugin » sur WordPress.org, vous ne saurez pas combien de temps vous allez attendre, mais vous pouvez voir combien de plugins sont en ligne avant le vôtre.

Au moment d'écrire ces lignes, 145 plugins dans la file d'attente de révision, avec 108 en attente de leur révision initiale.Tweet

Et, comme le dit le post de Speckyboy, "Automattic n'hésite pas à imposer [sa] volonté aux développeurs du référentiel."

Il convient également de noter que le processus de téléchargement et de soumission n'est pas très convivial, en particulier pour les novices, ce qui n'encourage pas les nouveaux développeurs à tester leurs compétences et à ajouter à l'expérience WordPress de manière créative.

Pas assez de données!

L'hébergement de votre plugin sur le référentiel de plugins WordPress ne vous fournira pas beaucoup de statistiques et de données sur qui utilise votre plugin et comment. Vous développerez à l'aveugle, n'ayant à faire qu'avec le nombre de téléchargements , et une estimation du nombre d' installations actives. Il est donc pratiquement impossible de prendre des décisions intelligentes et basées sur des données.

Comme le suggère Chris Lema - lorsque vous avez des données, vous n'êtes pas "à l'aveuglette" et cela peut vous ouvrir les yeux sur des décisions très importantes et urgentes qui doivent être prises concernant votre plugin. Ces décisions seront généralement dans l'intérêt de vos utilisateurs en termes de développement et de support, et éventuellement pour le processus d'optimisation du marketing et de la tarification de votre plugin.

Voici un rapide rendez-vous que Matt Cromwell a eu avec Chris Lema, discutant de ce sujet, entre autres sujets connexes.

Les développeurs de plugins hébergeant leurs plugins avec le référentiel WordPress ont néanmoins un moyen légitime d'obtenir les données de leur plugin, tant que cela se fait avec le consentement et l'approbation de l'utilisateur. Freemius Insights peut vous aider en fournissant toutes les pièces manquantes dans le puzzle de données d'un plugin WordPress.

Restrictions sur les plugins

Enfin, les développeurs doivent faire face à une longue liste de restrictions sur les plugins acceptés pour le référentiel.

Comme indiqué en bref sur la page d'informations sur le répertoire des plugins de WordPress.org pour les développeurs, ces restrictions incluent :

1. Votre plugin doit être 100% conforme à la GPL (et cela inclut les actifs non PHP, tels que les images et CSS, qui ne sont pas des dérivés du code WordPress)
2. Ne peut rien faire d'illégal ou de "moralement offensant"
3. Le développeur doit utiliser le référentiel Subversion fourni par l'équipe du plugin si vous souhaitez qu'il apparaisse sur le site WP.org - le répertoire "est un site d'hébergement, pas un site de liste"
4. Doit avoir un fichier readme.txt lisible et compatible avec la norme de fichier readme du plug-in WP

Il existe une liste beaucoup plus longue de directives et d'exigences, y compris une interdiction de violer les marques déposées de WordPress et un autre rappel que l'équipe peut supprimer les plugins pouvant être qualifiés de spam, de plugins illégaux ou moralement répréhensibles.

Conclusion

Un manque perçu de sensibilisation ou de considération pour la perspective et les besoins de la communauté des développeurs sous-tend bon nombre des inconvénients mentionnés dans cet article.

Couplé avec le problème perçu ou réel avec la qualité des plugins acceptés pour le référentiel et les nombreuses exigences qui sont appliquées, il n'est pas étonnant que le référentiel perde son attrait pour certains développeurs.

Alors, quelle est la solution ?

Si vous êtes un développeur qui souhaite apporter une contribution rapide à la communauté WordPress avec votre code, vous pouvez envisager GitHub, comme Coen Jacobs :

Il s'agit essentiellement d'un référentiel distant où vous pouvez stocker votre code. Mais GitHub offre plus. Vous obtenez un système de tickets de base, un wiki et un moyen agréable de visualiser (et de partager, si votre référentiel est public) votre code en ligne.

Bien sûr, GitHub offre son propre ensemble d'avantages - et d'inconvénients - aux développeurs de plugins. Vous devez donc examiner la question de manière critique avant de prendre une décision finale.

Mais, si vos intentions et vos plans dans le monde des plugins WordPress sont à long terme et répétitifs - et peut-être que vous aimeriez aussi monétiser votre plugin en utilisant le modèle freemium à un moment donné - peut-être que le référentiel WordPress.org vous convient, malgré tous ses inconvénients. En outre, en tant que membres de la communauté WordPress, nous devons faire pression pour que le référentiel améliore ses inconvénients et ses problèmes.

Qu'est-ce que tu penses? Les avantages du référentiel valent-ils tous les inconvénients et problèmes pour les développeurs de plugins ?