SinDominio: Un modelo de administración diferente

Joseba Torre y Miquel Vidal ^{∗}

   joseba@sindominio.net, miquel@sindominio.net

Otoño del 2000

Esta ponencia forma parte del III Congreso Hispalinux^{1} virtual, celebrado en Noviembre de 2000. Puedes participar en él en la sección de eventos de

BarraPunto^{2}

Resumen

SinDominio (http://www.sindominio.net) es un sitio de Internet sin ánimo de lucro, creado para dar visibilidad a colectivos sociales, centros sociales okupados, iniciativas a favor de la autonomía de lo social, proyectos antagonistas a la mercantilización de la red, a favor del conocimiento compartido y del software libre, etc. Iniciativas todas ellas que, generalmente por su escasez de recursos o por su carácter minoritario, suelen estar abocados a la dispersión total o a depender de servidores institucionales o gratuitos.

La gran diversidad y movilidad de contenidos de SinDominio nos hubiese obligado, de seguir los caminos habituales para la administración de un isp, a asalariar a alguien para que se hiciese responsable a tiempo completo del sitio. En su lugar, decidimos utilizar una política de administración colectiva y descentralizada, como forma de plasmar nuestro compromiso con la libre circulación del conocimiento.

De por qué elegimos este último método, y cómo lo organizamos, en fin, de una experiencia de administración colectiva y autogestionada basada íntegramente en software libre, es de lo que trata esta ponencia.

∗\begin{matrix}c \\ ◯ \end{matrix}2000 Joseba Torre y Miquel Vidal. Se otorga permiso para copiar, distribuir y/o modificar este documento bajo los términos de la Licencia de Documentación Libre GNU, Versión 1.1 o cualquier otra versión posterior publicada por la Free Software Foundation. Se considerará como Secciones Invariantes todo el documento, no habiendo Textos de Portada ni Textos de Contra Portada. Puede consultar una copia de la licencia en:

http://www.gnu.org/copyleft/fdl.html

1http://congreso.hispalinux.es 2http://barrapunto.com/eventos

1 ¿Por qué un modelo de administración diferente?

SinDominio, conglomerado de gentes y colectivos muy diversos, nace con una idea clara: que no es posible separar lo técnico de lo político y por tanto que no queremos reproducir la estructura clásica entre administradores/as y administrad@s. Nuestro deseo es conseguir que sólo haya participantes que colaboren en un plano de igualdad potencial; de hecho, la única diferencia entre quienes participamos son los conocimientos técnicos, y es un objetivo prioritario que eso no se convierta en un obstáculo insalvable a la hora de participar y decidir. También son ideas fundacionales de SinDominio el darle tanta importancia a los contenidos como al proceso colectivo que los produzca; que la toma de decisiones sea horizontal, y a no solo dar servicios sino capacitar técnicamente a los participantes de modo que vayan adquiriendo responsabilidades en el ámbito de la administración, empezando por las tareas que menos conocimientos requieren.

Desde el principio, teníamos claro que, al igual que no lo hacemos en nuestro quehacer diario, ni podíamos ni queríamos replicar en SinDominio los modelos que se usan en la mayoría de espacios de Internet: no queríamos que nadie tuviese más poder, ni en la toma de decisiones ni en las labores de administración. Lo primero lo solucionamos por el método habitual, constituyéndonos en asamblea, con la particularidad de que esta se lleva a cabo vía lista de correo; lo segundo, en cambio, nos obligó a plantearnos soluciones nuevas para un problema con el que ningun@ nos habíamos enfrentado nunca: la creación y administración, de forma remota y distribuida, de un espacio rico, cambiante, y bastante heterogéneo. Además, la intención de superar las diferencias de conocimientos nos llevó a generar textos explicativos donde, de la forma más concreta que podemos, documentamos cómo realizar algunas de las tareas para administrar el servidor de SinDominio.

Pero no solo procuramos no reproducir modelos de organización que cuestionamos, sino que tratamos sobre todo de crear formas de relación y de cooperación diferentes, no basadas en el mercado ni en el mando, ni en la propiedad ni en el control, sino en ideas de libertad y comunidad, en la inteligencia colectiva y en el saber compartido. Y apostar por su viabilidad técnica y política. Sin esas premisas, no se entenderá la centralidad que para un proyecto como SinDominio tiene el software libre.

2 Pasos previos a la administración

2.1 Lo que teníamos que administrar

El primer paso para elegir un modelo es saber a qué situación tiene que responder: en la parte técnica, SinDominio dispone de un pc con Debian gnu/Linux, conectado a la red interna de nuestro proveedor de conexión, con salida a Internet vía frame relay. No dudamos en la elección de gnu/Linux, y en particular de Debian, puesto que nos ofrecía en lo técnico la estabilidad y versatilidad que necesitábamos, junto con la apuesta no mercantilista del proyecto Debian por la difusión del software libre que compartimos plenamente. Tanto el equipo como la conexión se sostienen con aportaciones voluntarias de personas y colectivos, quedando claro que se paga para apoyar un recurso colectivo, pero no un servicio: pagar no da más derechos que no pagar.

Los servicios de los que queríamos disponer fueron:

Correo electrónico: Como servidor de correo, elegimos Postfix, puesto que es libre, es relativamente sencillo de configurar, y a la vez muy versátil, actualizado y potente. Además, contamos con la ayuda de Wietse Venema, su creador, y de Bennet Todd, autor de un pop-before-smtp para Postfix, a la hora de cerrar el relay a los spammers (lo cual no era sencillo pues SinDominio no da conectividad a sus usuarios, por lo que no es fácil de antemano distinguir un relay legítimo de un spammer).

Web: Para esto no había duda, y el clásico Apache, con servidor seguro incluido, se sigue comportando de manera admirable.

FTP: Sobre esto hubo más discusión, sobre todo porque cuando arrancamos cada día se descubrían nuevos problemas de seguridad en los servidores clásicos, y al final elegimos Proftpd: es sencillo de configurar, versátil, y en principio, parecía inmune a muchos de los problemas de seguridad del clásico Wu-Ftpd. Desgraciadamente, con el tiempo han aparecido también problemas de seguridad con Proftpd, y ahora mismo estamos pensando si migrar al servidor de Openbsd.

Listas de correo: También sobre este tema hubo cierta discusión: el popular Majordomo frente a SmartList; al final, este último fue la elección, por su licencia libre y por estar basado en el conocidísimo Procmail. Con el paso del tiempo hemos comprobado que la elección fue correcta, y ello pese a que aún no hayamos encontrado una interfaz web para la gestión de las listas, si bien es cierto que vía correo-e se hace sin problema.

Correo vía web: Tras probar con Webmail, lo abandonamos, sobre todo por necesitar el jdk —que no es libre— y por su excesivo consumo de recursos, a favor del Twig, que es 100% libre, basado en php, altamente configurable, y no consume apenas recursos. Conseguimos enlazarlo con Postgresql en lugar de Mysql, que en aquel momento no era libre, si bien era la opción probada y recomendada por los desarrolladores de Twig.

Noticias vía web: Uno de los primeros proyectos que pusimos en marcha fue la acp (http://acp.sindominio.net), para lo cual necesitábamos una herramienta que nos permitiese publicar en web noticias de forma sencilla y horizontal, sin mediaciones, así como permitir búsquedas por temas, por días… Las primeras pruebas las hicimos partiendo del software de Slashdot y la traducción que ya habían hecho en BarraPunto. Le encontramos un problema: Slashdot, propietaria de los derechos de dicho software, obligaba a incluir su logo y un enlace a su página, lo que, no siendo extremadamente grave, no nos gustaba (por suerte, hoy ya no imponen esa restricción y lo han liberado). Además el código que dejaban disponible era una versión antigua y descuidada, de complicada implementación. Tras un tiempo buscando alternativas, encontramos Squishdot, un weblog que corre sobre Zope, con el que estamos funcionando desde entonces.

IRC: SinDominio cuenta con su propio servidor de irc, conectado con otros proyectos de carácter similar, como el canadiense tao, para discutir, coordinarnos y apoyarnos mutuamente. Los servidores de la red SinDominio-tao son ircu, el servidor de Undernet.

2.2 Lo que exigíamos al modelo de administración

Otro problema a considerar era qué características debía reunir el modelo de administración. Esto era importante, puesto que una administración demasiado jerarquizada, además de ser contraria a nuestra forma de pensar, limitaría en exceso las posibilidades de participar de la gente, algo que queríamos evitar a toda costa. Por contra, una administración abierta pero poco pensada podía llevarnos a tener un sitio desorganizado y difícilmente administrable, además de posiblemente inseguro.

Por tanto, el modelo debía permitir que mucha gente participase en la administración, cada cual desde un espacio diferente y en la medida de sus posibilidades, pero manteniendo una coordinación y un “protocolo”.

3 El modelo de administración de SinDominio

3.1 Los accesos

Esta era la primera cuestión: dado que nadie tiene acceso físico a la máquina ¿cómo nos conectamos (de forma segura) y trabajamos en ella? La respuesta a esta pregunta era sencilla: ssh. Cerramos el puerto telnet, instalamos un servidor ssh (en aquel momento la única opción para gnu/Linux era no-libre, pero gracias al port del Openssh ya no existe ese problema), y ya podíamos trabajar. Posteriormente abrimos también un puerto telnet-ssl, para no quedarnos sin acceso a la máquina en el hipotético caso de que hubiese algún problema con el servidor sshd.

Lo siguiente era ¿quién tiene acceso shell? Muchas de las personas y colectivos que participan en SinDominio no tienen conocimientos de gnu/Linux, con lo que darles una shell no añadía ninguna utilidad, y ofrecía una posible vulnerabilidad al sistema si toda cuenta de correo tenía shell. Así que la decisión fue sencilla: cuando se da de alta algún nuevo participante no se le da shell, y si quiere tenerla no tiene más que pedirla. Quien no sepa qué es eso, no la va a necesitar, y quien la quiera va a saber qué es.

3.2 La cuenta de root

Otro problema obvio: ¿quién (o quiénes) tienen la contraseña de root? ¿cómo se accede a la cuenta de root?

La respuesta tampoco nos llevó demasiado tiempo: en un primer momento, había 4 personas con conocimientos y experiencia, con lo que esas 4 personas tienen la contraseña de root, cuenta a la que sólo se puede acceder con su, una vez dentro de la máquina, en un canal cifrado e identificado como usuario normal. Además, que fueran varias personas nos permitía mejorar la velocidad de respuesta caso de que su intervención fuese necesaria, liberando a esas personas de una disponibilidad a tiempo completo que en la práctica era inviable.

Por último, el hecho de que una de esas 4 personas viva cerca de donde está alojado el ordenador, nos facilita la solución de problemas sí por alguna circunstancia falla el acceso remoto o no se puede resolver por esa vía (problemas de hardware, DoS, etc.) de forma más o menos rápida.

Para coordinarnos, simplemente creamos un alias de la dirección de correo de root hacia las de los roots, y solucionado.

3.3 Los servicios

Hasta aquí, en realidad el método de administración no se diferencia demasiado del de cualquier sitio “compartido”. Esto es debido, en realidad, a que intentamos, en la medida de lo posible, que la configuración de servicios no necesite la participación de la cuenta root más que cuando sea imprescindible, dando sólo los permisos oportunos a cuentas concretas. Ahora veremos los servicios “descentrados” y cómo los gestionamos.

3.3.1 Las altas

El proceso para darse de alta en SinDominio es el siguiente: la persona o colectivo que desee incorporarse lo solicita por correo a una lista creada al efecto, explicando quién es y por qué se quiere incorpora al proyecto (sd@sindominio.net); ese correo es recibido por un grupo de gente, que se encarga de la parte social de la administración: son quienes mantienen el contacto con esa persona/colectivo, quienes presentan la solicitud a la asamblea, y quienes si se ha aceptado trasmiten esto a quienes generan la nueva cuenta. A su vez, al ser la cuenta pública de SinDominio, son quienes filtran y distribuyen las consultas, dudas, observaciones, etc. a la persona o personas adecuadas, encargadas del servicio en cuestión. Cualquiera que haya administrado un sistema de tamaño medio sabrá que esa parte “social” es fundamental para la buena marcha del sitio, con lo que, pese a no requerir conocimientos técnicos, lo incluimos en la parte de administración. Este grupo lo componen actualmente 8 personas, aunque el número va cambiando.

Después de esto, si el alta ha sido aceptada, se pasa el aviso a un segundo grupo, que se encarga de dar el alta, asignar una contraseña y enviársela a su destinatari@ (siempre que es posible, cifrada con GnuPG). Este grupo tiene permisos para dar las altas, así como de cambiar contraseñas —excepto la de root—, gracias a sudo, y actualmente está formado por 2 personas. Todos los usuarios pueden después cambiar su contraseña vía web-ssl las veces que lo deseen.

3.3.2 Mantenimiento de la web

Desde el principio, vimos que el mantenimiento de la web “corporativa” iba a llevarnos bastante trabajo, por lo que rápidamente creamos un equipo de webmasters, con permisos de escritura en todo el árbol /var/www, y coordinados a través de una nueva lista de correo. Al principio se propuso una división de acuerdo a cuatro grandes áreas técnicas, para que cada cual escogiese la que quisiese: diseño, elaboración de contenidos, programación web y administración de los servidores web (Apache y Zope).

Tal división funcional no ha acabado de cuajar y la práctica ha dado lugar a otra estructuración basada mas en proyectos y afinidades que en áreas técnicas, que a grandes rasgos queda así:

La web corporativa: Este grupo es el heredero del grupo de webmasters original, y se encarga de mantener, tanto a nivel estético como de contenidos, las páginas generales, así como de proyectar las modificaciones que luego presentarán a la asamblea. También tienen permisos, caso de que se requieran, para arrancar o parar el Apache, de nuevo vía sudo. Este grupo está formado por 14 personas.

Las páginas de ayuda: Aquí (http://www.sindominio.net/ayuda) es

donde almacenamos los distintos manuales que vamos generando o recopilando, para que estén disponibles para todo el mundo. Este espacio tiene mucha importancia, pues permite una transmisión efectiva de la experiencia de los administradores veteranos hacia la gente que se va incorporando nueva. Es también una pequeña aportación a la comunidad, pues bastantes de los mini-manuales tienen validez no solo para SinDominio, sino para otros sistemas basados en gnu/Linux. Ahora mismo esas ayudas son mantenidas por una persona, que a veces recibe o solicita aportaciones del resto.

La ACP: Como ya hemos comentado antes, la Agencia en Construcción Permanente (http://acp.sindominio.net) es un espacio de noticias vía web que se mantiene en SinDominio. Se modificó bastante la interfaz original de squishdot, se tradujo íntegramente y se añadieron algunas funcionalidades modificando el código python. Su administración cotidiana representa bastante trabajo pues, junto a su mejora estética y funcional, la administración de la acp conlleva la revisión de las noticias que se publican, para evitar duplicados, spam, que se caiga en descalificaciones graves, o que se publiquen noticias fuera del tema (la publicación de noticias en la acp es totalmente libre desde el punto de vista técnico —no hay editores ni ninguna figura similar— pero la asamblea de SinDominio se reserva el derecho de retirar las que considere que no responden al espíritu de la propia acp). Todo el trabajo administrativo es llevado a cabo vía web gracias a las herramientas que el propio Zope nos proporciona. Esta tarea la llevan a cabo 9 personas, más otro grupo de gente que ha colaborado con los desarrollos, o ha diseñado el aspecto visual, los gráficos y cabeceras.

GUGS: Hace unos meses, decidimos crear el “Grupo de Usuari@s gnu de SinDominio” con el doble objetivo de facilitar a la gente del entorno de SinDominio el salto a gnu/Linux y de difundir el aspecto político y ético del software libre. Dispone de un subdominio con una web (http://gugs.sindominio.net), lista de correo y foro de noticias-discusión-ayuda, basado en el trabajo previo para la acp, y administrado remotamente de la misma forma que esta. gugs pretende ser un punto de enganche entre la comunidad del software libre y las gentes y colectivos de la izquierda antagonista.

La BiblioWeb: Es otro proyecto en fase avanzada de desarrollo. Se trata de una biblioteca virtual que permitirá documentar bibliográficamente documentos que ya estén en la red o que se deseen publicar en web. Los documentalistas no necesitarán tener ningún conocimiento previo de base de datos ni de html: rellenarán una ficha describiendo el documento —visualizable en ventana adjunta— y, automáticamente, lo darán de alta remotamente en la base de datos del servidor. Inmediatamente estará accesible por web. Por tanto, la biblioteca se irá enriqueciendo desde proyectos diversos vía web, sin necesidad de que nadie lo coordine. Un interfaz web de consulta permitirá vía cgi cruzar todo tipo de búsquedas y extraer las fichas de la base de datos a cualquier visitante. La herramienta, construida desde cero por Sin-Dominio, contará con un interfaz de introducción de datos para los documentalistas escrito en Perl/Tk (con versión tanto para gnu/Linux como para MS-Windows), la base de datos construida en postgresql y los módulos y scripts en perl necesarios para manejar las altas y las consultas. Cuatro personas trabajan en este proyecto.

Nuestro particular “contrato social” consiste en que tanto la BiblioWeb como la acp o cualquier otro desarrollo que SinDominio pueda emprender en el futuro se basa en software libre, con lo cual dichas herramientas quedarán libremente disponibles para otros proyectos.

3.3.3 Los logs

Una de las tareas más desagradables en la administración de un sistema abierto es la revisión de los logs del sistema, en busca de errores, anomalías o ataques. En SinDominio esta tarea es menos tediosa, puesto que es asumida por un grupo de gente (esta vez sí, con conocimientos técnicos), lo que permite que ninguna persona tenga que estar revisándolos constantemente.

3.3.4 Los servicios generales

La configuración de los servicios generales se asumió en principio por quienes teníamos privilegios de root. Tras la congelación de la versión 2.2 de Debian, se realizó remotamente una actualización completa del sistema, con la participación simultánea de todos los roots vía ytalk para tomar decisiones ante las preguntas de configuración y el reinicio de servicios (cualquier error nos podría haber dejado sin acceso al sistema). No obstante, la mayor parte de las configuraciones siguen como al principio, excepto pequeñas modificaciones (creación de nuevas entradas en el dns, actualización de paquetes y de la versión del kernel, creación de nuevas listas, y otras modificaciones menores), que son llevadas a cabo por el equipo de roots, puesto que tampoco generan excesivo trabajo y algo tienen que hacer ellos :-)

Una excepción a esto fue el cierre del relay, lo que obligó a bastante trabajo durante unas dos semanas, y que fue llevado a cabo por un grupo reducido de personas, mientras el resto intentábamos buscar soluciones y/o información por la red; algunos otros ejemplos ha sido el enlazado de Twig con Postgresql —ahora se puede hacer sin más que instalar el paquete Debian, cuyo mantenedor oficial es uno de los roots de SinDominio—, y la puesta en funcionamiento de la acp. Precisamente, esto es parte del espíritu del modelo: descargar a quienes más conocimientos técnicos tienen de tareas que no los necesitan, para así no cargarles mucho de trabajo y aprovechar mejor los recursos.

Por último, cuando se plantea la puesta en funcionamiento de un nuevo servicio, en muchas ocasiones alguien se presenta voluntario para ponerlo en marcha, lo instala localmente, aprende a configurarlo, lo prueba, y cuando todo esta hecho avisa a algún root para que lo ponga en su estado real (ejemplos de esto han sido el servicio irc o la herramienta analog de estadísticas web).

3.3.5 Las listas de correo

Otro de las tareas tediosas de administrar son las listas de correo, una vez que ya están en funcionamiento: dar altas y bajas, revisar las direcciones suscritas, errores de suscripción, mensajes rebotados o no admitidos… Esta tarea se puede descentralizar de forma sencilla con Smartlist, puesto que se puede hacer con comandos vía mail. Actualmente, ninguna de las listas de correo de SinDominio es administrada por un root.

3.4 El desarrollo de aplicaciones o soluciones a medida

En muchos casos, una de las tareas que más tiempo lleva (y eso que no es puramente una tarea de administración) es la adaptación de aplicaciones a la situación real con la que te encuentras, y SinDominio no es una excepción.

Cuando nos encontramos con la necesidad o conveniencia de desarrollar algo, el método que seguimos es sencillo: se avisa en la lista de administración (que es en la que nos incluimos quienes tenemos conocimientos técnicos, o quienes más interés tienen en adquirirlos) de cuál es el proyecto, y la gente que está interesada se apunta; una vez que el número de gente es suficiente, el proyecto se pone en marcha, siguiendo los métodos que el propio grupo elija (forma de coordinación, herramientas a usar, plazos si son necesarios, conocimientos a adquirir si todavía no se tienen…).

4 Algunos problemas

SinDominio pretende ser, entre otras cosas, un espacio de construcción colectiva, donde se den las condiciones básicas para que se genere cooperación, circulación de conocimiento, lineas nuevas de creación e investigación.

Es en este punto donde el modelo hasta el momento ha sido más débil. Han surgido pocas iniciativas de trabajo cooperativo, poco sólidas y poco duraderas. Normalmente la persona que ha promovido una idea la ha dejado aparcada, bien porque no estaba dispuesta a encargarse de ella seriamente, bien porque los mecanismos de organización de equipos no han sido aún bien desarrollados en nuestro proyecto.

Tanto el modelo bazar como el modelo catedral y sus variantes no han alcanzado en SinDominio un grado aceptable de realización. La dinámica que más se ha observado en las diferentes listas donde se han propuesto ideas es la siguiente: 1) Alguien propone un proyecto. 2) Mucha gente lo apoya y se ofrece a ayudar. 3) A veces se habla de ello unos días. 4) Nadie se propone como coordinador del proyecto. 5) Nadie se compromete a encargarse de tareas concretas. 6) No se toma una sola medida para formar un grupo y no hay asignación o autoasignación de trabajos. 6) Vaporware.

