Mapa del Software Libre en Chile, proyecto PostgreSQL

Seguimos con la segunda parte del Mapa del Software Libre en Chile, ahora presentamos la encuesta realizada a Álvaro Herrera que es commiter del proyecto PostgreSQL y moderador de la lista pgsql-es-ayuda.

Agradecemos a Álvaro por dedicarnos parte de su valioso tiempo respondiendo nuestra encuesta, muchas gracias!

De qué se trata el proyecto? Cómo se financia? Se trata de desarrollar un sistema gestor de bases de datos robusto, confiable y potente, basándose en el estándar ISO SQL y en las necesidades de los usuarios.

No existe un único mecanismo de financiamiento. Los contribuyentes aportan código según sus propias motivaciones (normalmente impulsados por un empleador, aunque hay algunos que lo hacen sólo por la motivación del desafío y el aprendizaje); ciertas personas e instituciones donan dinero para la causa a través de variadas organizaciones sin fines de lucro como Software in the Public Interest, PostgreSQL U.S. Association o la fundación europea cuyo nombre no recuerdo. Estos fondos se utilizan para financiar viajes y estadías de charlistas, merchandising, etc.

Cuantas personas colaboran? Hay unos 20 "committers" que tienen acceso a incorporar nuevo código al proyecto (yo soy uno de ellos); 26 personas son catalogadas "major contributors" (algunos de ellos son committers también); y una lista variable que actualmente tiene 39 "contributors", aunque por lo que veo hay muchos nombres que participan intensamente desde hace poco y no están en la lista. Normalmente en cada release han trabajado unas 200 personas.

Cuál es tu rol en el proyecto? Cómo ha sido tu experiencia? Soy committer, lo cual quiere decir que pertenezco al pequeño grupo de personas que tiene acceso a incorporar nuevo código al proyecto (en cualquier versión: ya sea la versión en desarrollo o una de las ramas estables). Esto pone bastante responsabilidad sobre mis hombros, porque se espera de mi (al igual que de todos los otros committers) que cualquier cosa que contribuya sea de alta calidad; si echo a perder un test, es mi responsabilidad arreglarlo. Si echo a perder el sistema de una forma que una plataforma deja de funcionar, es mi responsabilidad buscar una solución, o buscar alguien que pueda corregir el problema.

Además soy moderador de la lista pgsql-es-ayuda, donde viven los usuarios hispano-parlantes. Estar constantemente respondiendo preguntas a menudo se vuelve un poco tedioso, pero de vez en cuando aparece una oportunidad de identificar un bug real que debe corregirse, o bien una funcionalidad que falta y que debe implementarse. Los usuarios (tanto los experimentados como los que no lo son tanto) son una infinita fuente de nuevas ideas.

Además estoy a cargo de administrar los archivos de las listas de correo; y desde esta semana aparentemente estoy a cargo de administrar las listas de correo propiamente tales, puesto que la persona que solía estar a cargo dejó el puesto.

La experiencia ha sido muy buena. Es tremendamente pedagógico (?) trabajar con gente que es tan extremadamente capaz como Tom Lane, que debe ser uno de los más brillantes ingenieros de software que pululan por Internet. He aprendido muchísimo, no sólo de Postgres propiamente tal, sino de técnicas que pueden ser aplicadas en otras situaciones. En otros términos, también podría decir que estar constantemente dando presentaciones y ocasionalmente cursos sobre Postgres me ha forzado a adquirir un poco de experiencia en el área de presentar y enseñar, que de otra forma probablemente nunca habría hecho.

Me ha tocado viajar bastante: México, Canadá, Estados Unidos, Venezuela, Cuba (y he tenido que rechazar algunas invitaciones).

Por otra parte, gracias a participar en la comunidad conseguí un puesto de trabajo en una empresa de USA de soporte de Postgres, que también ha sido increíble en muchos aspectos; me ha permitido vivir razonable cómodamente.

Realmente, la cantidad de oportunidades que he tenido ha sido muy satisfactoria por si misma.

Cómo se lleva a cabo el desarrollo? Cómo deciden los features de cada release? No hay un "roadmap". Más bien, cada desarrollador y cada empresa que auspicia a un desarrollador (de las cuales hay varias) decide en qué quiere trabajar para cada nueva versión. De esta forma el software crece en varios frentes simultáneamente, porque cada uno tiene distintas motivaciones, dependiendo de a qué negocio se esté dedicando. Los problemas que tiene una empresa que quiere hacer análisis masivo de datos son totalmente diferentes de los que tiene una que maneja un sistema web de uso masivo, y ambos son probablemente diferentes de quien maneje un control de inventario, un sistema financiero o una plataforma de telecomunicaciones.

