| _Quark_ | confirmando |
| MJesus | quien va a traducir ? |
| damage | _Quark_ traduciras? |
| _Quark_ | sip ayudare |
| _Quark_ | que debo hacer |
| _Quark_ | me limito a cortar pegar al vuelo ó al finalizar la conferencia |
| _Quark_ | ? |
| fernand0 | ? |
| felipe | cool |
| damage | Hola, hoy dia tenemos con nosotros a Gregorio Robles y Jesus Gonzales Barahona. |
| damage | ellos son de Grupo de Sistemas y Comunicaciones (ESCET). Universidad Rey Juam |
| damage | Carlos en España |
| damage | la charla sera de: "On Software libre engineering". |
| damage | este grupo hace un trabajo muy interesante sobre este tema |
| damage | estamos agradecidos de ustedes por esta interesante charla |
| damage | y tambien por haber concurrido hasta aca |
| damage | Como de costumbre, la charla será dada aquí. Los traductores (si esta' disponible) traducirán en #redes. Tenemos también un canal en #qc, donde pueden escribir preguntas y comentarios sobre la charla |
| felipe | usamos el termino software libre para evitar la confusion con software gratuito |
| unizar.es.uninet.edu MODE #redes +o krocz | |
| felipe | bueno ahora veamos un poco de historia en |
| felipe | http://sinetgy.org/jgb/articulos/libre-software-origin/ |
| felipe | una breve investigacion acerca del termino "software libre" |
| felipe | puede que su origen sea frances o espanol |
| felipe | bueno, ahora pasemos a la charla |
| damage | Así pues, aqui un resumen corto sobre las cosas que vamos a hablar, |
| damage | nosotros vamos ha hablar sobre la diferencia entre la tecnología 'classical' de dotación lógica |
| damage | y tecnología de dotación lógica libre |
| damage | cuando analizamos el concepto de bazaar y el ultimo, hablaremos un poco sobre algunas estudios de grupos |
| damage | de investigacion que se han realizado en esta materia |
| damage | Así pues, vamos asumir el control el primer punto yo imagino que muchos de ustedes se han preguntado: porque ingenieria de software libre? |
| damage | la respuesta es que algunos puntos son muy diferentes por que nosotros tenemos poco conocimiento sobre ingenieria de software |
| damage | mirado desde este punto de vista los proyectos del software libre estan haciendo casi exactamente lo que |
| damage | los textos clasicos de software engineering dicen, dicen que un proyecto debe estar en orden para ser |
| damage | aceptado, por supuesto no esta por que essos libros son incorrectos, la edicion del ambiente es diferente |
| damage | software libre es basicamente producido en otro ambiente, completamente diferente a las maneras de hacer software |
| damage | especialmente en ambientes corporativos |
| damage | entonces, nuevo ambiente significa nuevas posibilidades, pero tambien nuevos cambios |
| damage | la posibilidad viene por parte de toda la informacion publica que esta disponible |
| damage | entonces nosotros podemos estudiar el proceso del libre software development |
| damage | piensa que nosotros solo tenemos el codigo fuente como tambien toda la historia de versiones del repositorio |
| damage | o como tambien tenemos el bug tracking system para ver los errores, o como tambien las listas de correo |
| damage | y actualmente tenemos miles de proyectos de software libre |
| damage | pero por otra mano tenemos que el ambiente del software libre es muy dificil, solo imagina que tenemos mucha |
| damage | gente que no se conoce |
| damage | en diferentes ubicaciones geograficas para trabajar en un proyecto de software |
| damage | y nosotros no sabemos cuánto tiempo dedican estos desarrolladores al proyecto |
| damage | por que son mas que todo voluntarios |
| damage | y nosotros no tenemos un punto en comun para referirnos a la informacion como compañias tienen programadores |
| damage | que trabajan de manera clasica. |
| damage | ademas el software libre no es solido, es muy dificil de estimar la base de usuario para cada producto del software |
| damage | libre |
| damage | en efecto, en muchos casos es dificil seguir la pista de la actividad del desarrollo, puede que un fork pase en |
| damage | algun momento y la actividad se valla a cualquier lado, donde el grupo de desarrollo forked decide |
| damage | Asi,una vez que sepamos porqué es interesante centrarse en en ingenieria de software |
| damage | las ediciones con respecto a software del libre, vamos entrar en un cierto detalle |
| damage | Supogo que muchos de ustedes estan impacientes por esto |
| damage | amos a hablar de bazzar |
| damage | rimero, nosotros tenemos en mente que los proyectos de software libre son libres |
| damage | por que vienen con sus licencias |
| damage | el software libre se define para los libres que tienen el software y que no tienen el mandato del modelo de |
| damage | desarrollo y de echo, cada proyecto de softwarel ibre tiene su modelo de desarrollo sin embargo muchos de ellos |
| damage | (especialmente los de cierto tamaño) |
| damage | ciertas caracteristicas comunes del objeto expuesto en el primer panel que expone estas caracteristicas |
| damage | es "The cathedral and the bazaar", por Eric Raymond (esr) |
| damage | desde ahi puedes ver muchos modelos ha hablar sobre "bazaar", pero esto era solo un primer intento, que de echo |
| damage | sera visto mas adelante no tan exacto |
| damage | el cual esta traducido a muchos idiomas |
| damage | basicamente, el argumento principal es que los proyectos :S ?bazaar-driven? trata de abrir el proceso de desarrollo tanto como le es posible |
| damage | esto significa que muestra el codigo, para tener actualizaciones frecuentes |
| damage | para que los usuarios ordenadamente puedan hacer sus colaboraciones |
| damage | y sean co-desarrolladores |
| damage | y bajar la barrera de entrada a la gente que esta dispuesta a colaborar, en el proyecto uno de los principales |
| damage | errores es que la gente piensa generalmente en software libre como sinonimo del modelo de desarrolo de bazaar que es |
| damage | algo inexacto |
| damage | si le echas una mirada a sourceforge |
| damage | http://www.sf.net |
| damage | que es el sitio de desarrollo de software mas grande con alomenos 100.000 proyectos |
| damage | podras ver que la mayoria de ellos son pequeños, en efecto algunos estudies en el han demostrado |
| damage | que el promedio de desarrolladores por proyecto es 1, en otras palabras los proyectos mas comunes son de un |
| damage | solo desarrollador y por tener el modelo de desarrollo de bazaar-style, si somos claros nescesitamos |
| damage | mas que eso |
| damage | de cualquier manera como se dijo antes algunas caracteristicas son encontradas /una y otra vez/ó/una vez mas/ en muchos de los proyectos de software libre |
| damage | cuando un grupo de desarrolladores trabajan en este, es usual que esten distribuidos geograficamente |
| damage | usualmente la mayoria de veces ni siquiera tienen interacción cara a cara trabajando en diferentes zonas horarias |
| damage | usando casi que solo herramientas para internet |
| damage | ellos usualmente tienen que lidiar con culturas diferenten con la carencia de jerarquias formales |
| damage | y con la manera usual de trabajar: sin jefe que pueda decir lo que un voluntario deba hacer, eso puede ser |
| damage | una sugerencia o una motivacion (es una manera de jefe diferente a los jefes clasicos) |
| damage | despues tenemos algunas caracteristicas de desarrollo global de software |
| _Quark_ | ---... |
| _Quark_ | ok |
| damage | uno de los casos de estudio mas conocidos es Linux y la evolución de su codigo fuente historicamente ha habido una rama en la ingenieria de software llamada |
| damage | -- |
| damage | desface |
| damage | -- |
| damage | seria muy interesante ver si pasa eso tambien en otros proyectos de software libre, voi a enfocarme en buscar |
| damage | sobre este aspecto. |
| damage | este es solo un ehjemplo de lo que se debe hacer para buscar la informacion, publicamente disponible en los |
| damage | repositorios del software libre, estos son: cvs o svn repos, listas de correo, reportes de bug, weblgs, y algunos |
| damage | otros |
| damage | para obtener informacion de ellos, podemos obtener mucha informacion que despues puede ser usada para responder |
| damage | interesantes preguntas como |
| damage | si linux crece linealmente o son los software sobre una linea de codigo |
| damage | teniendo mas bugs, o son arreglamos mas lento? |
| damage | hay muchos grupos en el mundo analizando el software libre desde este punto de vista, uno de estos es URJC |
| damage | un ejemplo de esta herramienta que estos grupos usan y del resultado que obtienen es CVSAnalY tool |
| damage | http://libresoft.dat.escet.urjc.es/index.php?menu=Tools&Tools=CVSAnalY |
| damage | que nosotros utilizamos para analizar CVS Logs, y de esa informacion y desde ahi saber como esta |
| damage | siendo actualmente producido el software libre |
| damage | proyectos como KDE y GNOME puedes encontrar resultados para KDE en la siguiente dirección: http://libresoft.dat.escet.urjc.es/cvsanal/kde3-cvs/ como pueden ver, un monton de información puede extraerse desde los CVS |
| damage | grandes proyectos usualmente son divididos en pequeñas piecas que son llamadas modulos |
| damage | estos tratan de ser independientes de cada otro para asi tener mas intercomunicacion, con CVSAnalY tool |
| damage | podemos ver como trabaja en cada modulo y como se desenvuelve en el tiempo |
| damage | hay algunas cosas interesantes que emos visto en el analisis de modulos |
| damage | primero is que los proyectos mas viejos usualmente tienen cantidades de generaciones de desarrolladores que trabajaron en el |
| damage | en la mayoria de las personas que inician y crean un proyecto listo pueden dejar el proyecto sin nescesidad |
| damage | de preocupar por que otros lo tomaran denuevo, entonces podemos ver diferentes grupos de personas poniendo |
| damage | proyectos, en otras palabras diferentes generaciones |
| damage | otra edicion importante que se ha precisado en la literatura muy a menuda |
| damage | es el echo de que hay una alta desigualdad en contribuciones,que un sistema pequeño de personas |
| damage | contribuje una parte grande del proyecto siguiente casi una pareto distribution |
| damage | quien dice que el 20% de desarrolladores sacan el 80% de el codigo que se ha contribuido |
| damage | algunos investigadores dicen que el software libre sigue el modelo de una cebolla |
| damage | tenemos un grupo central conformado por una docena de desarrolladores quienes toman la mayoria de las tareas |
| damage | y alrededor esta otro grupo que esta que esta entorno a un orden de magnitud mas grande que contribuye ocasionalmente con codigo fuente y otras cosas/significados |
| damage | finalmente aqui esta otro grupo, otro orden de magnitud mas grande que la anterior |
| damage | quien es el responsable mas pequeño, pero las tareas mas importantes como informes de bugs, etc.. |
| damage | en el ultimo tenemos los usuarios del software, pero saber su numero es bastante dificil, pues el software |
| damage | libre se puede redistribuir y se envia en la multiplicidad de maneras (distribuciones, etc.) |
| damage | es tan dificul saber cuanta gente utiliza realemnte un software |
| damage | otro ejemplo de que tipo son los estudios cuantitativos puede ser echo en nuestro analizis en debian |
| damage | http://people.debian.org/~jgb/debian-counting/ este fue para debian 2.2. |
| damage | ahora vamos a cerrar para el publico simir informacion a 3.0 y por el que viene 3.1 |
| damage | estos analisis miran el codigo fuente por toda la distribucion, y pueden responder preguntas respecto |
| damage | de tu lenguaje que usas en debian (por sierto, la respuesta es "inicialmente C, con algo de C++ y otros) |
| damage | parece Debian incluir todo los programas estables disponibles para GNU/Linux que tambien es software libre |
| damage | (free, open source) |
| damage | este es un buen indicado de que lenguaje se esta utilizando por la comunidad de desarrolladores del software |
| damage | libre para sistemas GNU/Linux-like, podemos usar tambien aa clasida medida del monto de codigo, el SLOC |
| damage | (linea segura de codigo) para estimar el tamaño de debian |
| damage | como se habia dicho antes, esto tambien es una estimación aspera de el tamaño agregado de el desarrollo de software libre hecho por GNU/Linux |
| damage | eso fue mas que 50 MSLOC para Debian 2.2, y acerca de 100 MSLOC para 3.0 |
| damage | y probablmente cerrara con 200 MSLOC para Debian 3.1, de acuerdo a nuestras estimacuines |
| damage | SLOC es muy importante desde que son la unica entrada a el modelo de estimación clasico de esfuerzo, el modelo COCOMO |
| damage | este modelo usa SLOPC pare estimar el esfuerzo nescesitado para desarrollar cada software, y se utiliza extensamente |
| damage | como un ingeniero clasico de software |
| damage | usandolo, podemos decir que, era COCOMO im estimador valido, el software en debian ha adquirido |
| damage | acerca de 2.000 euro para desarrollar. en otras palabras, el software en debian fue desarrolao usando |
| damage | el software clasico, metodos donde COCOMO eran validos, ese es el monto de recursos nescesarios, porsupuesto |
| damage | esto es solo una minima comparasion pero puede dar el ultimo ordenan de magnitud.. desafortunadamente, por muchas |
| damage | rasones COCOMO parece no ser valido como un proyecto de software libre |
| damage | en efecto, buscamos otras maneras para estimar el esfuerzo en este caso de los proyectos de software libre |
| damage | casi terminando, pero antes un ejemplo |
| damage | echenle una mirada a http://gsyc.escet.urjc.es/~grex/apache/todas.html |
| damage | y podras encontrar un analisis de rede que hemos echo en el proyecto de Apache |
| damage | nodos en el analisis de la red son los modulos de CVS que he estado hablando hace lineas anteriores |
| damage | nodos(modules) estan conectados si hay un ultimo desarrollador en comun, si hace esto, entonces tienes algo |
| damage | como esto: http://gsyc.escet.urjc.es/~grex/apache/apache-total-feb04.jpg |
| damage | cual es el lio mas grande, donde tu no puedes ver nada acerca de la estructura del proyecto,entonces hemos |
| damage | usado un algoritmo que mira la estructura en cada red y obtenemos una fotografia como esta: |
| damage | http://gsyc.escet.urjc.es/~grex/apache/apache-2004-2-01.sna2.jpeg |
| damage | despues del algoritmo, los modulos en la misma linea pertenecen de alguna manera, se han colocado los nodos por |
| damage | su familia asi que en el rojo unos y los que pertenecen al servidor httpd al azul, unos al xml de jakarte, otros |
| damage | estan en verde,etc.. |
| damage | y como podemos ver el cuadro de la estructura de la red, parece ir muy bien..si deseas saber mas sobre |
| damage | esto echale una mirada al blog: http://barba.dat.escet.urjc.es:9080/libresoft/14 |
| damage | ahi esta mas detallado |
| damage | si, muchisimas gracias por su atención si tuvieramos una conclusión |
| damage | seria probablemente como esta |
| damage | ingenieria de software libre es un nuevo archifero, muy prometedor en los resultados |
| damage | pero recien esta comenzando lentamente a ser explorado |
| damage | creo que ahora podemos tomar algunas preguntas |
| felix | jaime: listlogs |
| felix | jaime: endlog |
The Organizing Comittee
