Cette proposition part du constat que les collectifs militants ont un peu de mal ont ces dernières années avec les outils de publication sur internet disponibles. Difficultés en amont autour du développement de ces outils. Difficultés en aval avec le choix, l’installation, la personnalisation et la maintenance de ces outils au sein de chaque collectif. Avec pour résultat des sites vieillissants, peu accessibles ou lisibles, très peu « multimédias » ou encore lourds à animer.
A l’origine, par exemple, Indymedia était organisé autour de quelques systèmes de publication pensés par et pour ce réseau [1] : Mir, SF Active, ou plus récemment Samizdat (Indymedia Ukraine) et Oscailt (développé par Indymedia Irlande)… La complexité galopante des outils de publication liée à leurs possibilités exponentielles (et qui nous sont demandées par les usagers de nos sites) rend impossible ce qui a été fait jusqu’à présent : les « anars geeks » du monde entier peuvent difficilement développer entre eux les outils dont nous avons besoin. Et y’a certainement d’autres choses plus intéressantes à faire aussi.
Même au sein d’un collectif relativement geek comme Rebellyon, si un certain nombre d’améliorations a pu être réalisé au cours de l’année écoulée, le collectif touche aux limites de Spip à bien des niveaux en terme de transparence de la modification des articles, de collaboration dans la rédaction ou la modération, ou encore dans l’accessibilité de la publication pour les personnes qui proposent des articles. Ou encore en terme de diffusion des améliorations que nous pouvons faire.
Distribution ? Spip ?
Spip est en cours de « modularisation » depuis quelques années déjà, afin (entre autres) de permettre la réalisation de « distributions » en fonction d’usages spécifiques. En gros, cela fonctionnera selon le même concept que Linux :
Extrait de la page Wikipedia sur les distributions Linux :
Une distribution Linux (ou distro, distrib), appelée aussi distribution GNU/Linux pour faire référence aux bibliothèques et logiciels du projet GNU, est un ensemble cohérent de logiciels (la plupart étant des logiciels libres) assemblés autour du système d’exploitation Linux.
Il existe une très grande variété de distributions, ayant chacune des objectifs et une philosophie particulière. Les éléments différenciant principalement les distributions sont : la convivialité (facilité de mise en œuvre), l’intégration (taille du parc de logiciels validés distribués), la notoriété (communauté informative pour résoudre les problèmes), l’environnement de bureau (GNOME, KDE, ...), le type de paquet utilisé pour distribuer un logiciel (principalement les deb et RPM) et le mainteneur de la distribution (généralement une entreprise ou une communauté). Le point commun est le noyau (kernel) et un certain nombre de commandes.
Jusqu’à très récemment, Spip était livré comme un bloc assez complet et complexe difficilement personnalisable. L’expérience du fork [2] d’Indy-Spip en a été la résultante il y a quelques années.
Mais depuis Spip 2.1, il existe ce qu’on appelle dans Spip les extensions [3] : livrés avec le moteur de Spip, elles n’ont pas besoin d’être activées pour fonctionner et ouvrent une voie à la réalisation de distributions spécifiques en fonction de l’usage prévu (blog, site de photo, associatif etc.).
Une distribution Spip « Médias Libres » (ou le nom qu’on choisira) comprendraient ainsi un certain nombre de ces extensions que nous aurions choisies et / ou développées à l’attention des « médias libres ». Les collectifs qui utiliseraient cette distribution auraient bien évidemment la possibilité de rajouter à cette distribution (Spip + des extensions choisies) les plugins spécifiques qu’ils choisiraient selon leurs besoins / envies.
Pourquoi choisir Spip ?
Spip est utilisé par la grande majorité de nos sites francophones, qu’ils fassent partie d’Indymedia ou pas, qu’ils soient des sites d’infos, de radios ou de journaux. Si Spip peut paraître aujourd’hui un peu vieillot par rapport à d’autres outils de publication sur internet (Drupal par exemple, Joomla ou même Wordpress) il est particulièrement intéressant pour nous à plusieurs titres :
d’abord parce qu’il est depuis son origine orienté vers une collaboration en ligne sur les articles,
parce qu’il est francophone et possède une communauté importante et plutôt sympa,
et surtout parce qu’il est techniquement particulièrement adapté aux sites avec peu de resssources côté serveur (grâce à son système de cache qui permet de servir plus de pages à plus de gens avec des serveurs limités en capacité) [4].
On peut aussi évoquer le fait que son interface est déjà disponible dans énormément de langues et qu’il est facilement traduisible, ou encore qu’il va évoluer prochainement dans un sens pertinent pour nous : le projet TextWheel permettra par exemple une meilleure accessibilité pour la publication aux gens qui utilisent d’autres outils de publication (le pied pour les spammeurs de sites d’infos :p), l’interface privée sera personnalisable, ou plus globalement son organisation de plus en plus inspirée de Debian (du système de gestion de paquets, de distributions, à son utilisation de Git).
Quel intérêt pour les sites comme les nôtres ?
Fournir un outil clés en main pour des collectifs qui se montent.
Ne pas réinventer la roue chacunE de notre côté : partager des solutions éprouvées, ou des développements à faire sur des fonctions qui nous manquent et qui n’intéressent pas pour l’instant la communauté Spip. En gros créer un espace de travail (réflexion, développement, traduction) qui nous soit commun.
Assurer un suivi collectif des évolutions de Spip. Son développement étant relativement pléthorique depuis la création des plugins, il n’est pas évident pour un collectif militant de s’y retrouver et de suivre les différents changements de Spip.
Cibler les besoins de traduction pour des collectifs non francophones mais aux activités similaires qui souhaiteraient utiliser Spip. En listant des plugins que nous trouverions nécessaires, nous pourrions concentrer nos efforts de traduction.
Et pourquoi pas fournir un cadre à l’obtention de subventions ou de donations pour le développement de nos outils.
Par où on commence ?
Tout d’abord en listant précisément des plugins qui nous intéressent tous et qui seraient donc intégrées en « extension » dans cette distribution.
En rendant publics des fonctions développées par et pour nos collectifs (dans le cas de Rebellyon par exemple, les plugins permettant l’encodage de vidéos en .ogv ou l’allègement de l’interface privée, mais il y en a d’autres).
En réfléchissant aux fonctions que nous souhaiterions voir développées.
En réunissant les squelettes de nos sites pour qu’ils puissent être repris par d’autres.
Merci de vos retours !
Messages
13 octobre 2010, 16:08
Je ne veux pas faire mon troll, mais je n’ai pas les mêmes expériences avec SPIP que ce que peux dire cet article au niveau des ressources que ce CMS peut utiliser.
L’article en lien sur la comparaison entre les CMS me paraît un peu douteux. En tout cas, la méthode de comparaison me paraît trop flou pour pouvoir représenter quelque chose qui d’approche d’un benchmark un peu sérieux.
Mon expérience avec spip, c’est que à partir du moment ou le site a des squelettes un peu complexe, il est capable de bouffer quand même beaucoup de ressources.
L’autre expérience c’est son language de boucles, qui est plutôt difficile, et était limité (mais ca a l’air de s’améliorer). En tout cas trop éloigné d’un langage de programmation pour être vraiment optimal.
Développé des trucs sous SPIP, pourquoi pas, mais de nos jours il existe des framework/langage qui permette bien plus et bien plus vite, parce qu’ils tirent parti des dizaines d’années d’expérience de développement, comme rails par exemple, qui a un modèle de developpement qui permet de créer rapidement des applications (MVC, developement « agile »,...) et sont à l’heure du 2.0 (jveux dire par là intègrent ajax out-of-the-box).
Bref ca demande beaucoup d’énergie de choisir SPIP, mais si la force est là pour tenir ce projet, c’est chouette. D’autant que SPIP est un CMS que les francophones connaissent bien.