Compte-rendu Atelier Avenir d’Agora, 7 décembre 2004, Paris

Et réflexions personnelles
Dimanche 12 décembre 2004 — Dernier ajout lundi 26 novembre 2007

Ce deuxième atelier (le premier avait eu lieu fin août 2004 à Hourtin, voir mon précédent compte-rendu) rassemblait une cinquantaine de personnes représentant 3 catégories d’utilisateurs d’Agora :

  • des administrations publiques
  • des entreprises privées (SSII et SSLL)
  • des indépendants

Parmi eux, au moins 3 membres du staff des admins de SPIP-Contrib !

De plus, un sociologue universitaire était là en tant qu’observateur de l’évolution d’une communauté du « Libre » dans une de ses crises de croissance.

La journée a été animée par Benoît §Thieulin§ du SIG, Thierry §Raffin§ responsable du portail de l’ANPE et François §Élie§ président de l’Adullact.

Nous avons regretté qu’aucun des développeurs historique de SPIP ne soit présent.

Vous pouvez aussi lire compte rendu officiel de la journée.

La journée a été partagée en 3 temps :

  • matinée : historique et mise en perspective de SPIP et d’Agora
  • repas : temps informel et convivial
  • après-midi : pose de jalons pour l’avenir d’Agora
Retour Sommaire

Quelques éclaircissements au sujet d’Agora

Retour Sommaire

Éclaircissements historiques

Nous avons pu apprendre de la bouche de Benoît et Thierry qu’à l’origine d’Agora, il n’y avait pas un plan directeur informatique d’une DSI soucieuse de financer du libre.

Non, il y avait quelques personnes qui aimant SPIP ont réussi à faire financer des développements pour celui-ci de manière à le faire coller complètement à leur besoin. C’était le SIG.

Là-dessus s’est greffée l’ANPE avec Thierry §Raffin§ qui apprenant l’existence d’Agora s’est mis à l’utiliser et améliorer (économisant par là de fortes sommes). Puis le Ministère des Affaires Étrangères (qui utilise d’ailleurs SPIP au niveau de 40 ambassades).

François §Élie§ a aussi relativisé le caractère historique du reversement du source d’Agora à la communauté libre. En effet, il y a au moins un précédent : Lutèce. Ce qui par contre est nouveau, c’est que pour la première fois, des sociétés privées différentes sont amenées à intervenir en même temps sur le même CVS !

Retour Sommaire

Éclaircissements financiers

Les personnes qui sont en charge d’Agora (le bureau des mainteneurs) n’ont pas le soutien d’une quelconque DSI, n’ont pas de budget propre, font des économies faramineuses en utilisant SPIP et Agora, mais n’ont pas la gestion de ces économies. Ceci explique en particulier pourquoi il n’y a pas plus de contributions de fonctionnalités venant d’Agora dans SPIP.

Retour Sommaire

Où l’on se rend compte qu’on aime tous SPIP

Le constat principal de cette journée a été de nous rendre compte que les débats étaient passionnés parce que nous aimons tous SPIP. Nous aimons sa simplicité, nous aimons pouvoir faire des squelettes, installer un site pratiquement n’importe où, modifier le code parce qu’il est facile à comprendre. Nous l’aimons aussi parce qu’il nous permet de rendre des services bien plus grands à nos clients que s’ils devaient payer des licences logicielles exorbitantes.

Retour Sommaire

Où l’on admet être à un tournant

Le fork que représente Agora actuellement a été reconnu. Ce n’était pourtant pas un souhait d’Agora de le devenir.

Par ailleurs, certains ont exprimé qu’ils percevaient Agora comme un aiguillon du développement de SPIP (en particulier du nouveau compilo). Personnellement, je n’y crois pas. J’estime plutôt qu’Agora représente une direction de développement de SPIP et que le nouveau compilo en représente une deuxième. Agora est tenu par des impératifs de délais et donc ne peut pas changer de choix technique du jour au lendemain ; SPIP si…

Retour Sommaire

Perspectives d’avenir

L’après-midi a été consacré à parler de cet avenir. Allait-on se résoudre à un Agora évoluant sans SPIP ou existait-il encore un moyen de revenir sur une base commune et d’éviter ainsi de disperser nos forces ?

Retour Sommaire

Ouverture du bureau des mainteneurs

Une première décision a été actée : pourraient intégrer le bureau des mainteneurs tous ceux qui contribueraient de manière évidente à Agora. Ceci concerne aussi bien des administrations que des entreprises privées que des indépendants ! L’appel à candidature a été lancée sur la liste Agora-devel

