Hace unos meses daba una conferencia en el FORMAN.
En la mesa en la que hablaba estaba mi buen amigo Victoriano Giralt; para el que no lo conozca, es una de las autoridades nacionales en servicios de directorio y OpenLDAP, además de ser administrador de sistemas en la Universidad de Málaga. También estaba Juan Fajardo, el vicepresidente de una importante empresa de alquiler de carne y huesped del evento -Novasoft tiene la concesión de la explotación del FORMAN-.
Decidí orientar mi conferencia hacia la búsqueda y selección de personal en empresas de software libre; mi ponencia fue recibida de forma distinta por el público; unos, encantado con lo que decía. Otros, despertando de Matrix. Otros -la minoría-, con cara de estar escuchando apostasía de la única religión verdadera. Al final de la conferencia, veía las cabezas de los responsables de algunas PYMEs asintiendo. El directivo de la «cárnica» -para los que no lo saben, una forma coloquial en determinados círculos de denominar las «software factories»-, por otro lado, manifestó de forma clara su total desacuerdo con las ideas que había manifestado.
Las ideas principales de la conferencia giraban en torno a que hay diferencias claras entre software libre y privativo, que hacen que la estrategia de contratación sea necesariamente diferente.
Comencemos por el principio: en una empresa de software privativo es necesario reinventar la rueda desde cero. A cambio, ganaremos dinero vendiendo licencias del código. Por otro lado, en una empresa de software libre podemos reaprovechar la ingente cantidad de código libre de altísima calidad existente en el mercado, acelerando el desarrollo. A cambio, podremos ganar dinero con muchas cosas, pero entre ellas no estará la venta de licencias. Como vemos, la empresa de software libre podrá aprovechar su ventaja competitiva en tanto en cuanto sus programadores sean capaz de aprovechar las ingentes cantidades de código libre existente. Y aquí empiezan los problemas.
En una empresa de software privativo, tenemos más flexibilidad a la hora de contratar programadores brillantes, o programadores fungibles. Podemos montar una empresa de software privativo contratando un ejército de Javeros monolenguaje, encerrándolos en una sala y haciéndoles remar la galera hasta que el programa esté listo. Este sistema funciona con las empresas cárnicas, y les va muy bien. Sin embargo, este modelo de negocio simplemente no funciona cuando tratamos el software libre: no podemos mandar un Javero monolenguaje a dar la consultoría y los servicios que serán la principal fuente de renta de una empresa de software libre.
Se me viene a la cabeza en este instante una empresa que tiene capital y contratos, pero no termina de funcionar porque intentan emplear el modelo de cárnica en desarrollos de software libre. El problema que tienen ahora es que han creado una cultura de empresa siguiendo el modelo de una cárnica grande. Por ello, aunque ahora contraten esporádicamente a algún programador de software libre, terminan quemándolo: no se puede nadar en contra de la cultura de empresa. Tienen el problema ahora de que no encuentran gente buena de software libre; quizás es que su cultura de empresa ya es conocida, y es incompatible con la forma de funcionar de la gente que precisamente necesitan.
No es el único tipo de empresa que existe. Tanto en las empresas de software libre, como en las de software privativo, hay otra cultura de empresa posible. Esta cultura de empresa es posible en software privativo, e indispensable si queremos aprovechar las ventajas del software libre.
Un programador de software libre debe ser capaz de aprovechar el código existente en Internet para nuestros proyectos de software libre. Esto significa que debe ser una persona que programe al menos C, C++, Perl y Python; ya que son los lenguajes en los que la mayor parte del software libre está escrito. Debe ser una persona con gran conocimiento de qué proyectos libres funcionan, y cuales no, para saber de donde se puede sacar código. Además, debe tener habilidades de comunicación y contactos que le permitan que si entra en los foros pueda preguntar a las personas apropiadas y que le respondan. He visto a Andrew Tridgell ayudar desinteresadamente a un desarrollador de software libre en un proyecto de empresa para una PYME malageña. No se debe minusvalorar lo que supone esto en proyectos reales.
Todo esto nos causa un problema: necesitamos programadores «top» si queremos una empresa de software libre. Mejor pocos y muy buenos, que muchos y mediocres. Si todavía consideramos que un programador mediocre y uno bueno producen a un ritmo semejante en orden de magnitud, quizás es que no hemos tenido en plantilla nunca a un programador bueno. En este caso, recomiendo la lectura de:
Afortunadamente, es fácil localizar los buenos programadores de software libre, y que tienen estos perfiles. Están consolidados, y son conocidos a través de los proyectos en los que colaboran. Podemos leer su código, para ver como programan. Podemos leerlos en las listas de correo, y saber como interaccionan en equipo con colaboradores. Algunos dirigen proyectos de software libre ya, y saben motivar y tratar a la gente. Cualquier programador de software libre consolidado programa varios lenguajes, y además sabe bastante de sistemas (algo atípico en los Javeros monolíngues, pero imprescindible para consultoría y para muchos proyectos)
Quizás el problema no es apenas contratarlos, sino retenerlos. La comunidad del software libre es más cerrada de lo que perciben tanto los miembros de la comunidad como los de fuera de la comunidad. Una mala experiencia se corre como la pólvora, y nos dificultará más contrataciones futuras. De hecho, puede cerrarnos la puerta de los mejores, que probablemente ya tienen trabajo, y a los que tendremos que conquistar.
Recordemos que las empresas de software libre basan su negocio en consultoría y en servicios. Por ello, necesitamos gente creativa, con pensamiento lateral, habilidad para entender escenarios complejos y solucionar sistemas complejos. La única forma de mantener a estos empleados es mediante gestión de teoría Y, así como premiando estas actitudes.
Esto está haciendo que muchos paradigmas estén migrando: cada vez hay más mercado en manos de empresas pequeñas, de poca capitalización pero beneficios interesantes. Las grandes -IBM, HP- llevan años “limpiando» el “pointy-haired boss» de Dilbert, migrando de
teoría X a teoría Y, y convirtiendose en proveedores de servicios. Es cierto que seguirá habiendo cárnicas; pero no es ni el modelo de negocio ni el nicho de mercado de una empresa de software libre. Una empresa de software libre debe ser más como un buffet de abogados que como el barco de los chinos delante de la costa californiana si quiere triunfar.
Technorati tags: recursos humanos,Software Libre
Enhorabuena David, una vez más lo has clavado, me ha encantado la claridad con la que has explicado la realidad del mercado tecnológico del software.
Por cierto, me apunto lo de «empresa cárnica».
Abrazos
Comprendo perfectamente cómo los que no te entendieron, no tienen ninguna posibilidad de entenderlo jamas, puesto que son incapaces de abordar los problemas desde distintos ángulos y para ellos el desarrollo es sólo traducir (de especificaciones a un lenguaje)….
Lo que nunca me he explicado es si de verdad creen que es eso en lo que consiste, ¿porqué no usan máquinas para hacerlo?…
Muy buena entrada, creo que expone claramente las motivaciones que tiene la gente que desarrolla soft libre y cómo identificarlos y retenerlos…. además creo que incluso en desarrollos de soft privativo y dado que el desarrollo es (por lo menos ahora)gran parte de artesanía, esa creatividad y pensamiento lateral es imprescindible, aunque lo normal es que en caso de disponer de gente con esas características normalmente no saben identificarla y mucho menos motivarla.
Una nota de humor negro, para mi «importante empresa de alquiler de carne» es un eufemismo, creo que es más claro si hablamos en términos tipo trata de blancas o proxenetas
Me parece muy interesante y acertado, el punto de vista de este artículo. He visto en otros artículos, que estás en desacuerdo con la visión «talibán» del software libre, y por eso entiendo que aceptarás otro punto de vista que espongo con la única intención de aportarlo, y si fuera para enriquecer, mejor que mejor.
No entiendo el dualismo que planteas entre gestión de de desarrolladores privativo asociado a cárnicas y desarrolladores software libre asociado a gestión de lo que en otro artículo nombras como tipo Y. Llegas a plantear «Esta cultura de empresa es posible en software privativo, e indispensable si queremos aprovechar las ventajas del software libre.» He sufrido en mis carnes «las cárnicas» y siento que es indispensable asumir esa cultura para ambos casos… me gustaría argumentar más mi posición en este sentido, pero tengo poco tiempo y quería aportar otra idea… hay muucho desarrollo software libre en Java y muy bueno, trabajo en entorno GIS y un ejemplo sería gvSIG, incluso hay gente que está desarrollando software libre en .NET… ¿porqué no??
Estoy de completamente de acuerdo contigo en que la cultura de empresa tipo Y debería ser empleada en las empresas de desarrollo de software. En todas.
No en la interpretación que tu haces de esta entrada en el blog. Lo que digo es que el modelo X en empresas de software privativo es posible -aunque no adecuado-. El hecho de que existen cárnicas prueba mi aseveración. Otra cosa es que para una empresa de modelo X es muy complicado aprovechar las ventajas del modelo de software libre; por lo que las empresas de modelo X se ven en clara desventaja a la hora de trabajar en entornos de software libre, frente a empresas de modelo Y.
El modelo X es siempre una desventaja cuando se trata de trabajo creativo. Pero en entornos como el software libre, la desventaja es demasiado grande, por lo que solo se hace a petición expresa de cliente, y como uso o dando el código, sin aprovechar las ventajas estratégicas del modelo.
Soy partidario del software libre, como concepto, pero usaré software libre en mis proyectos (además de que lo acepte el cliente) cuando cumpla los requisitos de calidad exigidos (incluida la documentación) y cuando tenga una comunidad estable detrás. Sigo sin ver las diferencias que indicas entre ambos tipos de desarrolladores, al menos en los entornos en los que me muevo. En GIS hay varias empresas muy fuertes, sobre las que hay una comunidad muy importante desarrollando aplicaciónes (ESRI, INTERGRAPH, SMALLWORLD), y te puedo asegurar que hay desarrolladores «top», en este entorno, con el mismo perfil que especificas para los desarrolladores de software libre. En este entorno se está utilizando mucho software libre, sobre todo por requerimiento de la admininstración pública, a partir de la directiva INSPIRE. En España es un caso paradigmático, el desarrollo del proyecto gvSIG. Volviendo el centro de la cuestión, entiendo que hay un problema estructural importante en las empresas de desarrollo de software (en concreto en España), como indicas muy bien en tu artículo, pero soy de la opinión que para la solución a este problema estructural, no es conveniente e incluso no tiene sentido (desde mi punto de vista) hacer distinciones entre desarrolladores de software privativo y sofware libre. Me imagino que tendrás conocimiento, pero yo si tengo referencias de empresas de software libre que «funcionan» y tienen una gestión de RRHH lamentable.
Con la filosofía que veo de tu comentario, no creo que aproveches las ventajas del modelo de software libre. Lo usas si te da más garantías que el software privativo, pero no como opción preferente (para ninguna de las soluciones privativas has exigido documentación al mismo nivel, ni una comunidad fuerte detrás. Las expresiones escogidas delatan a la gente…)
La ventaja del software libre como desarrollador es que no comienzas desde cero, puedes tomar código del ingente pool de código libre de calidad existente. Pero también hay código malo con licencia libre; por lo que es necesario ser capaz de discernir entre los dos.
El problema es que, para poder aprovechar esta ventaja, necesitas tener una serie de características que no son imprescindibles en el software privativo, pero sí en el libre. La capacidad para entender ingentes cantidades de código, cuya documentación puede no estar actualizada o ser inexistente, es una de ellas. Ser capaz de crear vínculos a través de correo electrónico o de foros con gente a la que no conoces personalmente es otra. Tener una reputación fuerte de persona que contribuye, para que cuando necesites ayuda y la pidas, te la de el propio autor del código sobre el que la necesitas, también es importante. Todo esto es crítico para el desarrollador de software libre si quiere aprovechar las ventajas del modelo. Si no lo ves, permíteme dudar de que hayas podido aprovechar estas ventajas; y que te limitas a emplear el software libre exactamente igual que empleas el privativo.
Mi preferencia no puede ser otra que la de cumplir de la mejor manera posible los plazos, los costes y la calidad definidos para cada proyecto. Al igual que no comparto la opción de utilizar software privativo, cuando hay una opción mejor en software libre (situación muy común, por cuestiones «políticas» que tan bien se da en la admon pública), tampoco comparto tener una opción preferente que no esté basada esclusivamente en una mejor resolución del proyecto, es más, estoy convencido de que esa manera de pensar, va a ir siempre en contra de cualquier «empresa», ya sea basada en software propietario o en software libre. Estoy convencido de las ventajas intrínsecas del software libre, para competir en igualdad de condiciones, teniendo en cuenta los parámetros de calidad, que desde mi punto de vista deben ser comunes para ambos tipos de software, incluyendo en estos parámetros de calidad la documentación, que es un factor importantísimo para la elección de una solución u otra, teniendo en cuenta el cumplimiento ineludible, anteriormente expuesto, en costes, plazos y calidad.
Los puntos que planteas como exclusivos del software libre, «crear vínculos», «persona que contribuye», los aplicaría igualmente para cualquier tipo de desarrollador. La capacidad de entender ingentes cantidades de código… no entiendo ese punto de vista… quizás habría que aclararlo, pero entiendo que en cualquier caso estamos hablando de «ingeniería» del software, y que la capacidad de síntesis y de análisis es aplicable como en cualquier otra ingeniería… o al menos debería serlo, independientemente de que el software sea libre o privativo.
Aunque estamos manifestando nuestras ideas de forma abierta (quizas por eso precisamente) decirte que está siendo un placer intercambiar mis puntos de vista contigo.
@gdepaz:
Nadie te discute cumplir de la mejor manera posible los plazos, los costes y la calidad definidos para cada proyecto.
De lo que hablamos es de, si hay que desarrollar una apliación, optas por hacer un desarrollo libre o privativo. El desarrollo de software libre tiene su modelo de negocio, que tiene su inconveniente -renuncias a una de las fuentes de renta-, y a cambio tienes una serie de ventajas, que solo aprovechas si tienes el enfoque adecuado; que incluye tener el personal adecuado.
Pero leyendo tus entradas, parece que me estás hablando de algo que no tiene nada que ver: usar un programa, u otro. Hablamos entonces de ser usuarios de software, y el escenario es otro. No se trata de lo que estabamos hablando, ya que para usar software no necesitas ser programador. En este caso el reaprovechamiento de código de otros proyectos y la posibilidad de colaboración es intranscendente, y la clave estaría en otros argumentos: independencia de proveedor, adaptabilidad al escenario de uso del SI del cliente, posibilidades futuras de desarrollos y adaptaciones a futuras necesidades, ciclo de vida, e historial de obsolescencia premeditada por el fabricante y potencialidad frente a ella; solo por poner algunos ejemplos.
Creo que por el «ansia» por defender mi postura, me olvidé de ponerte en antecedentes. La empresa en la que trabajo es una integradora (y yo me dedico a gestionar estas integraciones), no desarrolla software desde 0, si no que integra software (tanto libre como privativo) y realiza desarrollos a partir de la API de cada producto. No quiere esto decir que «uso» los programas, ya que estas integraciones requieren proyectos de desarrollo muy importantes, y sí hay que plantearse el reaprovechamiento de código (que sobre esto habría mucho que hablar) y la posibilidad de colaboración.
En el entorno GIS, no tendría sentido realizar un software desde 0, ya que hay software maduro, tanto privativo como libre. Desde mi posición y teorícamente, la elección de utilizar software libre o privativo para integrarlo y entregar la mejor solución al cliente, debería basarse en factores técnicos y de calidad del producto… lamentablemente esto no suele ser así.
Mi postura de que, en cuanto a los desarrolladores, no encuentro las diferencias que planteas entre ambos tipos de software, es porque en este entorno (y entiendo que no será el único en el que pasa esto), tanto para el software libre como privativo hay una comunidad muy importante de desarrollo. En ambos tipos puedes encontrar desarrolladores «top», e incluso desarrolladores que no tienen ningún problema de pasar de un tipo de software a otro y quizás este es el tipo de desarrollador, que desde mi punto de vista más valor pueden aportar ya que conocen y utilizan las ventajas de ambos.
Desde luego que si me planteara desarrollar algo desde 0, o si no tuviera las restricciones planteadas (coste, tiempo y calidad) siempre obtaría por software libre …
Hola David,
perdón por el offtopic..
Hace unos años acudiste a dar una charla sobre openMosix en la universidad de zaragoza (jornadas JETAI, organizada por una asociación llamada DirEuropa).. Fué un día fantástico, acabamos cenando en un bar.. Por estas tierras mañas guardamos buenos recuerdos de ese día.. En este océano de bits encontré tu blog y decidí saludarte :)
Firthunands
Tengo unos recuerdos fantásticos de aquella visita a Zaragoza. Vuestra recepción y el trato que me disteís fue excepcional.
Muchísimas gracias. :-)