 Debian, la Debian Policy. Y algunas guías específicas a la aplicación que ustedes desenpaquetar. Por ejemplo, si la aplicación está hecha en Python, hay una guía de cómo se desenpaquetar cosas en Python. Y así por el estilo. Pues adoptando un paquete, utilizando las herramientas que son de uso común en Debian. Por ejemplo, de uso común en Debian o de uso común en el ciclo de desarrollo de Debian, como The Helper, Peabilder, Elida, etcétera, etcétera, etcétera. Pero existen otras formas de colaborar también y algunas personas las han adoptado y las han internalizado a tal punto que, bueno, este es un poco lo que estamos hablando ahora, las han adoptado a tal punto que publicitan el proyecto de cualquier forma. Allí tienen una, ¿cierto? Aquí tienen otra. Aquí tienen otra. Y aquí tienen una que es de mis preferidas, ¿OK? Esa es una ristra de botella y de latas vacías de cerveza después de unas noches de trabajo. Y, bueno, ahí está un poco la forma en que se podría colaborar también. Y, bueno, este proyecto va rápido, lento. Va a su ritmo. Por ejemplo, pasar de una versión a otra en algunos casos es rápido, en otros no lo es. Por eso está una persona allí acostada al ritmo, ¿OK? Por ejemplo, pasar de Woody a Sarge llevó del 19 de julio, perdón, allí me equivoqué, del 19 de julio del 2002, no es 2009, disculpeme, al 6 de junio del 2005, ¿OK? Pasar de una versión a otra. Eso es lento o es rápido. Lento, rápido, son términos totalmente relativos, ¿OK? Son términos totalmente relativos. Por eso, aquí hay un ritmo de trabajo. De hecho, uno de los lemas de uno de los DPLs recién electos fue ese. Oye, tratar de ver cómo hacemos para que esto camine. ¿Por qué, a veces, existen esos cuello de botella para ir de una versión a otra? ¿Las herramientas que nos funcionan? ¿El engranaje social que está allí detrás que nos está funcionando bien? ¿Apatía? Pues no lo sabemos. Quizás una de las formas de ayudar también podría ser encontrar dónde están esos cuello de botella y ver cómo ayudamos a aligerarlo. Pero bueno, rápido o lento, yo creo que ni rápido ni lento. De bien va al ritmo que dicta la comunidad que está allí detrás, ¿OK? Pero igual tengo un aparato nuevo. Claro, ahí hablamos del tema del Kernel, claro. Pueden necesitar versiones más nuevas del Kernel para la detección de los componentes. Bueno, yo ese es el mayor inconveniente que veo, de que tarde mucho, bueno, tardará lo que tenga que tardar. Pero sí es cierto que dificultad de cara a para todos los nuevos, componentes nuevos. Fíjense que, entonces, allí hay un punto que lo vamos a ver ahora que es muy, muy, muy importante y es que debian es un desarrollo totalmente comunitario. Al ser un desarrollo comunitario, está sostenido por el esfuerzo voluntario de los que trabajan o militan o están inmersos en él, ¿OK? Eso es diferente totalmente a otros proyectos en los cuales existe una retribución por parte de una empresa para que existan unos ciclos de desarrollo puntuales con unos tiempos puntuales para entregar productos. Aquí, al ser un proyecto colaborativo, quizás, lo que decía, ¿cuál es tu nombre? Lo que decía José Luis, este es que, pues nada, me funcionó y me funcionó, pues. No tengo quizás capacidad para comprarme otro equipo nuevo o otra cuestión, me funciona y me funciona, muy bien. De hecho, fíjense que hay versiones de Debian. Yo trabajé en algún momento en un sitio y dejé instalado dos máquinas con Woody y esas máquinas todavía están trabajando allí sin ningún problema. O sea, están trabajando, o sea, ¿por qué? Porque funcionan. No se ha incorporado nada nuevo en la línea de producción y funcionan perfectamente. Es necesario pasarle una nueva versión. Lo principal ahí sería preguntarse para qué. No porque, o sea, bueno, sí, en este caso, no hay seguridad, pero allí está una red con tres equipos, no hay conectividad externa, nada. O sea, funcionan allí. Pero esa parte para mí es fundamental, porque permite darle una respuesta al usuario que siempre hay una. Siempre dicen que por qué se tarda tanto de una versión a otra, pues yo creo que hay un ritmo de trabajo. El ritmo algunas veces va más lento, otras veces más rápido, pero es un ritmo. Yo ahí quería añadir un tema. En el período de la producción de Sarge, el mundo de informática un poco se revolucionó. O sea, apareció muchas cosas de USB. Aparecieron el Serialata. Aparecieron en Linux, pasamos al 2.6. Pasamos al Udev para toda la auto tal. Es decir, un poco debían fue detrás porque había muchos cambios que quizás quiso asimilar a la vez. El error habría sido quizás el no haber hecho una publicación intermedia de menor calidad, pero que hubiese sido usada para sincronizarnos. Cosas que Ubuntu, ahí sí que llegó muy bien. Ahí empezó Ubuntu. Hizo Ubuntu se basa en menos paquetes que mantiene. Devía mantener un montón de paquetes para muchas plataformas. Y quizás fue un intento. Para mí, Sarge no es una buena release. Luego, Edge ya mejoró muchas cosas. Pero son cosas que, si la informática va avanzando, pues tenemos que adaptarnos. Y es tan rico que nos cueste. Y fíjate que también está el hecho de que la informática no es algo que está aislado del entorno. O sea, ahí toda una serie de condicionantes alrededor. La industria, el factor humano, etcétera, etcétera. Por eso, quizás yo creo que, como vuelvo a repetir allí, hay un ritmo de desarrollo. Ese ritmo incluso está aceptado por la comunidad. Y eso es algo importante, lo que tú dices. Es algo importante a reconocer. La comunidad secto que fuese así no hubo otras propuestas mejores, pues nada. Fue así. Y eso es lo que yo llamo el ritmo propio. Después de todo esto no se podría preguntar, bueno, esto es perfecto. Y ahí está una foto de Luciano. Y ya van a ver por qué se dice si esto es perfecto. Pues no. Luciano consiguió una de los errores que hizo que no recuerdo si fue al proyecto total o fue a SSH en específico, a SSH. Si el problema ahí fue sobre SSH y sobre cualquier cosa que estuviera ligada sobre SSH. Sí, Luciano descubrió un error que le valió a SSH ese premio nada envidiable, que es otorgado un poco por la comunidad de seguridad informática al proyecto que tenga el peor error de seguridad en el año. Y es un pony, púrpura, que se entrega en una conferencia anual. Debian se hizo a credor SSH en este caso por tener un error de seguridad que fue reportado por Luciano. Ahí está la dirección específica. El nombre del reporte es el 1571 Guion 1. El reporte fue para Open SSL. Específicamente fue que existen números aleatorios predecibles. Y fue porque alguien comentó una línea que no debía comentar. Sí, número finito. 32,718 posibilidades que podían perfectamente ser computadas y conseguirse cualquiera de esos números. Pero bueno, se consiguió el error. Creo que allí lo más importante a tomar en cuenta y a resaltar es que en el momento de conseguirse el error inmediatamente fue reportado y se tomaron todas las acciones posibles para minimizar ese error y simplemente solucionarlo. Eso es un proyecto de un proyecto abierto. En una compañía, por ejemplo, un error de SN, nunca hubiese una compañía que se dedicase al sector de informática o algo, nunca hubiese salido a la luz pública. Pero aquí se trató, se ventiló e inclusive hubo un premio, como dije, nada envidiable. Pero está allí y hay que saber que existe. Un poco los agradecimientos que están allí son a personas que, ayer, sobre todo específicamente, conversando, conseguí una serie de informaciones que me fueron muy útil para esta charla. Por ejemplo, está el propio Luciano. Andrew, estaba por allí, se fue. Francisco, un poco también con esos números que me facilitó a última hora y el propio Alejandro también conversando un poco. Traía mucho de estos datos anecdóticos que ustedes vieron allí. Hay una última acá que son preguntas. Hablen o pregúntenle a Google. Sería muy interesante que fuese, como les dije, un diálogo porque eso nos enriquece a todo. Para las preguntas, de igual forma, aquí están una serie de créditos, sobre todo para las fotografías. Hay muchas fotografías de la galería del Desconf, están algunas de las, como se llama, de los manuales, algunas fotografías de Flickr que aún no me queda claro si son de dominio público. No recuerdo ahora específicamente. Ande están los números que hablaba Francisco Nibresov. Las estadísticas de las listas las pueden conseguir actualizadas en listdebian.org. Estats. Eso lo llegué a esa raíz del blog de Ana. Y, ¿qué otra? Ah, bueno, y la lista un poco de las listas de Debian, que está en mailing list. De todas maneras, esto lo voy a colocar público en la siguiente dirección. Lo voy a colocar en la siguiente dirección, allá abajo está, E1TH0R, Gullmer ORGBE. Voy a colocar esta charla junto con las mejoras que ustedes me acaban de decir. Para que pueda ser bajada por todos. E1TH0R, Gullmer ORGBE, Grupo Usuario Linus de Mérida, punto ORG, punto B. Habigo en una ciudad llamada Mérida, enclavada en un sitio totalmente diferente al clima de acá. Estamos enclavados en una sierra que tiene nieve peréngles. Por lo tanto, es totalmente diferente a esto. No quería finalizar sin mostrarle estas dos láminas. Que conversa un poco con Gullmer, porque nos ayuda a declarar un poco el panorama de por qué se ayuda y por qué se colabora y por qué se trabaja en Debian, siendo que es un proyecto comunitario. Les explico un poco lo que está allí. Un poco el desarrollo comunitario, según lo hemos visto nosotros en algunos estudios que hemos hecho. Yo trabajo en un centro de investigaciones en tecnologías libres. Es un centro que fue creado en Venezuela para investigar cómo es el cuento de las tecnologías libres. Un poco nosotros hemos conseguido que los desarrollos comunitarios se basan en grupos de individuos con eso llamado prácticas virtuosas, que a primera vista no les diría nada. Pero el término prácticas virtuosas tiene que ver con el reconocimiento mutuo de potencialidades del otro que específicamente no tienen que ver con condicionantes académicos. Es decir, no importa si tú eres doctoro, si tú eres licenciado, si tú eres ingeniero, pero si tú conoces mucho, yo reconozco que tú conoces mucho. Dentro de los sistemas tradicionales de valoración, eso no está muy bien entendido. Incluso en mi país, siendo que yo trabajo en un centro nacional, en un centro del gobierno, incluso en mi país tenemos problemas con esto, a pesar de que nosotros hemos hecho estudios de este tipo, siempre me río mucho cuando en los consejos directivos, porque a pesar de que nosotros tenemos elementos como este cuando sacamos un concurso público, lo primero que ponemos es que tenga título de una universidad reconocida. Yo le digo, bueno, pero el tema de las prácticas virtuosas entonces allí no viene muy bien, porque si estamos diciendo que vamos a reconocer potencialidades en el otro, pedirle un título, ya estamos un poco validando el discurso. Pero lo importante es que existe el término. Ahora, fíjense que ese grupo de individuos están unidos por un fin común, y eso es fundamental. Las comunidades de desarrollo se basan en perseguir un fin común. Si el fin no es común, la comunidad en algún momento u otro simplemente se va a disgregar o va a desaparecer. Bajo modelos no tradicionales de desarrollo, es decir, muchas veces, todos estos modelos académicos de desarrollo que uno ve no entran dentro de los desarrollos comunitarios. Y desde modelos socioproductivos enfocados en servicio, esto lo que tiene que ver es que como uno de los elementos que existen en el desarrollo comunitario es la liberación del código, pues difícilmente podrá haber un modelo tradicional allí que se base en licenciar un binario. En este caso existen, son servicios. Por ejemplo, los más conocidos que yo he visto así y que me parecen excelentes está el caso de la gente de doqueos, que es una herramienta de learning que dice, bueno, nosotros inclusive le ayudamos a preparar los cursos y ese preparar los cursos tiene su costo. Está la herramienta de la gente de G4, que ahora recientemente liberaron Function 4 por eso mismo. Están Launchpad, lo acaban de liberar, pero detrás del Launchpad que existe un modelo comercial, no lo sé. Por ejemplo, la gente de Function 4 dicen, ¿ok? Sí. Creo que la gente de Launchpad tiene una versión comercial. Sí, no lo sé. Pero recientemente liberaron la. En el caso de la gente de G4, si tienen un modelo enfocado a la instalación del sistema, mejoras, etcétera, etcétera. Y bueno, para entender qué es esto de desarrollo comunitario, pero entonces la pregunta de rigor es, si eso es así, ¿qué lo motive entonces? ¿Qué motiva que exista que la gente participa en proyectos desde los cuales los conceptos tradicionales de paga me no existen? Pues existen otros elementos como, por ejemplo, ese es jerarquía consexuada que yo lo llamo o lo hemos llamado nosotros, jerarquía. En los proyectos de desarrollo, existen jerarquías, pero que no tienen que ver con los modelos tradicionales. Las jerarquías se basan en conocimiento, lo cual viene dado por la práctica, es decir, a medida de que tú haces más, tú tienes mayor reconocimiento y por lo tanto, si haces más, tienes una mayor jerarquía dentro del proyecto. Eso es diferente al modelo tradicional en el cual el jerarca está puesto ya por el sistema y hay que aceptarlo así como es. En mi pueblo hay, en Venezuela existe un dicho para eso. Creo que si lo digo acá no tendría mucho sentido porque no entendería el contexto, pero es algo así como, jefe, jefe, así tenga piojos. Nosotros decimos cochochos, piojos son estos animalitos que salen en la cabeza a las personas. Bueno, en Venezuela decimos jefe, jefe, así tenga piojo. Es decir que muchas veces los jefes no tienen ni idea de dónde van las cosas, pero es jefe, porque así lo dice el modelo tradicional. En proyectos como esto, ese modelo simplemente cae. El otro, esas heterarquías, es decir, yo reconocer que el otro es igual a mí, pero que en algún momento puede estar por encima de mí, viene dado por una práctica consensuada. Es decir, yo acepto que él esté en un puesto de jerarquía, el puesto del DPL es el más clásico. Yo acepto que el DPL sea DPL, ¿por qué? Porque hay una práctica detrás y porque en algún momento se necesita que el proyecto tenga una direccionalidad, que no la da el DPL, ciertamente, sino que la da toda la comunidad y el DPL ayuda a que eso sea así. Existe un fin común, existe una retribución no monetaria que viene dada por valores, ¿OK? Existe una retribución no monetaria que viene dada por valores, es decir, que me reconozcan mi aporte y, finalmente, existe un punto que un amigo que es economista, que fue ministro de planificación en Venezuela, llamó egoísmo altruista, que es una cosa contradictoria, pero que tiene que ver con lo siguiente. Yo soy egoísta porque libero mi código buscando una retribución para mí, pero es altruismo en tanto que lo libero, es decir, yo espero un beneficio, pero ese beneficio lo espero en la medida en que libero todo lo que sé. Eso es un poco lo que tiene que ver con el egoísmo altruista. Entonces vean que hay una serie de elementos que van mucho más allá del monetario que hacen que las personas participen en proyectos comunitarios. Y como le dije, este es un punto sumamente interesante. De hecho, muchos de los que trabajan en Debian no reciben retribución. En mi caso, por ejemplo, me paga el Instituto de Investigaciones por examinar qué hay detrás de todo esto. Y lo que yo voy haciendo, su vez, lo voy liberando. Y parte, todo el trabajo que voy haciendo, también lo voy liberando. Entonces, no existe una retribución directa en cuanto a participación del proyecto, pero existen valores como esto que son muy importantes con lo sé. Pues nada, preguntas, comentarios. Una cosa que quizás nos ha comentado, cuando sé si es muy compleja, es la parte rígida de cómo hacer esa red de Debian o qué fórmula de participación es ahí. Porque me parece que hay más que una. ¿Se puedes comentar un poquito o si alguien puede comentar algo? ¿Quieres comentar algo? Sería bastante injusto que comentara. Yo digo, a mí me gusta y siempre termino robando el micrófono donde sea que me pare, pero es tu práctica. Sí. Fíjate, uno de los elementos más, o sea, como decíamos, la forma tradicional de participar en Debian es, o una de las que tiene mayor publicidad o promoción, es la de ser desarrollador. Por ahí va tu pregunta. OK, es la de ser desarrollador que yo realmente considero no es la mejor vía para participar en Debian al principio. Te pongo mi experiencia personal. Yo estoy trabajando con Debian desde que salió potato, o teido, o papas, o patatas, como le quieras decir, he estado trabajando con Debian. Nunca he entrado en el proceso de ser desarrollador. Últimamente he estado trabajando en ello. Es probable que en este DESKON meta mi procedimiento. Pero la primera forma la que siempre se dice es, tienes que empezar a ser desarrollador o ser desarrollador. Yo creo que no es la más adecuada cuando uno se está iniciando. OK, no obstante, es un proceso bastante rígido. Tiene toda una serie de etapa. Por ejemplo, una de las primeras etapas que se te dicen es, tienes que tener tu llave pública firmada por un desarrollador. Eso es casi que el requisito de entrada. Eso se basa en el traslado de algo que en sociología se aman los grupos. O sea, tú, en el momento en que un desarrollador firma tu clave, está indicando que te conoce o que quizás no tanto personalmente, pero que sí sabe que tienes algunas prácticas de seguridad que podrían redundar en el sistema o que pueden ayudar al sistema. OK? Es reconocer que el otro tiene capacidades. Eso es casi que lo primero que te dice. Previo a eso, tú debiste haber, por ejemplo, empezado a mantener algún paquete. OK? Debiste haber buscado un mentor, alguien que te ayudase, a subir tus mejoras, etcétera, etcétera. Y después de todo esto, es que tú empiezas la aplicación que puede tardar meses, años. Tú recuerdas cuál ha decidido uno los procesos más cortos, Aníbal. Tú recuerdas, Gunnar, alguno de los procesos más cortos. A algunas veces el proceso es muy rápido para personas que tienen que tienen muy bien reconocidos por su trabajo que han estado haciendo durante mucho tiempo y muchas veces ellos son aprobados en menos de tres meses. Sí, pero fíjate que lo que les decía, hay un proceso formal. Pero esa persona antes tenía cualquier cantidad de años. Antes de eso, tuvo que haber estado trabajando mucho tiempo, hasta por años. Sí. Claro, hoy en día ya se pide que para entrar al proceso de desarrollador ya estés haciendo algo. Digo, yo actualmente, por ejemplo, estoy procesando una persona que casi termina ya con su solicitud y llevamos un mes trabajando. Pero ya está involucrado hace tiempo. Por allá tenía una participación. Sí, yo creo que te habías preguntado también por qué otras formas de participar en el proyecto existen, aparte de ser un desarrollador. Y es bien importante porque hay muchas cosas que se pueden hacer que ayudan al proyecto, que nos las hace un desarrollador. Digamos, el desarrollador están las tripas del proyecto. Es el soldado básico del funcionamiento completo del proyecto. Pero hay cosas como traducir programas, como reportar bugs, como estar en el chat ayudando a la gente y demás que pueden ayudar mucho a eso. Entonces, puf, cuando tú entras a la página, pues hay cientos y cientos de cosas. Ya, ya, ya. No, pues que yo llevo usando Debian desde el 2002 y más o menos a la teoría y he hecho algún bug report y he hecho mi paquetito un poco para mí. Pero la idea es si ya tengo un paquetillo que puede ser, bueno, no es quizás lo más correcto que funciona, ni mucho menos tampoco es policy compliant, ¿no? Pero si ya tengo un paquetillo y demás, ¿cómo hacer para subirlo o para incorporarlo a Debian via alguien o a una cosilla así? Y luego yo tengo el control para hacer los cambios. Bueno, tienes que, yo justamente estaba desde hace poco tiempo en eso. Yo antes usaba, por ejemplo, me ayudaron muchos otros desarrolladores que uno conocía ya tanto por amistad o por IRC y fuiste queriendo una amistad con ellos. Pero yo estaba usando hace muy poco tiempo lo que llaman el Debian Mentors. Ellos justamente lo que hacen es tratar de ayudarte a subir un paquete y tienes que seguir un proceso, ¿no? Un algoritmo que ellos te dicen. Y eso es básicamente lo que hace cuando no conoces a casi nadie o necesitas que alguien te lo suba, pero la persona que te lo va a subir, que es un desarrollador, te exige que tu paquete prácticamente te exige muchas cosas que tenga, que siga todas las políticas, por supuesto. Y si alguien está interesado en tu paquete, tú lo que haces es subirlo. Pero lo primero que tienes que hacer es enviar un correo, un correo a la lista de Debian Mentors. Y ellos sencillamente lo que van a hacer es subir el paquete. Por supuesto que la mayoría de las veces, depende de desarrollador, que lo quieras subir, te exige muchas cosas. Hay desarrolladores que, por ejemplo, no utilizan un archivito que se llama el WATCH, que lo que te permite es verificar las actualizaciones que va a tener ese paquete. Para subirlo con Debian Mentors, es necesario ese archivo. De hecho, te lo exige la página, te dice. Si no tienes ese archivo, no puedes ni siquiera mandar la solicitud. Y bueno, tener el paquete de hecho Debian Mentors es muy flexible, porque también te permite, si tú no tienes un servidor web donde subir el paquete, que sea accesible, ellos también te dan una cuenta con un usuario, de manera que tú puedas subir tu paquete con la página web y tengas todo eso ahí. Y te genera la solicitud con el correo y todo, te la genera todo automáticamente. Y bueno, el resto de lo que tienes que esperar es que algún desarrollador se interese por el paquete y decida subirlo, ¿no? Lo que sí es un proceso algo lento. Eso también depende de las personas que estén allí, ayudando. Yo aquí cuelgo de una vez un poquito de anuncio de lado. Mira, hay varios grupos de trabajo a través de los cuales puedes participar. Si tu paquete es, digamos, un programita genérico, pues lo subes a través de Mentors y puede ser lo mejor. Pero también hay varios grupos que se dedican a áreas de infraestructura de propósito bastante más bien de características comunes. Por ejemplo, yo participo en los grupos de Perli y de Rubi. Casi todos los paquetes que mantenemos, pues cumplen por mucho con la misma estructura. Entonces, por ejemplo, te puedo decir que entre cosa de 15 personas estamos manejando cosa de 1.300 paquetes en Perli. Ahí él es uno de los instigadores primarios. Y pues, bueno, ahí es mucho más ágil todavía el asunto. Primero, puedes pedir ser parte del grupo. Para eso basta con que crees una cuenta en Aliote. Y una vez que eres parte del grupo, pues nada más, subes tu paquete, lo etiquetas como ya está listo. Alguien lo va a encontrar dentro de 2 o 3 horas y lo va a subir. En Mentors, pues sí, tienes razón. Es algo lento porque tienes que llamar la atención hacia lo que tú estás haciendo. En tanto que en los grupos que trabajan alrededor de un depósito, pues es mucho más ágil. Y otro punto es si tienes un paquete, utiliza las herramientas para hacer pruebas desautivas del paquete. Por ejemplo, PeeBuilder corre tu paquete, corre el PeeBuilder, corre el Élida para que te ayuden a depurar cosas como, qué sé yo, una licencia que no esté bien clara o una parte que no sea muy descriptiva, etcétera, etcétera. Bueno, con la experiencia que yo tengo paquetando, que tampoco es que sea mucho, yo creo que la mejor forma de comenzar es la que te dijo Gunnar en un grupo. Por ejemplo, yo también pertenezco al grupo de Pair, que en paquetan para Pair. Y a mí me ayuda mucho porque también ha aprendido muchísimas cosas. Por ejemplo, Gregor me ha enseñado muchísimas cosas. Básicamente, tú subes un paquete y entre todos van ayudándote a mejorar ese paquete y cualquier actualización la hace quien pueda, quien tenga más tiempo. Pero tú aprendes muchísimo, muchísimo. En mentor, por supuesto, que te hacen correcciones, pero si tu paquete no está del todo bien hecho, sencillamente ni siquiera te van a responder un correo y te van a obviar. Así que tiene que cumplir bastante bien las políticas. En cambio, en el grupo de Pair, por supuesto, también te exigimos que cumplan las políticas pero te ayudan bastante bien, te ayudan, aprendes muchísimas cosas. O sea, tips, muchísimo, muchísimas cosas yo he aprendido y de verdad yo se lo agradezco al grupo en general. Entonces, si quieres comenzar, yo sí te recomiendo por ahí, por algún grupo, en caso que el paquete es para librerías de Pair o programas en Pair, si el paquete es para Python, hay varios grupos de Python, de Pair, de varios. Entonces, yo te recomendaría y empecé por ahí, una recomendación más personal que cualquier otra. Alguna. Voy a cambiar de tema, ¿eh? No, yo hablo como usuario final y por la mañana me encontraba con una persona por aquí y me dice, hombre, un usuario final, dame. Porque yo, o sea, yo no soy informático, ¿no? Yo simplemente uso el ordenador porque lo tengo que usar, punto, y hace varios años ya que uso de bien. Entonces, bueno, yo hablas un montón de cosas aquí que hay algunas en que creo que puedo aportar, pero la inmensa mayoría de ellas no, ¿no? Pero, aún así, Jolín, yo tengo ideas y tengo cosas que, a lo mejor, pudieran servir. Entonces, por ejemplo, eso. Yo tengo una idea de un programa, pero yo no sé desarrollar, yo no sé picar código, yo, pero a lo mejor hay gente que sí sabe hacer código, pero no tiene la idea de, coño, mira, este programa puede ser útil para ciertas personas. O, bueno, no sé, eso. Quizás allí hay un punto interesante y es que busca algún programa, si no sabes desarrollar, búcate un programa que sea algo parecido a lo que tú tienes. Quizás haya alguno que sea parecido a lo que tú tienes. Métete en ese programa, participa en la lista de discusión y trata de dar tus aportes de cómo debería hacer, porque es probable que la visión que tú tengas, el desarrollador o el grupo de desarrolladores, no la hayan tenido. Y quizás ayudes, entonces, a que ese programa tome un poco la visión que tú estás tomando. Ese es un poco ya cuando uno no sabe nada, pero tiene algunas ideas, se busca ese programa y, bueno, trata de hacer los aportes a ese grupo para que sean concretos. Yo aquí, déjame, nada más, se agregar un poco a esto. Eso de ser informático, pues es como un formalismo que no tiene razón de ser. Héctor empezó diciéndote que él no es, yo tampoco soy. Así, nada más, alentando la pregunta, ¿quién de aquí estudió formalmente informática? OK, es mayoría, pero no es mayoría pabullante. Estarán de acuerdo. Yo personalmente no han completado ni siquiera la carrera, que apenas estudiaron en la preparatoria, pero son excelentes. Alejandro Emusila, o sea, personas que tú las pones frente a un ordenador y hacen maravillas. Bueno, tú estás acostumbrado a andar con gente con sombrero, yo no, pero. Lo mejor que puedes hacer es irte involucrando de a poco. Si tú, exacto, lo que dice Héctor, tú encuentras un programa que hace 80% de lo que quieres, reportes un fallo. Y claro, en el proceso, o sea, reportes un fallo porque no cumple la funcionalidad necesaria que tú tienes, que tú requieres. Y en el proceso de ir guiando a la persona para que implemente lo que tú necesitas, vas a ir aprendiendo. Y una vez que vas aprendiendo, pues vas involucrándote. Y si te gusta, pues lo puedes terminar haciendo tú también. Y fíjate que hay, antes de continuar, fíjate que hay algo muy importante. En Debian, existen personas que están en puestos, oye, que tienen mucha responsabilidad. Por ejemplo, Cristian es un poco el coordinador de todo el equipo de traducción de Debian, ¿ok? Y Cristian no es informático. Y él lo comente en algún momento. Oye, yo mismo lucré en esto porque me pareció interesante, me fui involucrando, me fui involucrando. Y hoy día es uno de los que coordina el grupo de traducción de Debian, el grupo I18N, que es el grupo de internacionalización. Entonces, yo creo que lo importante son las ganas de aportar y de colaborar y de aprender que podrías tener involucrarte. Volucrarte es que vas a aprender muchísimo en el camino. Bueno, yo quería decir dos cosas. La primera es que también puede pasar que alguien haya estudiado formalmente informática y no sepa moverse para nada. Conozco el caso. Y lo que quería decirte es que existen comunidades que tienen secciones específicamente para capturar estas ideas que pueda tener cualquiera. Por ejemplo, en la página KD Look, se ha relacionado con el entorno de KD, tienen dos secciones, una de brainstorming general y otra de ideas para KD4. Y ahí la gente sube diagramas que hace EmoCapso, directamente un texto, una idea, y lo votan y comentan otros usuarios. Entonces, existen canales para poder hacer esa contribución, aunque tú consideras que igual no tienes la habilidad técnica o todavía. Pero que existen esos canales. ¿Alguna de los otros comentarios? Comentario, pregunta. ¿Nada? Pues nada, mucho.