Libertonia || Comments || Pidgin y Google Desktop


Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios

Pidgin y Google Desktop | 9 comentarios (9 temáticos, editoriales, 0 ocultos)

La disciplina (none / 0) (#3)
por jorginius ("jorginius" en Google Mail) a las Mon Sep 1st, 2008 at 12:28:29 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

Empezar un programa es plantearse problemas nuevos y resolverlos creativamente, eso siempre es más interesante desde cualquier punto de vista que el trabajo sucio.

El punto fundamental aquí es que el software lo puedes entender como algo creativo, un arte, o bien como una ingeniería. El trabajo del ingeniero es transformar su conocimiento tecnológico en productos y si no es capaz no será un buen ingeniero, independientemente de lo creativas que sean sus ideas. Esto vale tanto si hablamos de software o de ingeniería civil. Un programa sin terminar tiene mucho en común con un puente abandonado a la mitad :-P

Lo de "tantos proyectos cerrados tanto vales" lo escuché en una conferencia de Pyro Studios sobre gestión de proyectos. Por desgracia no recuerdo el nombre del ponente (ya ha llovido) pero era alguien de la directiva y el argumento, aunque en un contexto mayor que el de un proyecto personal, sonaba razonable.

Esta persona admiraba a Rebel Act Studios por no haber tirado la toalla con Blade, incluso después de tanto retrasos e incluso asumiendo la quiebra de la compañía. Un buen gestor, según él, era el que lleva al equipo a cruzar la barrera psicológica de "terminado al 90%" a pesar de retrasos y contingencias varias. En la literatura se suele hablar de que ese 10% suele consumir el 90% del tiempo. Decía que, de cara a una entrevista y a presentar un currículum, le decía mucho más los proyectos que había cerrado el aspirante (al margen de los resultados) que aquellos en los que estuviera trabajando, y que los que hubiera dejado inconclusos le causaban sólo mala impresión.

Rebel Act no abandonó su proyecto sino que, a pesar de los retrasos, lo cerro. Muchas compañías grandes o pequeñas, o muchos gestores en realidad, no aguantarían la presión: cancelarían mucho antes y tratarían de capear el temporal.

Volviendo al tema de proyectos personales y software libre, la persona que asume el rol del gestor (nosotros, por ejemplo) abandona antes de completar ese 10%. Falta la disciplina y la implicación "a las duras y a las maduras". Todo proyecto software, incluso los que emprendes como diversión, incluye tareas que son odiosas (documentación es un ejemplo) y si el gestor de proyecto no es capaz de motivar al resto del equipo (muchas veces unipersonal :-D) no se cerrará; fracasará en su trabajo y fracasará el proyecto por extensión.

Lo que sí puede resultar enormemente aburrido es trabajar con un bicho cuyo diseño nos produce náuseas, cuyo lenguaje nos mortifica o cuyo propósito nos ha dejado de interesar.

El dinero es un buen incentivo pero la profesionalidad, el "orgullo" de ingeniero también debería pesar en estos casos, y el gestor del proyecto debería buscar también la motivación del equipo.

El caso es que el programador de software libre "ocasional" (por contraste con un asalariado de Red Hat o IBM) no programa para "hacer programas" sino que lo hace por divertirse, la prioridad principal no es la entrega de un producto terminado y eso los proyectos lo sufren porque todos tienen su parte odiosa que nadie quiere hacer.

[ Padre ]

De acuerdo, y ... (none / 0) (#4)
por atopos a las Mon Sep 1st, 2008 at 01:10:57 AM CET
(Información Usuario) http://los-pajaros-de-hogano.blogspot.com

Ante tus argumentos no puedo sino doblegarme ;-) . A ver si alguien más opina de este tema que seguro interesa a muchos.

No tengo experiencia en software empresarial, salvo por lo que me cuentan algunos amigos que trabajan en ello. Y no puedo opinar más que de refilón. En general, en proyectos de software de cierto tamaño como los que citas, y que, por tanto, son en principio objeto de una demanda considerable, es evidente que el "aspecto de ingeniería" es fundamental, y que se debe pensar en los términos que tú dices. Sí, ahí es necesario el producto terminado, es decir, el cumplimiento del objetivo marcado al comienzo.

En el software casero la cosa es distinta, aunque uno se pueda proponer como meta la emulación del tipo de disciplina que requiere un software de mayor envergadura. Porque, incluso así, es posible que a uno le falten motivos para ello. Sin embargo, puede ser ésa una de las razones por las que el SL funciona, a pesar de que en algunos casos (no, sin duda, los más importantes) sea software inmaduro o abandonado.

Me explico. Quizá sea la presión que ejercen las expectativas de los usuarios o de los colaboradores, cuando los hay, lo que hace funcionar el cotarro. Uno no puede abandonarse cuando hay otros, potencialmente muchos, que están ahí esperando unos resultados. Y, justo, por eso, los perezosos (es mi caso, y no hablo de mi incompetencia, que también) somos reticentes a publicar nada, más allá, si acaso, de enseñarlo a algunos amigos comprensivos. Quizá sentimos inconscientemente que poner algo a luz pública es hallarnos sometidos a las expectativas lógicas de terceros y de que esas expectativas van a obligarnos, en cierto modo, a cumplirlas y a someternos a la disciplina que nos falta o no queremos aplicar en esos asuntos.

Esto, la presión, adquirida por voluntad propia, de otras personas, y el deseo, no sólo de no defraudar, sino incluso de lograr algo realmente bueno para otros, es algo que pasa en todos los campos. Y creo que es uno de los mejores acicates para trabajar de firme en algo que de suyo nos interesa, a pesar de la dura disciplina que exija.

[ Padre ]

Enseñando las vergüenzas :-) (none / 0) (#6)
por jorginius ("jorginius" en Google Mail) a las Tue Sep 2nd, 2008 at 12:07:11 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

Uno no puede abandonarse cuando hay otros, potencialmente muchos, que están ahí esperando unos resultados.

Bueno, tampoco puedes abandonarte en el trabajo porque acabas en la calle :-D

Lo que sí es cierto es que con el soft libre o el opensource todo el mundo ve tu código y estás obligado a "hacerlo bonito" para no sufrir el escarnio público :-P.

Esto no solo es un asunto de ego o "sensibilidad estética": al publicar el código lo conviertes en tu "tarjeta de presentación": igual que lo pueden ver tus amigos lo pueden ver tus empleadores, tus clientes... Eso añade presión.

Quizá sentimos inconscientemente que poner algo a luz pública es hallarnos sometidos a las expectativas lógicas de terceros y de que esas expectativas van a obligarnos, en cierto modo, a cumplirlas y a someternos a la disciplina que nos falta o no queremos aplicar en esos asuntos.

El software libre -cosas pequeñas que surgen por diversión, no hablo de las "vacas sagradas" como Linux, Gnome, KDE, GNU, firefox... Que están über-profesionalizadas- debería ser algo que haces para ti, que compartes con los demás porque no te cuesta nada hacerlo pero sobre lo que no tienes obligaciones. La idea es "he hecho esto y te lo regalo. Si no te vale lo siento, mala suerte... Pero puedes cambiarlo tú".

Cuando los usuarios no aceptan eso sino que exigen opciones que al autor ni le van ni le vienen y sin poner nada de su parte (ni código ni dinero) pasas de trabajar para ti a trabajar para los demás.

Precisamente con este programa, el indexador de pidgin/gaim, tuve una mini-discusión con un usuario hace un par de años que ilustra el tema. Él quería varias cosas: primero que indexase sus logs antiguos y segundo que estuviera escrito en un lenguaje "de verdad" (sic) en vez de en python. Le respondí que, dado que yo no tenía logs antiguos no tenía necesidad de procesarlos y que estaba escrito en python por era más sencillo para mí. Le di, eso sí, varias pistas para que se escribiese su propio procesador de logs antiguos. Él se lo tomó muy mal, supongo que se sintió estafado. Quizás debí devolverle el dinero que pagó por él X-D

En fin, publicar software libre no debería ser trabajar gratis para tus usuarios. En todo caso trabajar gratis para ti. El programa debería cumplir tus expectativas y, si las suyas también se cumplen pues genial, pero eso no es lo importante :-)

