¿De dónde vino la idea de Spip? ¿A qué necesidad respondía?¿Puedes brevemente trazarnos las grandes líneas en la historia de Spip, cuándo, dónde, cómo? ¿Y sobre todo qué? Y, finalmente, ¿cuáles son los vínculos entre Spip y Uzine, y el Minirézo (como b presentación de los dos últimos si quieres...)

Bien, te hago un paquete por las tres cuestiones, porque todo es un poco lo mismo. Por otra parte es lo que permite incluir las características de SPIP.

El minirézo es un grupo informal de Webmasters (no siempre los mismos, desde el principio cambian regularmente) que se pusieron a discutir en torno a lo que les gustaba hacer: webzines, a la manera de un sitio que existía, en 1995-1996, La Rafale. Eso inspiró rápidamente el Manifiesto del Web independiente, y un sitio llamado uZine. El principio de uZine era ser a la vez un espacio de activismo y reflexión, y una experiencia de grupo: todos los participantes de minirézo disponían del acceso ftp al lugar, e instalaban ellos mismos sus textos (lo que no planteaba problema, puesto que al principio del minirézo tod@s eramos webmasters de nuestros pequeños sitios; y entonces no había dificultades para que cada uno resolviera lo del HTML).

Al cabo de un poco más de dos años, hacia mediados de 1997, el sitio se detuvo progresivamente. Una de las razones era que cada puesta al día se volvía cada vez más difícil de realizar: para cada nuevo artículo, era necesario actualizar varias otras páginas para hacerle referencia, y a veces se eliminaban las modificaciones de otro participante.

Mientras tanto, empecé con PHP, y luego con mySQL. Pero lo primero que salió no fue un sistema de publicación, fue el "Portal de los Amigos de Lazuly". El objetivo del Portal era automatizarlo a tal nivel que Laz puediera irse quince días de vacaciones en un barco denominado "SPIP" sin que se notara su ausencia.

A mediados de 2000 se decidió reactivar uZine, pero esta vez bajo una forma diferente. En particular, con una herramienta permitiéndonos administrar el sitio a varios y automatizar la compaginación. Los primeros imperativos, resultantes de la experiencia del primer uZine, eran:

 que la publicación en línea de los artículos sea lo más simple y rápida posible;
 que haya una herramientas de trabajo cooperativo para poder administrar colectivamente el trabajo editorial;

Desde los principios, las cuestiones no habían evolucionado mal. Del "webzinat" [1], se había pasado a algunas experiencias sobre el trabajo colectivo sobre un mismo sitio; y allí, se quería experimentar el trabajo colectivo sobre la decisión editorial (es decir, la negociación, dentro del sitio, de la línea editorial y la elección de lo que debía publicarse). Pues, otros dos imperativos aparecieron:

 que todos los visitantes puedan proponer artículos;
 y sobre todo, que estos visitantes puedan también participar en los debates sobre las elecciones editoriales.

Por ello nació una clase de preversión de SPIP para uZine, para responder a estas necesidades específicas. Ese desarrollo se convirtió en SPIP al año siguiente y se distribuyó bajo licencia GPL.

Para mi, entre las grandes fuerzas de Spip, se podría decir: maqueta personalizable a deseo (no hay "3 columnas" irrenunciables al estilo Nuke, por ejemplo), instalación ultra simple (automatizada, con elección de las opciones según los anfitriones), velocidad del producto (con sistema de cacheo). ¿Ves otras?

En mi opinión, es el trabajo sobre el interfaz de gestión del sitio: la interfaz se concibe enteramente desde la óptica editorial. Se trata de efectuar una función sobre una base de datos, pero siempre utlizando una lógica de publicación editorial. Es lo que tranquiliza a los no técnicos (en particular, a los visitantes que proponen artículos: la lógica que se les propone es la de la publicación de documentos, donde no hay ninguna consideración técnica aparente) y que hace que la utilización de SPIP generalmente se acepta bien por usuarios a priori hostiles a la idea de trabajar sobre un "programa informático para Internet" (es frecuente en las asociaciones: los refractarios a la informática se suman, porque la interfaz corresponde una lógica que ya conocen).

Y aquí también otra ventaja, pero es muy personal: ¡fuimos nosotros quienes lo hicimos! No sabía dónde abordar este punto en tus preguntas, entonces lo digo aquí. Cuando comenzamos a reflexionar sobre el sistema de publicación, con Lazuly y Erwan, Erwan ya se desarrollaba un sistema para administrar el sitio Ornitho; y con Laz, nos apresuramos a encontrar argumentos engañosos para no utilizarlo (interfaz poco bonito, no es eso lo que se busca...). Realmente, lo que queríamos era hacerlo nosotros.