El desarrollo se estructura en lo que llamamos CommitFests. En cada commitfest, los desarrolladores registran cada modificación que desarrollan; en algún momento el commitfest deja de recibir nuevos parches y entramos en el estado en que cada parche recibe revisión por parte del resto de los desarrolladores, y bien se incorpora, o bien se decide que la característica no es deseable o que la modificación necesita trabajarse un poco más para alcanzar calidad aceptable. Esto se repite hasta que se acaban las contribuciones del commitfest, de modo que todo el mundo siempre sabe que su contribución va a recibir la revisión necesaria para asegurar que la integración produce un resultado de buena calidad.

Básicamente, el sistema de commitfests está hecho para hacer que el enorme flujo de contribuciones que recibimos tenga suficiente estructura para hacerse manejable. Normalmente hay 4 o 5 commitfest en cada versión de Postgres (que es aproximadamente unos 14-16 meses).

Esto es independiente de los parches que son necesarios para corregir errores. Esos parches no entran en commitfest, porque normalmente esos parches se demoran 1 o 2 días en ser procesados, a diferencia de los 2 meses que puede tardar el proceso a través de un commitfest.

En lo que ahora se ha vuelto tradición, en cada PGCon (conferencia anual en Ottawa) llevamos a cabo una "Developer's meeting" donde los desarrolladores más activos discuten ideas cara a cara. Para ideas complicadas o que requieren tener objetivos de largo plazo en cuenta, esta reunión es tremendamente productiva, aunque normalmente no se produce ningún código. Permite que una discusión que tardaría un mes en las listas de correo se resuelva en 20 minutos. Es genial ver estas sesiones de mentes brillantes actuando todas juntas en búsqueda de soluciones a problemas que a veces ni siquiera sabemos que tenemos.

Que que lenguajes y herramientas usan? Más que nada se usa el lenguaje C, aunque por supuesto PostgreSQL existe sobre todo para permitir el uso del lenguaje SQL. Hay algunas cosas auxiliares en que se usa Perl como herramienta de soporte, pero más que nada son cosas que están ahí y funcionan bien y por lo tanto no se tocan mucho una vez que se han escrito.

La documentación está en DocBook SGML, que es una herramienta que nos ha permitido producirla en HTML y PDF y otros formatos en forma simple y de calidad. Un punto importante es que si bien tenemos un sistema de comentarios en la versión web de la documentación, estos comentarios no se consideran parte integral como los del manual de PHP. Lo que se hace es tomar esos comentarios, si son buenos, e incorporarlos en la prosa de la documentación propiamente tal. Con esto conseguimos que la documentación misma sea de gran calidad (a diferencia de la de PHP que para mi gusto es basura con muy mala estructura, incompleta e incoherente, y lo único que te ayuda a tener una idea más clara de la realidad son los comentarios de usuarios).

Usamos Git para manejar el código, desde hace poco tiempo. Hasta hace muy poco usábamos CVS. La conversión nos tomó mucho tiempo porque quisimos hacerla de muy buena calidad. Como resultado, uno puede mirar la historia Git y encontrar que exactamente representa nuestra realidad, desde el primer commit en 1995 que incorpora el código tal como salió de Berkeley.

No tenemos bugtracker. Tenemos un formulario para enviar bugs en el sitio web, pero lo que hace es mandar un correo a la lista pgsql-bugs. Lo que pasa de ahí en adelante depende de las personas: alguien lo toma y decide si es un bug válido o no; y si lo es, se le busca solución. Si es un bug real normalmente se resuelve en uno o dos días. A veces las cosas toman más tiempo que eso pero tratamos que nada válido se pierda sin encontrar solución. Se ha discutido el uso de algún bugtracker pero realmente muchos creen que hará las cosas más difíciles de lo que resolverá.

Tenemos una buildfarm propia. Es como un sistema de testing continuo (algo así como lo que era Hudson): cada vez que alguien sube un parche, inmediatamente decenas de sistemas en distintas plataformas, distintos compiladores lo compilan, corren las pruebas, y reportan si cada paso funciona o no. De esta forma tenemos resultados inmediatos de que nuestro código no se rompe de un momento a otro.

Tenemos un montón de infrastructura (servidores web, de mail, listas de correo y archivos, la buildfarm, el sitio de traducciones, ...) que es manejado por un grupo de gente medianamente invisible que nos hace las cosas muy sencillas. Es genial.

Yo (y otros) uso Vim. Otros hackers usan Emacs. Existe gente que usa otras cosas pero hacemos lo posible por impedir que se reproduzcan.

Que tan usado es Postgres en Chile? Hay ejemplos de uso en organizaciones grandes? Muchas, pero son pocas las que lo dicen. Uno de los usuarios que lo hacen público es la superintendencia de pensiones. Empresas privadas hay montones y en muchos rubros, pero no estoy autorizado a dar nombres.

Existen empresas que den soporte en Chile? No que yo sepa.

Sabes de alguien más que colabore con el proyecto desde Chile? No.

