La_empresa_ante_el_software_libre 7
7. La empresa basada en software libre.
7.1 Resumen del capítulo.
- Estrategias de desarrollo.
- Esponsorización.
- Apadrinamiento.
- Captura de cerebros.
- Servicios de valor añadido.
- Que debe ser libre y que debe ser "de pago".
- Modelo de desarrollo.
- La pirámide de desarrollo.
- Estrategias de desarrollo.
- Marketing y "venta" del software libre.
- Estructura y organización.
- Gestión de recursos humanos.
- Gestión de recursos materiales.
- Gestión de servidores de información.
Una vez sentadas las bases, vamos a pasar a describir el funcionamiento de una empresa orientada al software libre. Aunque, como hemos visto esto puede referirse tanto a que produce software libre como a que basa su actividad en acciones desarrolladas alrededor del software libre, vamos a centrarnos sobre todo en el primer caso, pues la mayor parte de lo que se exponga será de aplicación a los dos modelos.
7.2 Modelo de desarrollo.
Cuando una empresa se dispone a trabajar en torno al software libre, debe ser consciente de las consecuencias, tanto a nivel organizativo, como de metodología de trabajo, que debe asumir y hacer suyas. La primera , y principal es la de adaptar el modelo de trabajo de sus programadores al modelo de software libre.
Estrategias de desarrollo.
Pues el software libre ofrece un modelo de desarrollo contrapuesto al del software tradicional: los conceptos de planificación de trabajos, reparto de tareas, integración, paso a producción, etc., difieren grandemente del modelo de una empresa cerrada, debido a multitud de factores:
- Puesto que el desarrollo es público, las tareas de depuración y publicación de versiones se deben efectuar en paralelo con las tareas de desarrollo.
- Se deben habilitar canales de comunicación con los desarrolladores, establecer una política de distribución de versiones, y un sistema de feed-back desde Internet a la empresa.
- Hay que estar abierto a la posibilidad de que en función de las demandas de Internet, el desarrollo original pueda sufrir cambios drásticos.
Todas las fases de desarrollo del software libre están descritas y documentadas en el artículo "la catedral y el bazar" de Eric S. Raymond, por lo que no nos vamos a detener en exceso aquí. Simplemente haremos algunas anotaciones:
- El "bazar" es un sueño imposible...
Si bien el modelo bazar funciona aceptablemente bien en entornos no empresariales, una empresa no puede dejar al azar el desarrollo y evolución de su software. Deberá permitir flexibilidad, nuevas prestaciones, incluso reestructuración completa del desarrollo, pero siempre debe hacer que el proyecto esté dirigido a sus intereses. Por ello el modelo bazar "puro" no es aceptable, sino que el grupo de desarrolladores de la empresa debe asumir las funciones de un "supervisor de proyecto".
- "Cambio programador por analista de sistemas".
Vamos a hacer un alto en este punto. Aunque casi todas los artículos existentes hablan sobre la libertad y aleatoriedad de los desarrollos de software libre, lo cierto es que siempre hay detrás una mente que es capaz de coordinar y dirigir el proyecto a buen puerto. En muchas ocasiones no es sino el autor del programa original quien asume la labor de "director espiritual". En otros casos, es un consorcio, o una "junta directiva" quien decide la evolución del software. Es difícil que un director de proyecto "automático", tipo CVS pueda "atraer" suficientes adeptos como para poder hablar de un modelo bazar puro y duro. Por contra, la figura del coordinador, acaba siendo fundamental, y en un modelo empresarial es condición imprescindible para que el proyecto llegue a buen puerto.
Desde este punto de vista, el papel de los programadores en la empresa pasa a ser el de coordinadores, creándose de hecho una "junta directiva" que se organiza el trabajo. Dicho trabajo ya no es el habitual de un grupo cerrado de desarrollo software, sino un trabajo orientado al nuevo modelo. Así tenemos las siguientes tareas:
- Integración.
- Comunicación.
- Control de versiones.
- Documentación.
- Servicios de valor añadido.
- Relaciones publicas y marketing.
- Sistemas de información.
Como se puede ver, las tareas de programación y depuración son delegadas a la actividad en la red, dejándose para el grupo de desarrollo los temas relacionados con la coordinación y distribución. En un apartado posterior describimos el perfil y los roles del grupo de desarrolladores de la empresa.
- Canales de distribución.
Es evidente para el lector que esta organización depende fuertemente de los canales de comunicación de la empresa con los demás participantes de la cadena. Una empresa cuya conexión a Internet sea pobre, o que no sepa aprovechar los recursos de la red, mas vale que se dedique a otra cosa....
Porque el software libre vive por, para y de Internet. Es preciso garantizar que los usuarios y colaboradores están informados, que el servidor web y ftp funcionan. El responsable de comunicación deberá dedicarse casi por entero a garantizar que todo lo relacionado con el software llegue hasta el último servidor de correo existente. Es intolerable el menor fallo en la cadena de comunicación, pues la vida misma del proyecto depende de ella.
Del mismo modo, el responsable de marketing hará lo imposible por que el proyecto sea conocido: sabe manejar los portales y los canales de anuncio de noticias, mantendrá permanentemente actualizada la página web... como veremos posteriormente, dicha página puede convertirse en una de las principales fuentes de ingresos de la empresa.
- Estrategias de captación de voluntarios.
Para que un proyecto de software libre llegue a buen puerto, hace falta otro componente fundamental: los usuarios y voluntarios para el desarrollo. Es necesario que la empresa llegue a tener un plantel de colaboradores suficiente para poder llevar a buen puerto el proyecto. Existen diversas estrategias de captación de voluntarios, pero se pueden resumir en breves frases:
- El producto ofertado debe ser útil, y cubrir las necesidades de los usuarios. Esto que parece obvio, es frecuentemente olvidado, y dada la fuerte "selección natural" que se lleva a cabo en Internet, a menos que sea algo necesario, rápidamente estará condenado al olvido.
- Se debe partir de algo suficientemente atractivo como para que aquellas personas interesadas tengan algo a lo que acogerse. No vale de nada un mensaje de "busco interesados en realizar XXXX", sino que hay que decir "He hecho XXXX, y me gustaría que alguien lo probara". Muy pocos proyectos de software libre nacen "de la nada", sino que siempre hay alguien que realiza el desarrollo inicial.
- Hay que utilizar sin compasión técnicas de habilidades sociales, relaciones públicas , etc., con tal de mantener el interés del colaborador. Es necesario crear una identificación del voluntario con el proyecto, o de lo contrario se acabara como una "beta 0.9" mas de las que tanto abundan en la red. En el capítulo dedicado al "dilema del preso" y posteriores, se analiza el concepto de "masa crítica" en el desarrollo del software libre.
- Minimización de I+D: Un "Outsourcing" de facto.
La primera consecuencia de todo este proceso es que el papel del equipo de software de la empresa pasa a ser de coordinadores de proyecto. La figura del desarrollador se relega a Internet, y engloba las fases de desarrollo, ampliaciones y depuración. Podemos hablar de un Outsourcing del desarrollo software, en el sentido pleno de la palabra.
- Internet como servicio técnico.
Otra consecuencia del modelo de desarrollo del software libre es que el concepto de asistencia al cliente y servicio técnico queda también desplazada a la red. Una empresa inteligente hará uso de los recursos de la red para aprovechar y dirigir dicho empeño hacia su empresa: creara listas de correo, tendrá un programador dedicado a moderar dichas listas, pondrá las FAQ, HOWTOS, e instrucciones en su web, y hará lo posible por que dicha información sea distribuida de la forma mas eficiente posible. El ideal debe ser: "ninguna duda resuelta sin que aparezca el URL de la empresa". El hacer que el portal de Internet de la empresa sea referencia obligada para un proyecto de software libre es una fuente ingente de ingresos, tanto de publicidad directa en el portal, como de venta de servicios de valor añadido por parte de la empresa. El objetivo es conseguir una identificación entre el producto y la empresa, aunque dicho producto sea 100% software libre. Veremos en un apartado posterior diversas técnicas para conseguir este objetivo.
La pirámide de desarrollo.
En este modelo, y tal como vamos describiendo, se perfilan claramente una serie de escalas de actuación, con tareas y objetivos concretos. A continuación se describe el perfil de alguna de las partes.
- La empresa.
Al margen de los proyectos realizados en torno a fundaciones, universidades, o grupos que podríamos calificar de no-empresariales, la empresa de software libre asume el papel del responsable máximo del proyecto. Dicha responsabilidad no es tanto de "paternidad" o de "líder del proyecto" sino como "padrino". En efecto, la empresa provee de estabilidad al proyecto, proporciona canales fiables de venta y distribución, mantiene la disponibilidad de ftp, web y correo en torno al producto.... Como vimos en el primer capítulo, si el desarrollo es correcto, el nombre del producto queda irremisiblemente ligado al nombre de la empresa. En muchas ocasiones, los desarrolladores son programadores contratados por la empresa, en otras la empresa subvenciona el desarrollo, proporciona cobertura legal, etc.
- El coordinador.
El coordinador tiene un papel especial: podemos decir que ejerce de "Dios". Es difícil que un voluntario trabaje para una empresa, pero es muy sencillo hacer que trabaje para su líder. En el mas puro estilo de la sociología de las sectas sobre el coordinador recaen toda responsabilidad de mantener el proyecto vivo, de animar a los voluntarios, de proporcionar nuevas y nuevas versiones y prestaciones a una clientela ávida de noticias frescas sobre su software favorito.
La personalidad del coordinador es pues especial: en una fase inicial deben ser buenos programadores, pero una vez el proyecto alcance masa crítica, su papel pasa a ser el de relaciones públicas y de analista de sistemas. La mayor parte de los líderes de proyecto son buenos oradores, saben atraer la atención del público, responden personalmente al correo electrónico... posiblemente les quede poco tiempo real para desarrollar, pero también un buen líder sabe proveerse de colaboradores -a menudo compañeros de trabajo de la empresa- que asumen las tareas pesadas. Es tan importante este papel, que muchas veces buenos proyectos caen en el olvido por falta de un líder; o lo que es peor para la empresa: el proyecto es "robado" por otra empresa con mejores recursos. Como veremos posteriormente, el apadrinamiento de proyectos y el contacto de la empresa con el líder es fundamental, por lo que en general la mayor parte de los líderes de proyecto acaban trabajando para una empresa que vive de dicho proyecto: Redhat, Sendmail, PostGreSQL, etc...
- Los colaboradores.
En organizaciones no empresariales de software libre, frecuentemente el papel del líder está diluido en el "comité organizador". Incluso en estos casos el liderazgo está repartido en áreas de trabajo, aunque la "atracción" de un proyecto sin líder es menor. Salvo honrosas excepciones -Debian, por ejemplo- es difícil, y no está exento de problemas un desarrollo "democrático".
El papel de los colaboradores es por tanto el de responsables de área. Aquí sí se exige un fuerte nivel técnico y capacidad de abstracción. Son los colaboradores los que van a realizar el trabajo de integración, los que van a recopilar la información que les llegue de Internet... en unión con el coordinador -y atendiendo a la comunidad Internet- deciden la política a seguir.
Esta organización recuerda grandemente al modelo bazar. No es del todo cierto, pues el modelo bazar exige una planificación previa, y frecuentemente estos grupos trabajan sobre la marcha. Podemos hablar de este grupo como el destinatario final de la opinión de Internet... y de la empresa o fundación que tengan detrás.
Al ser un grupo relativamente pequeño, la comunicación y toma de decisiones responde frecuentemente a un modelo "comité". Usualmente trabajan todos en la misma empresa, aunque en ocasiones, la facilidad de comunicación que la red ofrece proporciona un modelo de "comité distribuido" al grupo de colaboradores.
- Los voluntarios.
El voluntariado constituye la fuerza de choque de un proyecto de desarrollo software. El flujo de comunicación entre el grupo de colaboradores y los voluntarios está profusamente documentado en otros ensayos, por lo que no nos vamos a detener aquí en detallarlo. Únicamente hacer hincapié en algunos detalles.
- El primero es la necesidad de que el voluntario este permanentemente informado del desarrollo del proyecto. Es misión del responsable de comunicación dicha tarea. Es necesario que el voluntario no se quede descolgado y que pueda sentirse copartícipe del desarrollo.
- El segundo es la necesidad que tiene de realimentación. Por experiencia personal, conozco como un proyecto se echa a perder por no atender las opiniones, quejas y sugerencias de los usuarios. Cierto que en última instancia los intereses de la empresa en el proyecto van a tomar la parte principal en el proceso de toma de decisiones, pero también es cierto que muchas veces la opinión de la mayoría de los usuarios suele en su conjunto ser más objetiva que la visión que la empresa tenga del proyecto. No se debe olvidar nunca que estamos trabajando con software libre, y que en el momento que dicho software no responda a las expectativas del usuario, el proyecto quedará abandonado.
- En este ensayo establecemos una diferencia entre voluntario y usuario. El voluntario participa en el desarrollo. El usuario utiliza el desarrollo. No conviene perder de vista esta diferencia.
- Los usuarios.
Porque el interés comercial del producto de software libre de por si, reside en la comunidad de usuarios y clientes potenciales del producto. Está claro que el voluntario se basta a si mismo, o utiliza los recursos de la red, para hacer que el software responda a sus necesidades. Por contra, el usuario suele utilizar los paquetes binarios, casi nunca compila el código fuente, y frecuentemente no utiliza sino el manual del usuario ( y no siempre ). Frecuentemente es el usuario quien hace los comentarios mas oportunos acerca de la apariencia, el modo de funcionamiento, las funcionalidades a añadir... y los errores evidentes del software. Mientras el voluntario busca eficiencia, el usuario busca funcionalidad. Un buen responsable de marketing, conseguirá que el usuario se convierta en cliente: comprando documentación, recibiendo cursos, e incluso mediante soluciones pre-instaladas.
Esta estrategia tiene además una ventaja oculta: si se consigue "enganchar" al usuario como cliente, este queda integrado en la cadena de producción, convirtiéndose de hecho en el departamento de control de calidad del producto.
- La competencia.
Finalmente nos queda una última parte en la cadena del desarrollo software: la competencia.
No debemos olvidar un hecho importante en el mundo del software: los conceptos de nichos ecológicos y de evolución , de tanta aplicación en biología, siguen siendo válidos al ser aplicados al software. En un mundo tan altamente competitivo, podemos decir que cada necesidad software tiende a tener un único producto que la cumbre. En los casos en que esto no es así, y hay varios productos compitiendo, se produce el fenómeno de "evolucionar para permanecer en el nicho", esto es, una carrera desenfrenada por añadir prestaciones y funcionalidades para no perder cuota de mercado. Tenemos ejemplos de dicha evolución en el entorno del software libre: las "guerras de los escritorios" en Linux o la búsqueda de un entorno ofimático libre...
La empresa pues, ante la competencia, deberá buscar, o bien desbancar a sus competidores, o bien desplazarse hacia un nuevo nicho, donde no haya competencia. Una tercera alternativa es la búsqueda de "pactos" de interoperatividad, pero normalmente no es una elección atractiva desde el punto de vista económico, pues implica un reparto de beneficios, y a la larga una pérdida de competitividad de la empresa menos "ágil".
Marketing y "venta" del software abierto.
Hemos llegado al núcleo del problema: ya tenemos una empresa organizada en torno al software libre, y con un producto. Ahora toca venderlo y ganar dinero. Pues, ¿cómo se puede vender un producto que es "gratis"?.
- Una primera aproximación consiste en ahorrarle al usuario trabajo, a cambio de un mínimo coste. El concepto de "distribución de paquetes" sigue este modelo. Un ejemplo concreto es el de las distribuciones binarias de Linux: si bien el usuario tiene en todo momento opción a crearse su propia distribución, el coste en horas, o en gasto de grabación del CD-Rom, le hacen que este dispuesto a pagar una cantidad simbólica por tener el trabajo ya hecho.
- La segunda alternativa es la venta de funcionalidades añadida: la licencia GNU permite enlazar aplicaciones libres con aplicaciones comerciales, siempre que la segunda no utilice otros recursos de la primera que no correspondan al API. Por ello es frecuente la venta de plug-ins, así como de productos que desarrollan aplicaciones específicas alrededor de un software libre ( manejadores gráficos, gestores de administración, front-ends, etc. ).
- Una tercera vía es la venta de documentación. Uno de los grandes problemas del software libre es la ausencia de una documentación fiable y -por la propia naturaleza del software libre- actualizada. Actualmente, el modelo de "documentación aparte" es adoptado por muchas empresas que trabajan con software libre.
- Por último, nos queda -por lo menos- otra opción: la de dar cursillos y entrenamiento a los usuarios. Hace poco saltó la noticia de que RedHat ofrecía unos cursos en los que se daba un diploma que acreditaba como "RedHat certiffied manager".... el paralelismo con otras empresas comerciales es evidente.
- Como efecto marginal, pero no desdeñable, es preciso destacar el papel que los responsables del proyecto tienen: conferencias, charlas exposiciones, etc., son también fuentes de ingreso para la empresa.
- Publicidad y distribución.
Para que todos estos métodos lleguen a ser rentables hace falta algo común a todas las empresas, tanto libres como cerradas: el producto tiene que ser conocido, y la gente debe ser convencida de que su posesión es una necesidad vital. El responsable de marketing es el encargado de esta misión. Existen diversas estrategias:
- El uso -y en ocasiones abuso- de Internet debe se una constante. Un aprovechamiento inteligente de la red hará que el software sea conocido por los clientes potenciales en cuestión de horas.
- No tenemos por que estar limitados a nuestro servidor. El convencer a los voluntarios de que mantengan réplicas (mirrors) de nuestro servidor, hará que las posibilidades de que nuestro software sea conocido crezcan exponencialmente.
- Del mismo modo es necesario conseguir que los portales de Internet reflejen nuestro producto. Es más, debemos conseguir que nuestro web se convierta en un portal.
- Este ultimo punto hace que aparezca una nueva fuente de ingresos: los ingresos por publicidad de otras empresas. Actualmente la mayor parte de los ingresos de Netscape se deben a la publicidad de su portal.
- Hay que saber vender. Hoy en día, el software libre está "de moda", y como veremos en otro capítulo, el uso de dicho software es "políticamente correcto". Una adecuada venta del hecho de que la empresa distribuya software libre, abre la puerta a instituciones, organismos públicos, universidades, etc., donde los condicionantes de la decisión de adquisición del software no son económicos sino políticos.
- Por último, hay que ser capaz de dar a los posibles clientes tareas de consultoría. El cliente no quiere un producto, sino una solución a su problema, y si no se produce abuso, normalmente no pondrá impedimento al pago de una determinada cantidad por lo que a todas luces es una mínima adaptación -a veces ni siquiera llega a tal- de un producto de software libre.
7.3 Estrategias de comienzo.
Todo lo dicho hasta ahora parte de la base de que la empresa tiene un producto de software disponible. Como es obvio, esto no siempre ocurre, sino que en ocasiones hay que proceder , o bien a un trabajo inicial de desarrollo, o a la liberalización de un software anterior, o incluso a la "captura" de un proyecto. Veamos en detalle estas técnicas.
- Esponsorización o apadrinamiento.
El primer método es el más sencillo -y en cierto modo el menos arriesgado-. Consiste en que la empresa invierte dinero en una fundación, o asociación, o incluso en un proyecto de investigación de una universidad, con el fin de financiar económicamente un determinado proyecto.
Claramente, una empresa que utilice esta estrategia no suele estar interesada en el proyecto en si, sino en derivar parte de su carga de trabajo a otros intereses más rentables. Podemos hablar de optimización de recursos de la empresa, mediante técnicas de "Outsourcing" camuflado.
En otro caso la inversión económica responde a otras necesidades o intereses. Un efecto curioso que se da en algunas empresas de software libre, ( caso de RedHat, o Netscape ) es que son consideradas como valores de bolsa, sujetos a cotización en el mercado. Antes de la Crisis de Netscape, la mayor fuente de ingresos que poseía dicha empresa se debía a sus operaciones en bolsa. En el caso de Redhat, las inversiones y subvenciones realizadas por grandes compañías de hardware y software, hacen que su valor en bolsa se dispare, llegando a tener una cartera de beneficios más que apreciable.
- Captura de cerebros.
Un segundo método consiste en que la empresa contrate a los coordinadores de un proyecto de software libre, asumiendo dicha empresa los fines y objetivos de dicho proyecto... en su propio beneficio. Los nuevos empleados disfrutan de casi total libertad para seguir el desarrollo, con la garantía de que van a cobrar por su trabajo. Muchos de los nombres famosos en el mundo Linux trabajan al amparo de empresas como RedHat o Netscape.
- Liberalización de software.
En ocasiones, la competencia hace que deje de ser rentable el mantenimiento y actualización de un producto. La liberalización del código fuente, proporciona una segunda oportunidad al producto, y una nueva fuente de desarrollo.
Hay que hacer constar que esta política de liberalización, rara vez se hace a través de una licencia tipo GPL: es norma casi general que el fabricante desee proteger lo más posible su inversión inicial, y por ello se aplican cláusulas de restricción de la distribución. Las restricciones más usuales son:
- Restricción a la distribución: se suele prohibir el uso comercial del código fuente liberado.
- Restricción al formato: los parches y añadidos deben ir aparte de la distribución oficial.
- Cláusula de terminación: la empresa puede restringir sin previo aviso el uso del software liberado, tanto en fuentes como en ejecutables.
La comunidad Internet está generalmente en contra de estas restricciones especialmente de la última, que ha sido adoptada por empresas como IBM y Apple. Claramente no son sino un intento de utilizar la fuerza de producción de Internet en beneficio exclusivo de la empresa.
- Captura de proyectos.
Nos queda aún otro modelo de introducción empresarial en el modelo de software libre. Tenemos un ejemplo clásico en el desarrollo del paquete PostGreSQL ( un gestor de bases de datos relacional cuyo copyright ha sido recientemente adquirido por InSight Distributions ).
En este caso, la empresa asume poco a poco la coordinación de un proyecto, hasta el punto en que los responsables originales del trabajo "ceden" las labores de mantenimiento del programa. Esto permite a una empresa integrar sus productos de pago en torno a un programa, que a pesar de ser libre, es mantenido y dirigido por la empresa. Aunque el carácter abierto de dicho software no se pueda perder, dadas las características de la licencia, su orientación futura dependerá en gran medida de los intereses de su nuevo patrocinador.
- Qué debe ser abierto y qué debe ser "de pago".
Con independencia de la estrategia adoptada, la empresa tiene que ser consciente de que un producto de software libre no basta de por si para la productividad. Es más, como hemos visto existen campos del desarrollo software donde el modelo de software libre no puede ser viable, debido a que no cumple la condición de masa crítica requerida para dicho modelo ( ver siguiente capítulo ). Estamos hablando de soluciones "a medida", o de programas muy especializados. la empresa utilizará los resultados del desarrollo de S.L. para proporcionar una base de lanzamiento de dichos productos.
Los contratos de outsourcing son pues un modelo idóneo de explotación del software libre. Al cliente no le importa tanto la condición de "libertad" del código, cuanto que le proporcione solución a su problema. Es aquí donde la empresa adquiere sus beneficios directamente del software, y donde el resultado del esfuerzo invertido en el software libre es directamente aprovechado por la empresa, con independencia de otras soluciones marginales.
7.4 Estructura y organización.
Todo lo dicho hasta ahora se refiere a procedimientos de trabajo en la empresa. Analicemos un poco la organización y gestión. Existe mucha literatura acerca de cómo hacer una empresa "orientada a Internet", y no vamos a profundizar en ello, remitiendo al lector a la bibliografía reseñada en el apéndice. Haremos en cambio hincapié en la gestión y control de los recursos.
- Gestión de recursos materiales.
Lo primero que caracteriza a una empresa de software libre es la escasez de recursos, tanto materiales como humanos. Esto es explicable si consideramos que dicha empresa delega en la red tareas básicas como los procesos de producción y distribución. La empresa de software libre posee generalmente un inmovilizado ( recursos materiales ) mínimo, y por contra dispone de una fuerte capitalización, bien mediante inversiones, financiación externa, etc. La mayor parte de las empresas actuales son objeto de especulación en bolsa, y algunas de ellas -caso de RedHat- son consideradas hoy en día como "opciones de riesgo" por los inversores bursátiles.
Las áreas de actuación y de inversión en recursos materiales de esta empresa se derivan hacia los campos de obtención de beneficios: se prioriza pues el departamento de Marketing, y el de atención al cliente. Se potencia el uso de la red, la publicidad vía Internet, y los mecanismos automatizados de respuesta al usuario.
Otra área de inversión constituye el desarrollo de servicios de valor añadido: documentación, soluciones al cliente, productos auxiliares, etc.
El perfil pues es el de una empresa de servicios en su acepción más extrema: el de una empresa que vive de, por y para Internet.
- Gestión de recursos humanos.
Visto el perfil personal y laboral de los responsables de un proyecto de software libre, es necesario concluir que la política de trabajo de nuestra empresa, debe diferir bastante de la de una empresa habitual. Se deberán poder aplicar técnicas de teletrabajo, permitir una muy grande libertad horaria, etc. Recordemos que en el software libre, aparte de la motivación económica existe una muy fuerte motivación personal, y a ella tampoco son ajenos los responsables del proyecto. Al coordinador de recursos humanos le corresponde encauzar las energías, y conducir la nave a buen puerto.
De hecho muchos proyectos de software libre se han venido abajo por una falta de organización y coordinación en la cúpula. En el mundo empresarial esto sólo es tolerable por la competencia... para apropiarse del proyecto.
- Se impone un control.
Por ello el responsable de recursos humanos deberá ser capaz de:
- Mantener el ritmo de trabajo y los plazos.
- Monitorizar el uso de la red, para evitar abusos.
- No olvidar las actividades relacionadas con el marketing que afecten a los desarrolladores: ferias, conferencias, cursos, etc.
- Decidir que tareas debe asumir el grupo de desarrolladores, y que tareas se deben delegar en la red.
El departamento de marketing y atención al cliente, deberá estar a su vez familiarizado con el "Estado del arte" del desarrollo, atender a las consultas de clientes y colaboradores.
- Gestión inteligente de servidores de información.
Como hemos visto, todas las tareas de trabajo y control, giran en torno a un componente principal: la red. Gracias a la red, la empresa consigue voluntarios, clientes, publicidad.... en suma, dinero.
Podemos observar que gran parte de las páginas web de proyectos de software libre abundan en publicidad. Es una publicidad inteligente, personalizada en función del visitante, que no sobrecarga el sistema, compatible con todo tipo de navegadores y entornos... la idea es conseguir ingresos, sin perder visitantes, ( esto, que parece obvio es olvidado por empresas "serias" ).
El servidor de información deberá disponer de listas de correo automáticas, adecuadas, y a ser posible moderadas por un responsable. Se deberá cuidar el mail-spamming, la corrección en el estilo. De ser posible, sólo una voz hablará de la empresa a través del correo. Las listas de correo deberán estar accesibles por Web y FTP.
Del mismo modo, toda la documentación libre deberá ser accesible de manera sencilla y directa. Las técnicas de "registro" previo deberían utilizarse sólo para los "clientes", y nunca para el acceso general. Se deberá dar cuenta en el menor plazo posible de toda novedad existente. Es vital que los servidores de información tengan un buen enlace con la red, y que se ejecuten en entornos seguros y fiables, y -por supuesto- basados en software libre.
Una cosa a evitar es el uso negativo de las estadísticas: aunque quedan muy "bonitos", debería huirse de contadores, y sobre todo de cualquier cosa que pueda ahuyentar a un posible voluntario o cliente. Mensajes del estilo "Bienvenido Mr. Pepito. Es la quinta vez que se conecta a nuestro web" producen reacción de rechazo en el cliente".
Es de agradecer que se establezca una metodología de trabajo: habrá que definir unas normas de estilo, un sistema tipo CVS para la gestión del software, etc... son normas básicas de coordinación de proyectos, que adquieren importancia fundamental cuando se va a coordinar un sistema de esta envergadura.
Página siguiente Página anterior Índice general