De la misma forma que no habíamos puesto con HTML, el placer era el "DO IT Yourself" (tres acordes de guitarra, y a ti aquí sobre la escena del CBGB!). Queriamos poder hacer nosotros mismos nuestros garabatos en PHP y construir nuestras peticiones mySQL. Por numerosos aspectos (y eso se veía enormemente en la primera versión de SPIP, terriblemente mal programada según los criterios de los informáticos), SPIP se construyó así: se aprendió a hacerlo haciendolo. No sé si el planteamiento es perceptible, pero es central: el placer de la Red, no es escribir sus textos en Word y copiarlos -clavar en una interfaz toda hecho bajo Dreamweaver: es esto, es el "hágalo usted".

Y un poco es este deseo el que se espera comunicar a los usuarios; los que quieren solamente escribir, intentar estructurar sus textos de manera elegante fácilmente... ; los que quieren "toquetear" su interfaz pueden construir cosas más o menos elaboradas... Se proporciona una herramienta donde la parte dura ya está resuelta (administrar las peticiones MySQL e indicar los criterios en bucles PHP, es de una porquería!), y el placer es ver a los usuarios formarse, solos y entre ellos: allí están los que comienzan con la interfaz por defecto, luego que deciden enterarse del HTML para toquetear un poco a su salsa; y algunos hasta deciden aprender los rudimentos del PHP, no para modificar SPIP mismo (o sí), sino para precisar sus esqueletos...

¿Puedes decir más sobre cada una de fuerzas que acabo de citar?

La libertad de la interfaz gráfico del sitio público, eso realmente no era una opción; era imprescindible. Uno de los placeres de tener su sitio Web, es a pesar de todo darle la cabeza que se quiere. La única sutileza aquí consistió en desarrollar un pequeño sistema de "bucles", que permite recuperar la información con algo que se funde en el HTML, sin tener que administrar las peticiones MySQL. Cuando se "ejecuta" su esqueleto, las llamadas de los bucles desaparece, y en los lugares donde están las llamadas (balizas) la información se hace visible (los títulos aparecen, por ejemplo, sustituyendo la mención "#TITRE").

Los dos puntos restantes para nosotros eran también imprescindibles: la configuración engorrosa de tener que modificar un fichero de texto, eso lo rechaza cualquier ser normalmente constituido; y para el cacheo, obligado también, con la primera versión que no lo tenía, uZine hacía caer el servidor del amigo que nos albergaba cada dos días. No sé bien porqué esas características no eran más extendidas en los otros sistemas, ya que una vez que se decide hacerlas, es relativamente simple.

Dicho se de paso, sobre la simplicidad de la instalación, en algo debimos equivocarnos: recibí hace poco comentarios de "nukers" comentandome que no consiguieron instalarlo.

Para el aspecto gráfico, hablan de "esqueletos", el equivalente nuke de "tema". ¿Piensan desarrollar más? ¿Poner para descargar? ¿Incitar los diseñadores de spip a proporcionar los suyos libremente?

Precisamente, no sólo desempeñan la gestión gráfica, por eso no son "temas". Administran por supuesto la presentación gráfica, pero también la estructura del sitio. Cuando se comienza a tocar los esqueletos, se puede adaptar SPIP a necesidades muy específicas; hay por ejemplo un tutorial basado en un hipotético sitio sobre vídeo juegos: con los esqueletos normales de SPIP, tal sitio es rigurosamente imposible de realizar; pero al crear los esqueletos ad hoc, se obtiene un resultado que no estaba previsto en el origen.

Por eso, como hay combinaciones de situaciones imprevisibles o necesidades específicas, crear esqueletos "universales" (válidos para todos los sitios, a la manera de los temas de Nuke), es a la vez muy difícil y definitivamente es una buena solución. Los mejores esqueletos, son indudablemente los concebidos específicamente para la estructura que se quiere dar al sitio.

Pero obviamente, cuando los diseñadores proporcionan esqueletos, incluso relativamente específicos, ellos los comparten libremente. Nota también que voluntariamente no ocultamos los esqueletos de los sitios. Por defecto son fáciles de recuperar. Por ejemplo, si quiere saber cómo funcionan los esqueletos de los artículos de uZine, te basta que vayas a ver por http://www.uzine.net/article.html. Como es puro HTML, basta con observar el código fuente de otro sitio para aprender a hacer la misma cosa.