¿Por qué ocurre esto? La respuesta no acaba de estar clara. Dejando aparte las ideas en las que no se involucraba mínimamente quien las proponía, en varias ocasiones una propuesta ha sido muy apoyada y mucha gente se ha ofrecido a cooperar, es decir, existía la idea y gente dispuesta a llevarla a cabo. Por otro lado, los individuos y colectivos que forman Sin-Dominio están familiarizados con proyectos donde se requiere esfuerzo y cooperación. Por lo tanto sería difícil pensar que las cosas no se hacen por falta de voluntad, dejadez, nihilismo, etc.

Es muy probable que estemos ante varias carencias técnico-culturales. La principal de todas es la incapacidad que hasta ahora hemos tenido de, una vez formado un grupo, articularlo y dinamizarlo. Esto puede ser debido a que la cultura de lo presencial nos domina todavía, es más fácil esconderse en el mundo virtual, a no ser que tengas cultura virtual y sientas la mirada de tus compañeros. Del mismo modo ha ocurrido con los impulsores de ideas, el grado de implicación ha sido bajo, probablemente porque no se ha asumido que en esta cultura de la telemática antagonista, en la que queremos estar, decir algo y hacer algo es lo mismo, y lo demás es ruido, es decir, quien propone se implica ya que el medio virtual es mucho más propenso, debido a la distancia y al anonimato, a la opinión vacía.