Retour Sommaire

Vers un développement modulaire ?

J’ai (Jacques §Pyrat§) personnellement invité les gens présents ce jour-là à considérer qu’il y avait des signes forts sur la liste spip-devel d’une porte ouverte à un développement de SPIP modulaire. Développements qui pourrait, en partie, être réalisé par les gens présents à cette réunion. Mais rien n’a été décidé sur place.

Une autre porte a été ouverte par Benoît §Thieulin§ : « Chiffrez-moi combien ça coûterait de refaire Agora sous forme modulaire et dans combien de temps il serait prêt. ». Ça ne veut pas dire qu’il pourra le financer, mais s’il n’a pas ces chiffres, il ne pourra même pas l’envisager ! À noter que pour que ce ne soit pas un nouveau fork, il est nécessaire de réaliser un double développement : les fonctionnalités actuelles de SPIP + les fonctionnalités actuelles d’Agora.

François §Élie§ nous a alors présenté ce que pourrait être un SPIP modulaire ayant pour cœur le compilateur de squelettes.

Des questions essentielles sont alors sorties :

  • En quoi PEAR est nécessaire à Agora ? Réponse : toute la gestion des erreurs + les arbres de mots clefs + l’abstraction de la base de données s’appuient sur PEAR (personnellement, les erreurs PEAR, je vois pas comment déboguer avec, mais je dois mal m’y prendre…).
  • En quoi la programmation objet est elle nécessaire pour faire un SPIP modulaire ? Manifestement, ceux qui savent programmer en objet estiment ne pas pouvoir faire autrement, ceux qui ne savent pas trouvent des astuces (pour mémoire, de la programmation objet, ce n’est qu’une représentation d’un code qui finit par être binaire pour la machine…). La question est donc plutôt qu’est-ce qui est le plus coûteux (en temps d’exécution) ?
Retour Sommaire

Conclusion

Thomas Égli de Objectif Sciences propose de lancer cet été un camp de développement SPIP 2. La réussite ou l’échec de cette initiative dépend :

  • du degré de préparation de ce camp
  • de l’investissement de programmeurs talentueux pour encadrer ce camp ou y participer via le Net
  • du degré de reflexion pour réaliser ce SPIP 2 « Légo »

De mon point de vue, il y a là une occasion historique de travailler ensemble (administrations, entreprises, indépendants) pour réaliser le produit dont nous rêvons tous : un SPIP² dont nous pourrions gérer les briques selon nos besoins.

J’en serai, et vous ? MàJ 7 août 2005 : suite aux SPAMs inacceptables d’Objectif-Sciences auprès de la communauté des utilisateurs de SPIP, j’ai décidé en mai 2005 de ne plus participer à ces camps. Depuis lors, Objectif-Sciences ne communique plus rien au sujet de ces camps. Le site web n’est pas à jour et la communication lors des camps (qui aurait due être quotidienne) avec la communauté SPIP est inexistante.

Retour Sommaire

Pour aller plus loin

D’autres personnes présentes ou non à cet atelier on écrit dans les listes. Voici quelques liens vers leurs interventions pour parfaire votre opinion sur le sujet.

Des espaces pour commencer à discuter de ce que serait ce SPIP 2 se trouvent sur le lab :

Mise à jour le 5 janvier 2005 : Enfin, suite à cette journée, un atelier de « Réflexions pour un Spip modulaire » est organisé par le SIG le 10 janvier 2005.

Retour Sommaire

« Il y a deux façons d’aimer ses idées : la première consiste à les aimer un peu pour elles et beaucoup pour la part de soi-même qu’on y a mise. Cette façon s’accompagne généralement d’impatience et de témérité inconsidérée. Elle fait prendre au compte de l’amour-propre les méconnaissances et les oppositions qui s’adressent aux idées. Elle pousse à l’individualisation égoïste d’un bien qui n’a de valeur que lorsqu’il devient commun à beaucoup. Elle mène à l’exagération et à la singularité et finit par faire perdre à l’idée primitive jusqu’au cachet original qui pouvait en constituer le charme.

La seconde consiste à aimer ses idées pour elles-mêmes, pour le principe fécond qu’elles portent en elles, à les aimer d’un amour dont la clairvoyance, le désintéressement et la fidélité les gardent du danger d’égoïsme. Elle consiste surtout à savoir les aimer lorsqu’elles sont défendues et propagées par d’autres. Quand on aime ainsi ses idées, on croit à leur vertu, à leur victoire nécessaire et l’on éprouve point la tentation d’en servir le progrès par des moyens violents ou des procédés infraternels. »