Para Spip, debieron escribir un lenguage propio, una sintaxis en particular, para lo que se refiere a las compaginaciones, los bucles. ¿Qué le dirías a un principiante que podría temerle este nuevo aprendizaje?

Que es el primer paso el que cuesta. Es verdad que al principio, todo no es evidente, ya que es necesario asimilar los principios de los bucles. Pero una vez que se comprendió (y eso no es brujería), hay una curva de progresión rápida e ilimitada (personalmente, descubro posibilidades y astucias regularmente).

Pasada esta primera etapa, comienza la verdadera. Al principio por pequeñas modificaciones, copiando finales de código aquí o allá, y luego desarrollando una estructura de personal para el sitio.

Y luego está la lista de correo de SPIP. Las cuestiones referentes a los bucles son las que ciertamente obtienen más respuestas: muy a menudo, varios usuarios proporcionan soluciones diferentes e intercambian trucos para obtener una solución más elegante. Es un aspecto bastante lúdico eso de intercambiarse bloques de código cuando se aprende ("y cómo obtiene este efecto?"...).

¿Piensan dar algo más de apoyo desde su sitio ;-)?

¡Eso es una porquería! :-). Encargarse de la redacción de la documentación, es una calamidad.

Sin embargo es una preocupación permanente: no se saca una nueva versión sin las adiciones de la documentación que van con ella. Para la versión 1.0, se retrasó la salida 3 meses, hasta que se pudo tener una documentación completa. Y, sí, hay siempre cosas que hacer sobre la documentación...

¿Tiene previsto promocionar SPIP en más idiomas?

Sí, esto está previsto. Pero antes, es necesario que terminar la versión 1.4. La versión de SPIP para la exportación (!),seguramente será la versión siguiente. Técnicamente, eso no debería ser monstruoso; en cambio, va a ser necesario traducir las documentaciones, y organizar las listas para responder a los usuarios extranjeros (el trabajo grande es más bien por este lado). ¿Nos darías una mano para la traducción al sueco?

¿Cuáles son las evoluciones que les quisiera aportar a Spip?

Cada uno tiene sus ideas, pero no hay plan global previsto. En efecto hay varios factores que influyen sobre el desarrollo:

 en primer lugar, la idea de origen, que se desarrolla según la lógica inicial; es muy importante, es a veces fuente de tensiones (habrá), pero la idea, es que SPIP no es un producto terminado, al contrario se desarrolla hacia una determinada coherencia. Antes de hacer cambios radicales, el objetivo contemplado es que el producto haga todo lo esperado de él, sin dañar a su propia lógica. Es el motor principal;

 las necesidades que aparecen sobre sitios que utilizan SPIP; es imprevisible al principio, pero eso desempeña un papel importante. Por ejemplo, recientemente vi cómo Samizdat modificaba SPIP para que se adapte a lo que hacían en Génova; y de golpe, la próxima versión integrará algunas funcionalidades vinculadas a eso;

 las posibilidades que aparecen a raíz de anteriores evoluciones. Sucede frecuentemente que al añadir una determinada funcionalidad, o al programar de nuevo una parte del funcionamiento, de golpe se descubre que se pueden insertar nuevas posibilidades sin complicarse demasiado. Por ejemplo, actualmente, Fil programa de nuevo el sistema de identificación para el acceso a la gestión del sitio, y eso debería abrirnos posibilidades imprevistas para el sitio público.

Entre las muy raras críticas que se les hacen, es una que se refiere a su desarrollo. Se dice al equipo de desarrollo de Spip es menos abierto que otros. ¿Te parece que esta observación está justificada?

¿ Y no es la misma crítica que se le hace al creador de phpNuke, que no es agradable, que es malévolo, que no se abre lo suficiente, y entonces se hacen forks absolutamente idénticos a Nuke?’ : -)