Por otras parte, hemos podido verificar algunos de los límites conocidos del modelo bazar, que parece encontrar serias dificultades para producir cooperación cuando:

• se empieza desde cero un proyecto (es decir, ha de haber algo hecho, pensado o perfilado antes de proponerlo).

• no hay coordinador/a o varios que asuman esa función.

• hay grupos amplios demasiado heterogéneos en cuanto a conocimientos y/o intereses.

Por último, pagamos un precio por la dinámica asamblearia que queremos para SinDominio. En el mundo presencial este precio es más pequeño porque el hecho de que haya gente en un lugar determinado fuerza al final la toma de decisiones, el “opinódromo” no aplasta las ganas de hacer cosas. En el mundo-medio virtual la dinámica asamblearia debería probablemente ser más contenida, se debería hacer el esfuerzo de seguir las líneas que han marcado la cultura hacker y la comunidad del software libre: hacer más que decir.

5 Conclusiones

Ya sea, como es en nuestro caso, por convicciones políticas, ya sea por cuestiones de eficacia, gnu/Linux nos proporciona herramientas y formas de trabajar que permiten alejarnos casi todo lo que queramos del modelo tradicional de administración jerárquica y centralizada. Si bien es cierto, que la puesta en práctica de un modelo diferente ha demostrado algunas carencias a la hora de que cuajen iniciativas de trabajo cooperativo, no deberían convertirse en obstáculos insalvables para proyectos cuya supervivencia no depende de la eficacia o del beneficio económico, sino que su objetivo es que los usuarios de ordenadores puedan cooperar libremente. En ese sentido, la apuesta mantiene intacta su potencialidad en cuanto a optimización del esfuerzo de quienes participan, mínima inversión económica (sobre todo comparado con otros medios de comunicación), sentimiento de implicación, potenciación de la participación, circulación del saber, acercamiento de lo técnico a gente sin grandes conocimientos… El modelo descrito parece especialmente adecuado para aquellas iniciativas en las que el dinero no es la motivación y no están remuneradas —lo que todavía es frecuente en Internet—, y en las que no se puede contar con la dedicación a tiempo completo de nadie.