Marius Gonin

Voir aussi : Agora → SPIP.

Vos réactions

  • François Daniel Giezendanner 22 juin 2007 15:41

    Bonjour Jacques,

    Lorsque SPIP AGORA était sorti en 2004 je m’y étais beaucoup intéressé.

    Depuis, beaucoup d’eau a coulé sous le pont et SPIP a beaucoup évolué, beaucoup progressé, entre autre en adoptant la technologie des plugins.

    Qu’en est-il aujourd’hui :

    • Du développement de SPIP AGORA ? s’est-il arrêté en 2004 ?
    • Des différences essentielles avec SPIP 1.9.2 ?
    • Du merge avec SPIP : est-il toujours d’actualité ou est-ce une démarche devenue obsolète ?

    Meilleurs messages

    FDG

  • > Compte-rendu Atelier Avenir d’Agora, 7 décembre 2004, Paris 14 décembre 2004 11:48, par Olivier Mansour

    Bonjour,

    Merci pour ce compte rendu.

    Toutefois ce paragraphe me hérisse un tantinet le poil : « *En quoi la programmation objet est elle nécessaire pour faire un SPIP modulaire* ? Manifestement, ceux qui savent programmer en objet estiment ne pas pouvoir faire autrement, ceux qui ne savent pas trouvent des astuces (pour mémoire, de la programmation objet, ce n’est qu’une représentation d’un code qui finit par être binaire pour la machine…). La question est donc plutôt qu’est-ce qui est le plus coûteux (en temps d’exécution) ? »

    J’ai l’impression (ici et là) que bcp pensent que la programmation objet c’est un machin de consultant fait pour vendre des prestations plus chères alors que des bonnes vieilles fonctions feraient l’affaire. (mis à part que, en presque 2005, ce n’est pas un point de vue super moderne 😉 ) C’est vraiment tout le contraire ! Le mécanisme d’héritage, par exemple, permet d’étendre un objet en récupérant toutes ses méthodes sans avoir à les réécrire ! Par exemple, la classe article hérite de la classe métier, ce qui lui permet de disposer d’une méthode de connexion à la base (_getDB ?). Si je veux changer la méthode de connection, je ne le fais qu’a un endroit ! et là on réponds … oui mais je le fais aussi avec une fonction. Certes, mais en programmation objet, on peut aussi surcharger cette fonction pour lui donner un comportement spécifique (c’est la base des drivers de SGBD pour les classes métiers)

    autre mythe, la programmation objet c’est plus lent …. personnellement je n’ai rien lu à ce sujet. (je suis preneur de toutes infos)

    On peut faire un gros projet en procédural … pour plus cher ! Je ne le conseillerais pas.

    bref, au final, tout n’est que code binaire 😉

    Olivier

    • Super, après les grands débats philosophique sur le libre, voici venu le grand débat technique sur le modele de programmation !

      Sauf que :

      • Spip n’est pas programmé en objet et ne le sera sans doute pas avant un moment (ce qui n’empeche pas de faire de l’objet dans les « extensions »).
      • L’interet de la programmation objet reste à démontrer pour ce projet (pour ce qui est de la « surcharge », spip fournit un mecanisme permettant de remplacer un include par un autre fichier, ce qui permet de « surcharger » des fonctions). Alors, une bonne raison ?

      Quel autre interet ? La maintenabilité du code (j’ai toujours trouvé ca formidable de faire payer le client plus cher pour se faciliter la vie …). Mais qui maintient le code de Spip ? Des champions de l’UML ? Des super-developpeurs objets ? Je ne crois pas. De toutes facons, il faudra encore un peu de temps avant que PHP propose réellement le service (en tous cas dans une version stable).

      Un peu de réalisme : Le noyau de Spip n’est pas et ne veut pour le moment pas etre un ensemble de classes.

      Sinon, coté perf. OK, rien de prouvé, mais il parait evident qu’un objet s’instancie avant de pouvoir appeler une methode … Coté memoire utilisée par contre, la preuve est faite il me semble que c’est plus gourmand de faire de l’objet (la barre reste à 8Mo chez la plupart des hebergeurs).

  • Veni, vidi et De Vinci 14 décembre 2004 01:23, par Jules Pige

    je suis venu, j’ai vu et j’ai pas tout compru mais ce que j’ai compru ça m’a branchu.

Revenir en haut