Adaptación del modelo de desarrollo "Bazar" para sistemas "in-house" en empresas particulares

Este trabajo intenta adaptar el modelo Bazar a desarrollos que no necesariamente cumplen con las características del código abierto, internándose en las razones mismas de la motivación de los programadores (y los beta-testers, que tienen igual o más importancia) y replicándolas, con ligeras adaptaciones, para su aplicación en sistemas desarrollados dentro y para la empresa.

El desarrollo de sistemas en empresas particulares, en las que los desarrolladores son empleados de la empresa o trabajan como man-power, ha sufrido una evolución a partir de los primeros años del desarrollo en mainframe hasta la actualidad, para sistemas cliente-servidor, distribuidos y/o para Inter-Intranet. Sin embargo, los rubros que han recibido la mayor parte de la evolución han sido la organización y planeación del proyecto, en forma de metodologías que facilitan la administración del mismo. Sin embargo, hasta ahora las motivaciones de los desarrolladores no han cambiado mucho: se suele trabajar simplemente por terminar un producto, y a menos que el desarrollador en turno tenga acceso a diseñar y crear las partes críticas del sistema, es raro que el esfuerzo sea utilizado eficientemente.

Cuando se desarrolla un sistema "in-house", es decir, dentro y para la empresa, no existe la motivación de grupos de desarrollo en los que el producto final será vendido y por lo tanto tendrá competencia; en estos casos la motivación para imaginar y llevar a cabo nuevas características es suficiente para mantener al desarrollador altamente enfocado en el objetivo final. Tampoco existe en los sistemas in-house la motivación de recibir bonos especiales debido a volumen de ventas o aceptación del producto. De hecho, la motivación debe encontrarla el desarrollador dentro de sí mismo y suele depender del grado de complejidad del problema, la inclinación técnica y los gustos personales.

Sin embargo, el reciente auge del software de código abierto ha mostrado avances en proyectos de gran envergadura, desarrollados en sus tiempos libres de forma gratuita por gente que probablemente también desarrolla sistemas in-house y sin embargo a sus participaciones de código abierto le invierten mucho más tiempo y calidad de programación y/o diseño. La filosofía de desarrollo de código abierto en un principio floreció, podríamos decir, de forma silvestre, y ha sido más y más analizada a raíz del éxito de proyectos tan complejos como Linux, gcc y Apache.

A pesar de que Eric Raymond, en su ya mencionado ensayo "La catedral y el bazar", nunca define explícitamente los términos que él acuñó, es posible dar la siguiente definición de modelo "Bazar":

• Modelo de desarrollo en el que, a pesar de existir un plan del proyecto, el desarrollo se encausa por los caminos que vayan siendo encontrados y las necesidades sugeridas por el grupo de desarrollo y pruebas (los usuarios).
• Este modelo de desarrollo ha encontrado su mejor ambiente en los sistemas de código abierto, en los cuales existe una figura, el desarrollador principal, que en paralelo a la coordinación de nuevos esfuerzos se encarga de evaluar reportes de problemas y nuevas propuestas. Es éste uno de los puntos que Raymond considera claves: "para este puesto no se necesita una gran inteligencia, ni siquiera ser un gran programador. Se necesita siempre estar dispuesto a aceptar que en el pasado se ha elegido un camino erróneo y retomar todo".

Los cimientos de los proyectos de software de código abierto son:

1. El proyecto no puede nacer como Bazar; debe ser integrado a esta metodología cuando ya lleve un avance tal que haga usable la aplicación.
2. Aunque el desarrollo no sea una catedral, es útil que exista un "arzobispo".
3. Tener usuarios es decisivo para elegir el método Bazar: "dados suficientes ojos, todos los errores son evidentes".
4. Se deben publicar versiones beta tan rápido y a menudo como sea posible.
5. Siempre es mejor ser robusto y simple que genial y elegante.
6. Se debe, sobre todo, reconocer las buenas ideas de diseño provenientes de otros.
7. Por último, y no tan aparente, es necesario que el líder del bazar tenga ciertas facilidades para la comunicación y las relaciones humanas.

No cualquier proyecto de software puede ser adaptado para el método del Bazar; de hecho, una condición necesaria es que el proyecto por sí mismo atraiga la atención de los programadores; es, por lo tanto, necesario, que los usuarios crean firmemente en el proyecto. "Todo gran proyecto empieza siendo interesante".

Este es quizás el punto más controversial: algunos opinan que sentirse parte de un auténtico grupo creativo es suficiente para provocar que los usuarios empleen gran parte de su tiempo en desarrollar y regalar su código; otra explicación es el ego el que juega el rol principal, al basarse en el hecho de que los desarrolladores siempre intentan desarrollar la mayor cantidad posible de código para recibir el mayor reconocimiento posible. Incluso, se ha llegado a afirmar que es parte de la naturaleza humana el regalar sus creaciones y sentirse satisfecho. Todos estos argumentos tienen sus raíces en la psicología del ser humano, y sin embargo no es necesario conocer a Freud para darse cuenta de que el método ha tenido éxito.