Dicho esto, hay efectivamente algunas características de SPIP que pueden causar esta clase de reacción:

 SPIP es un producto jóven. Como lo indiqué más arriba: queda mucho hasta por hacer en la lógica del producto. De golpe, es inevitablemente se tajante sobre algunos puntos, ya que a menudo se tiene una idea muy precisa de hacia dónde es que SPIP va a evolucionar, aunque eso no se aún en el producto actual.

 SPIP es muy diferente a los tipo Nuke. Ahora bien muchos desarrolladores llegaron en la lista de SPIP con ideas preconcebidas vinculadas a Nuke (por ejemplo, las primeras semanas, se hacía discusiones todos los días sobre porque no hay tal "módulo" en SPIP; mientras que los esqueletos permiten muchas cosas normalmente realizadas con los módulos en Nuke, y que la integración de funcionalidades externas en el lenguage de bucles no tienen nada de evidente - es más fácil inmediatamente cuando todo es predefinido en PHP). De ahí es inevitablemente algunas incomprensiones.

 La interfaz de gestión de SPIP se orienta con determinación hacia una metáfora de publicación, de flujo editorial. Ahora bien, por naturaleza, los informáticos que saben jugar con PHP/mySQL piensan las funcionalidades en término de interfaz básico de datos. Allí también, numerosas incomprensiones. (Para exagerar, diría que algunas funcionalidades requeridas parecían más concebidas para phpMyAdmin que para SPIP.)

 SPIP es usado por algunos usuarios sin ningún conocimiento técnico. Es algo en lo cual realmente se tiene enormemente cuidado, y que irrita algunos. El equilibrio entre el flexibilidad de funcionalidad y la intuición de la interfaz gráfica (en líneas generales: no se debería preguntar para que sirve tal botón). Naturalmente, los informáticos quieren un máximo de flexibilidad y funciones potentes, y al mismo tiempo no se quiere asustar a los refractarios a los manuales de 200 páginas :-)

Se dice que ya no saben exactamente lo que significa el acrónimo Spip ¿Es cierto? ; -)

¡Es una mentira desvergonzada! No se olvidó: nunca se lo supo. Por el momento, oficialmente, eso quiere decir "Sistema de Publicación para Internet" y la último P no se sabe lo que es. [2] Pero en el logotipo, todo eso se hacía demasiado largo.

Varios proyectos retomaron algunas de sus ideas, pienso a Glasnost, en ProjectX. ¿Que piensas?

¡Bien, estupendo! Tengo ansias de ver eso. Luego iremos para allá a mirar sus código y sus buenas ideas.

¿Te das una idea del número de sitios bajo Spip?

Lo que sé, es la lista de sitios que se apuntaron: http://www.spip.net/fr_article884.html

¿Te sorprenden los usuarios?

Sinceramente, no, no me sorprenden. La diversidad de los temas abordados, es el aspecto <> de la red, y por lo tanto no es sorprendente, es más bien simpático.

Y la diversidad de las estructuras que los utilizan (los particulares, las asociaciones, los Diarios, de las escuelas, de las administraciones, de los partidos políticos, de los sitios de campaña electoral, de las empresas...), eso no es tampoco muy asombroso. Contrariamente a lo que se nos repite (que se nos repite menos ahora, hago la observación), la Red no es un asunto de megatecnos ultradiplomados; los sitios carísimos realizados por grandes empresas SSII, ya no son lo más corriente. Para una amplia parte, los sitios siempre son realizados por el tipo que se interesa por la Red, que construye su sitio, y que propone encargarse de otros. De golpe, si conoce SPIP, será SPIP para la asociación, la escuela, el partido...

Lo que da sobre todo placer, es que hay muy muy pocos sitios bajo SPIP consagrados a SPIP [3]. Quiero decir que SPIP se utiliza para tratar temas que tienen corazón (temas de la "verdadera vida"). Me da la sensación de estar ayudando.

¿Para terminar, qué mirada tienen sobre la comunidad Nuke, y más generalmente sobre los otros CMS?

¡Sobre los otros CMS, excelente, estupendo que esté lleno, es una fiesta! Seriamente, es indispensable si no se quiere que nuestras pequeñas herramientas pasan a ser de terribles instrumentos normativos. Cuanto más productos diferentes haya, menos se verán obligados los usuarios a doblegarse a las especificidades de los programas informáticos; podrán elegir el producto que más le conviene a su necesidad, y no reducir sus necesidades para que puedan caber en el programa informático.

Para Nuke, de golpe, bien sí, estupendo bajo este aspecto. En cambio, no llego a explicarme porqué los 200 CMS tipo nuke-son todo idénticos. Tanto más rápido, orientado a objetos, o sabrá uno que, es ciertamente estupendo, pero finalmente la eso de hacer sitios invariantes, poco me gusta. De golpe, una multitud de sistemas que imponen la misma norma a los y las webmaster, es una bonita energía derrochada... (esto va a hacerme enojar, crees?).