Hoy he leído un post en decabeza titulado Archivos fuentes, ¿se deben entregar? que me ha parecido muy interesante. Como mi opinión es bastante extensa, he decidido continuar la conversación aquí (weedo, espero que no te importe ;) ) Como el título indica, el tema versa sobre si se debe entregar el código fuente al cliente y si éste debe pagar un plus por ello.
Antes de nada, comentar que he estado en las dos bandas: programando para clientes hace tiempo y actualmente
externalizando muchos proyectos en mi agencia. Por lo tanto, mi opinión está basada en las dos experiencias.
Para ponernos en situación: vamos a asumir que cuando hablamos de código fuente hay una parte que corresponde puramente al encargo, y en muchos proyectos hay otra parte de “valor añadido” (porque se está utilizando un framework propio, unas librerías muy complejas, una clase que facilita muchísimo x tarea, etc). Entiendo que con la primera no hay problema, porque al fin y al cabo te pagan por eso, y es en el segundo caso donde sabe mal “regalar” nuestro trabajo. A partir de aquí pienso todo el rato en situaciones con este “código de valor añadido”.
Para mí, casi siempre se debe entregar el código fuente. Sino se hace así, el cliente está encadenado. ¿Qué le impediría luego al desarrollador pedir cantidades desorbitadas por cualquier cambio? En caso de que al cliente no le interese trabajar con el autor original, debe tener la posibilidad de modificar él mismo el programa o pasárselo a terceras personas. Obviamente habrá excepciones, por ejemplo desarrollos muy complejos donde se entra en un sistema de licencias para explotación.
Si el cliente puede (y debería) exigir los archivos, el programador también puede pedir una cantidad mayor. En el primer comentario del post original se lee “para entregarse los fuentes, tiene que haber mucho dinero encima”, y me consta que hay muchísima gente de la misma opinión. Si un programador tiene el derecho de pedir mucho dinero, obviamente el cliente tiene el derecho de preguntar qué está comprando:
- ¿una clase propia para validar un mail? ¿un gestor entero de contenidos?
- ¿y qué calidad tiene el código fuente? ¿tipo Grant Skinner o tipo estudiante de segundo curso?
- ¿está el código 100% libre de bugs?
- ¿es fácil de implementar? ¿es fácil de extender?
- antes de que yo ponga encima de la mesa el dinero ¿me vas dejar investigar a ver si merece la pena?
- y más allá del código en sí… ¿me puedes asegurar que es imprescindible utilizar ese código que aumenta tanto el presupuesto?
Intento ilustrar las preguntas anteriores con un par de ejemplos:
1) Yo como “contratista”, hago un encargo a un freelance que me pasa un presupuesto muy elevado porque incluye el código fuente de un motor de tweens que ha desarrollado durante 2 años. Habiendo librerías gratuitas tan buenas como GTween o TweenLite, me niego a pagar el coste (seguramente nadie lo haría)
Ahora lo hacemos extensible, por ejemplo, a un conjunto de Expresiones Regulares. El freelance se ha currado una librería durante meses con decenas de ellas, y piensa que el cliente podrá aprovecharse de ello para otros proyectos. Yo dudo si pagarlo, porque considero se pueden encontrar en google de manera más o menos fácil.
Y lo hacemos extensible a un algoritmo que se ha inventando Yugop para deformar imágenes y que no se consigue en ningún lado y blablabla y yo lo pago encantado.
¿Qué marca el límite sobre lo que es fácil de conseguir y lo que no? ¿qué es reutilizable y qué no? ¿qué es único y qué no? Y más importante, ¿tienen nuestros clientes un nivel de conocimientos suficiente para tratar estas cuestiones?
2) Un cliente me contrata para un proyecto. Decido utilizar mi package de utilidades, que simplifica un montón de tareas y me permitirá hacer el trabajo en 5 días. El cliente se niega a pagarme el código, así que yo rehago el presupuesto sin incluir mis “utils”, lo voy a hacer todo de cero. Esto significa que en vez de 5 estaré 10 días y que doblo el presu final. Para el cliente no soy competitivo y se busca otra alternativa.
Son sólo dos ejemplos, pero a mí personalmente me responden muchas cuestiones. Y aún más, vamos a alejarnos un poquito de la perspectiva flash, por ejemplo pensando que hacemos un site en html+css+php, ¿no entregas todo? ¿el programador php teme que utilicen sus clases? ¿que aprovechen el css para otro site?
Mi conclusión final es que como programador siempre voy a dar el código fuente, y como cliente no voy a trabajar con nadie que no lo entregue. Y no voy a exigir más dinero al darlo, y no voy a pagar más si me lo dan. Para mí la gracia del negocio está en el valor que aporta el programador. Si trabajo con una persona que me resuelve cualquier problema, si puede aplicar cambios sin estar 4 días, si al pedir un cambio de funcionalidad no tiene que tirar media web abajo porque la implementó con patrones, si el código está perfectamente documentado… eso sí que no me importa pagarlo. Y por contra, si el presupuesto es muy justo, pues se puede avisar de que se programará “rápido” (que no mal), que será más difícil de extender, poco modulable, etc.
Y en cuanto a nuestro trabajo de “valor añadido”, pues seamos listos. Si no se le quiere dar un plus al cliente, pues no metamos el package entero, simplemente las funciones/clases imprescindibles; si se utiliza un módulo que se puede reutilizar para otros proyectos, pues se crea un biblioteca de clases (swc); si paga las horas justísimas, pues no se comenta el código por falta de tiempo; etcétera etcétera.
Y obviamente, lo expuesto aquí es mi opinión. Cada uno es libre de valorar su trabajo y sus horas como quiera. Al final, como cada proyecto, cada cliente y cada programador es un mundo, se convierte en una ecuación de infinitas posibilidades. Por eso, se piense como se piense, lo importante es dejarlo todo por escrito desde el principio.
[…] A partir de ahora, ya no te vas a perder conversaciones tan interesante como esta: Código fuente, ¿se debe entregar? […]