Linux es probablemente el ejemplo más patente de que el método sí surte efecto: el tiempo en que fue desarrollado un sistema operativo completo, con tal cantidad de aplicaciones utilitarias y características (SMP, RAID, SCSI, todo tipo de filesystems, X Windows) no tiene precedente en la historia del software. Tampoco lo tiene el hecho de que varios gigantes del desarrollo, como Netscape y Apple, han decidido abrazar el método para algunos de sus proyectos, encontrando resultados de exitosos a moderados. Incluso Microsoft ha hablado de utilizar la filosofía de código abierto para algunos de sus productos. Es claro, pues, que esta nueva metodología de desarrollo ha encontrado terreno donde plantarse firmemente.

Es bien sabido que este modelo de desarrollo ofrece un número de ventajas. Algunas son:

• Tiempos de desarrollo mucho menores. Algunos proyectos –Linux, como el ejemplo más evidente- han avanzado tres o cuatro veces más rápido que si se hubieran desarrollado bajo otro esquema.
• Reporte de errores ("bugs") y/o su corrección en períodos mucho menores. Los beta-testers son a veces también desarrolladores, con la capacidad de corregir errores en el sistema.
• Retroalimentación. Es muy claro en estos proyectos cuáles son las características más deseadas y utilizadas, dado el número de personas involucradas en ellas.
• Gastos. Son prácticamente nulos, comparados con otros esquemas.
• Motivación. Quizás la ventaja más importante; el desarrollador siente que está siendo útil, sin sentirse aprisionado por las responsabilidades. Esto conduce, por supuesto, a menores tiempos de desarrollo, soluciones más brillantes, etc.

Sin embargo, hay también desventajas. Las más importantes son las siguientes:

• Si el proyecto no genera interés, puede no llevarse a cabo. Suele ocurrir que, igual que las películas malas, el sistema se quite de cartelera prematuramente.
• Patrocinio. En ocasiones, la falta de patrocinadores puede alentar el desarrollo. También, es común que tengan que comprarse licencias y/o especificaciones técnicas para la adaptación a ciertos ambientes.
• Credibilidad. El concepto de "software abierto" está cambiando en la mente de las mayorías; sin embargo, aún es posible atacar al movimiento con argumentos tales como "no se puede confiar en un montón de adolescentes con barros que decidieron hacer un programa".

No es necesario hacer una apología del modelo tradicional de desarrollo, dada su extensión en todo tipo de empresas. Baste decir que el desarrollo se basa en una serie de pasos bien delimitados, y que las tareas y sus duraciones son definidas por un jefe, que también determina quién y cuándo deberá realizarlas.

Los cimientos de esta metodología son:

1. Es necesario seguir una serie de pasos definidos y ordenados para llevar el proyecto a su terminación.
2. Estos pasos dependen del tipo de proyecto (cliente-servidor, e-commerce, tres capas) y de la plataforma.
3. Existen varias corrientes dentro de este modelo de desarrollo; sin embargo, todas coinciden en el ejercicio de la "tiranía benevolente".
4. Se deben respetar en todo momento los lineamientos de diseño si se desea cumplir con los tiempos fijados.
5. Sólo se deben publicar versiones cuando el sistema esté terminado al menos en un 90%.

Las principales ventajas del modelo Catedral son:

• Desarrollo ordenado. Todos saben qué tareas deben realizar y cuándo, dentro de un rango determinado de tiempo.
• Control del proyecto. Es posible evaluar porcentajes de avance y/o de retraso fácilmente, reflejando el trabajo realizado en un diagrama de Gantt o de Pert.
• Sencillez de manejo. En realidad, nunca es sencillo dirigir un proyecto; simplemente es más fácil cuando uno puede remitirse a los tiempos prefijados y no a las necesidades surgidas en el último momento.

Es evidente que no es posible simular todas las condiciones que permiten el desarrollo de software abierto dentro de una empresa; principalmente, existen compromisos que coartan el espíritu libre que reina dentro de proyectos "open-source". Algunas otras diferencias son:

• Los gastos tienen que incluir al menos la nómina. A estos programadores sí se les está pagando por desarrollar.
• Los compromisos se deben usualmente a requerimientos de las altas esferas de los usuarios; por lo tanto, alguien debe responder ante esta responsabilidad.
• El desarrollo tiene que basarse en un proyecto inicial, con tiempos aproximados. No es válido decir "terminaremos cuando terminemos".
• Los recursos disponibles no suelen tener experiencia en todos los ámbitos del proyecto: unos son expertos en bases de datos, otros lo serán en herramientas de desarrollo, otros quizás en diseñar procesos, comunicaciones, hardware, etc. Esto, de cierta manera, ata a los recursos a un ámbito del desarrollo.

Sin embargo, algunas de las condiciones que se dan en proyectos de software abierto pueden ser simuladas para generar un grado similar de motivación.

Es deseable que el proyecto sea un desarrollo completamente nuevo. Esto, porque cuando se modifican sistemas existentes y/o se les da mantenimiento, no es sencillo cambiarles la dinámica. En estos casos, debe utilizarse el modelo Catedral.