[ Padre ]

Python y compromisos (none / 0) (#7)
por atopos a las Tue Sep 2nd, 2008 at 01:56:11 AM CET
(Información Usuario) http://los-pajaros-de-hogano.blogspot.com

Precisamente con este programa, el indexador de pidgin/gaim, tuve una mini-discusión con un usuario hace un par de años que ilustra el tema. Él quería varias cosas: primero que indexase sus logs antiguos y segundo que estuviera escrito en un lenguaje "de verdad" (sic) en vez de en python.

En cuanto a lo de Python está visto que el usuario en cuestión no se leyó este comentario de Graham X-D

En fin, publicar software libre no debería ser trabajar gratis para tus usuarios. En todo caso trabajar gratis para ti. El programa debería cumplir tus expectativas y, si las suyas también se cumplen pues genial, pero eso no es lo importante :-)

Es cierto, pero no está reñido con lo que dije antes. Cuando alguien hace un programa que le gusta, le gusta también que ese programa funcione lo mejor posible y en todas las situaciones posibles. Los usuarios del SL, cuando son inteligentes, hacen las veces de auténticos colaboradores del programador, al desenterrar en su software problemas que él mismo no había previsto y cuya existencia demuestra que el software debe revisarse, ya para corregir un error, mejorar la interfaz, completar la lógica de sus requisitos, etc.