Que plataforma (distro de Linux) usas para tu trabajo? Por qué esa y no otra? Debian. La uso porque es muy cómoda, tiene paquetes para casi todo lo que necesito, se mantiene razonablemente al día (no uso Stable), se mantiene bastante cercana a lo que es upstream en la mayoría de las cosas. Quizás podría usar otra cosa pero llevo usando esto como 6 años y no tengo interés en cambiar.

Si alguien quiere colaborar con el proyecto, por dónde podría comenzar? Uf, hay muchas cosas que hacer. Si te interesan los temas de código, puedes participar en las revisiones de parches que se envían en cada versión, http://commitfest.postgresql.org Todas las revisiones son bienvenidas, no necesitas ser un super-hacker. Si quieres escribir código, también se puede; hay muchas áreas en que se puede trabajar, desde el servidor propiamente tal, o herramientas de gestión como pgAdmin, la interfaz web phpPgAdmin, o proyectos externos relacionados (de los cuales hay muchos).

La lista de cosas por hacer está en http://wiki.postgresql.org/wiki/Todo. Con ese material, siempre hay más que suficiente para empezar en alguna parte (Nota respecto del "To Do": no porque algo aparezca ahí significa necesariamente que estamos de acuerdo en que debe implementarse, o en la forma en que debe implementarse. Es sabio preguntar en pgsql-hackers antes de lanzarse a implementar algo). Por supuesto, cualquier característica descrita por el estándar SQL que no esté implementada (o que no esté completa) es deseable. En todos los casos, es necesario discutir el tema en pgsql-hackers ¡antes de escribir ningún código!

No tenemos un bugtracker; los bugs son archivados en pgsql-bugs. De vez en cuando se reportan bugs que requieren escribir código para solucionarlos. Cuando hay problemas serios, normalmente se reparan muy rápido; en un día o dos. Pero a veces los reportes son cosas que no suscitan suficiente interés y quedan en el olvido. En esos casos puede ser que alguien con suficiente dedicación (y tiempo libre) ;-) pueda producir algo que solucione un problema real.

Por supuesto, el proyecto Postgres es mucho más que sólo el código. Por ejemplo: el Wiki tiene mucho contenido; a veces escribir un artículo o reformar un artículo existente puede ser una buena tarea también. Y así.

Actualmente vives en el sur de Chile, se hace complicado trabajar a distancia? No.

Que te motiva trabajar desarrollando software libre? Es entretenido (teniendo en cuenta, por supuesto, que para mí es entretenido el código en sí mismo). Se trabaja con gente de muy alto nivel, de la cual puedes aprender mucho. A veces, no necesitas tener super experiencia para que se te ocurran soluciones a problemas que a nadie más se le habían ocurrido. Es desafiante. Hay problemas interesantes todavía por resolver. Te comunicas con gente distinta que comparten intereses en común. Si tienes suerte, puedes tener ocasión de viajar y encontrarte con esas personas.

En algún momento has pensado en tener un trabajo "normal"? Por supuesto, pero a estas alturas probablemente no funcionaría.

Que le podrías decir a un estudiante de educación media/superior interesado en ser desarrollador de software libre? Deja de pensar que los gringos o europeos son "más inteligentes" o "están mejor preparados". Si tu cabeza está hecha para ser desarrollador, puedes lograrlo sólo con esforzarte lo suficiente. Pero si no lo intentas, nunca lo lograrás.

No estoy de acuerdo con Eduardo Silva que plantea que uno debe escribir un "hola mundo" y publicarlo en Internet. ¿Para qué publicarlo? Seguro ya hay cientos o miles de esos programas. Mejor escríbelo y guárdatelo. Después escribe algo más desafiante. Luego sube otro poco la vara. Y así sucesivamente, hasta que llegues a un punto en que produzcas algo que pueda servirle de algo a otra persona; eso sí lo publicas y lo publicitas para ver si encuentras esa otra persona, y ver si te puede ayudar, o mejor dicho, si tú puedes ayudarla a ella.

Tampoco tienes que esperar hasta escribir un sistema de control de bombas atómicas ... las cosas simples también pueden ser útiles.

(Una cosa a tener en cuenta, eso sí, es que si tienes tu código en GitHub, te puede salvar de perderlo en caso de que tu computador pesque fuego un día de estos; aún si no lo "compartes" con nadie más).

Cómo ves la comunidad de software libre en Chile? No la conozco mucho, pero en general tengo la sensación de que hay pocos participantes activos, y aún menos desarrolladores.

Crees que han habido avances? Que cosas se podrían mejorar? No sabría responder esta pregunta.

Encuesta realizada durante Noviembre 2010 y Junio 2011.

 
Acerca de Tux.cl

La historia es larga, tenemos una pagina especial para eso...

Más información »
Ayuda & Soporte

Contáctate con tu GUL más cercano o pregunta en la lista de correo

Linux UTFSM »
Contacto

Email: contacto[arroba]tux.cl

Follow 
tux_cl on Twitter