Otras características deseables para esta adaptación son: baja presión en las fechas de entrega, comprensión total de los alcances por parte de los desarrolladores, transparencia con respecto a la aplicación de controles internos de la empresa, etc.

Todas estas características ayudan grandemente a facilitarle el trabajo al líder u organizador del proyecto. Existen, sin embargo, tres factores motivacionales que deben existir:

• El proyecto debe ser interesante y útil para el desarrollador

El proyecto debe ser interesante y retador desde el primer vistazo; los sistemas de mantenimiento de tablas en bases de datos normalmente no cumplen esta condición. Por otro lado, normalmente es imposible que el producto sea útil para el desarrollador, dado que el sistema se desarrolla por lo general para alguien más (el negocio). Sin embargo, el programador debe poder ponerse en los zapatos del usuario final para encontrar por sí mismo el camino más fácil para conseguir los objetivos.

• Completa libertad de desarrollar en la cantidad y en el lugar elegido

La analogía clara es permitir que el desarrollador elija el módulo a desarrollar e incluso decidir si quiere integrarse al proyecto. Poco realista, pero es aquí donde entra en juego el "chamán" del proyecto, convenciendo a todos de la valía de su participación.

• Se busca reconocimiento como meta, o al menos camaradería

Esto es un ideal de todo proyecto (no sólo de desarrollo) y uno de los primeros consejos en los cursos de motivación al personal. Simplemente, es un objetivo "mágico" para el que no existen reglas de aplicación. Eric Raymond menciona que el líder debe tener el don de caer bien, para dar el reconocimiento necesario y generar compañerismo.

Los factores motivacionales son clave para los proyectos de código abierto, y por consiguiente de Bazar. Son, entonces, la base para la adaptación de tal método a las aplicaciones in-house.

A raíz de esta primer aproximación a la psicología del desarrollador Bazar, parece difícil adaptarlo al desarrollo tradicional. Sin embargo, una reorganización de las tareas diarias y varios cambios en el sistema de desarrollo pueden ser la solución:

• Cada desarrollador debe elegir, en un principio, el módulo que desarrollará

El orden de elección puede ser aleatorio, o basado en algún criterio que tenga que ver con la experiencia o el perfil.

• En un inicio, el proyecto se desarrollará bajo el método de Catedral, tomando como primer objetivo lograr un prototipo que funcione

Con esto, se consigue no empezar desde cero con la metodología Bazar. Esta etapa finalizará en cuanto exista una primer versión utilizable del sistema. Sin lujos ni detalles. Sólo que funcione lo realmente básico.

• Cada módulo tendrá una extensión de media a pequeña, tomando como límite máximo tiempos de veinte días.

Esto consigue hacer más interesante el proyecto y poder visualizar fácilmente metas intermedias.

• Una vez conseguido el prototipo, cada desarrollador determinará el tiempo máximo en el que publicará los últimos cambios al módulo, aún si éste no está terminado. Estos tiempos no podrán ser mayores a cinco días.

Consigna número uno: publicar rápido y a menudo.

• Dos veces por semana, cada desarrollador tomará el papel de "usuario" y probará un módulo desarrollado por alguien más. Por supuesto, también los usuarios tomarán parte en este proceso de pruebas, previa advertencia de que lo que están probando es una versión altamente inestable.

Esto logra dos cosas: multiplicar el número de ojos puestos sobre cada módulo, e integrar a cada miembro del equipo con todas las otras funciones del sistema

• Cada vez que un desarrollador termine un módulo, cambiará de función y se convertirá en usuario puro, hasta que otro desarrollador termine a su vez e intercambie su lugar.

Esto es quizás el punto más importante de la propuesta: todo desarrollador debe ser capaz de integrarse a cualquier parte del sistema, en la medida de lo posible. Esto tiene que hacer más interesante al proyecto. También resuelve un viejo problema de los sistemas desarrollados in-house: a menudo, cuando falla un módulo del sistema, sólo una persona en todo el equipo sabe de qué están hablando.

El desarrollo in-house puede llegar a ser terriblemente ingrato; la paga es la misma si se generan soluciones geniales o no; la presión es la misma sin depender del grado de complejidad del problema; el único reconocimiento que se otorga es un cambio de proyecto. Estas características generalmente provocan falta de motivación en el desarrollador, generando oficinas que parecen clonadas de la de Dilbert. Es por esto que hay que buscar nuevos esquemas de desarrollo, que busquen explotar la razón primaria por la que los programadores se dedican a eso: por amor a las computadoras, por el gusto de crear.

Cada proyecto, por supuesto, tiene sus particularidades que lo hacen único; sin embargo, es posible que a través del uso de este método de organización del trabajo se logren mejores tiempos de desarrollo y mayor motivación en el equipo. O probablemente signifique un cambio en la rutina de desarrollo, lo que consituiría ya un cambio positivo. Lo que en realidad importa es que el proyecto parezca cobrar vida propia, como aquéllos desarrollados en Internet por cientos de programadores trabajando ordenadamente y en forma cooperativa. Y de noche.