Tú te refieres más bien al usuario chupóptero y lerdo que se mueve por ahí fastidiando a los que trabajan por gusto, también a los usuarios que he llamado antes inteligentes.

Piensa que todo lo que dije en mi respuesta anterior va siempre referido al tipo de usuario inteligente y comprometido con el proceso de desarrollo, y que, por tanto, es consciente de que no se deben pedir peras al olmo, porque no sólo es de mala educación, sino porque es absurdo. A este usuario no se le va a ocurrir nunca forzar a alguien que está haciendo el trabajo por gusto y con frecuencia en su tiempo libre. Entre otras cosas porque a él también le habrá llevado su tiempo determinar donde está el problema e informar de él de modo adecuado y útil.

Es cierto que en el SL hay usuarios pelmazos, sobre todo a medida que se va extendiendo su uso, pero también hay muchos de los inteligentes, y éstos sí son, en mi opinión, un componente importante en el proceso de desarrollo de este tipo de software y un acicate para el desarrollador.

[ Padre ]

Todas las situaciones es mucho trabajo (none / 0) (#8)
por jorginius ("jorginius" en Google Mail) a las Tue Sep 2nd, 2008 at 03:47:13 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Es cierto, pero no está reñido con lo que dije antes. Cuando alguien hace un programa que le gusta, le gusta también que ese programa funcione lo mejor posible y en todas las situaciones posibles.

Sí pero si yo no necesito esa opción es lógico y el usuario debe entender que lo ponga al fondo de la bandeja de pendientes, por mucho que a él le parezca prioritario. Si tan necesario le resulta siempre puede parchearlo él mismo o bien dar incentivos, no tiene razón para molestarse ni para esperar que el autor trabaje para él gratis... Y el autor tampoco debería "malcriar" a los usuarios. No se puede contentar a todo el mundo y si les das hoy la mano mañana se llevarán el brazo :-)

En el caso de GaimDS era una buena idea que indexase los mensajes antiguos pero yo no tenía necesidad y no me apetecía investigar cómo y dónde guardaba los logs un programa de mensajería que no usaba en una plataforma de la que tampoco era usuario. De la misma manera entiendo que si no trabajas con python es una molestia tener que instalarlo sólo por un plugin, pero ese tampoco era mi problema. Además la alternativa en C no es que sea difícil de escribir pero sí es engorrosa, tal y como he explicado aquí.

Supongo que la prioridad se puede modelar como "necesidad / esfuerzo": la necesidad del que hace el trabajo respecto al esfuerzo que le supone implementarlo. Por ejemplo en GtkAtlantic un japonés se me quejaba de que no podía escribir en su idioma en el chat del servidor de partidas. A mí no es que eso me quitase el sueño (con ISO-8859-1 no había problemas) pero dio la casualidad de que no tenía nada mejor que hacer y el arreglo era muy sencillo: ahora soporta unicode. Si hubiera sido un trabajo de chinos seguramente no lo hubiera hecho nunca o tendría que haber esperado a vacaciones o similar.

Es cierto que en el SL hay usuarios pelmazos, sobre todo a medida que se va extendiendo su uso, pero también hay muchos de los inteligentes, y éstos sí son, en mi opinión, un componente importante en el proceso de desarrollo de este tipo de software y un acicate para el desarrollador.

Bueno, evidentemente me he ido a un tipo de usuario "pelmazo" porque son los que "impiden" que publiques más cosas.

Antes comentabas que había usuarios que imponían obligaciones y que, por eso, muchas personas se echaban para atrás. Los usuarios "responsables" no imponen, es más: facilitan tu trabajo haciendo que crezca el proyecto. De hecho si no fuera por este tipo de usuario o este tipo de feedback nadie se tomaría la molestia de publicar.

[ Padre ]

Pidgin y Google Desktop | 9 comentarios (9 temáticos, editoriales, 0 ocultos)

Menu

· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login


Nueva cuenta
Usuario:
Contraseña:

Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda