Creo que como programador no te contratan solo por hacer un codigo, y de como esta hecho, es en ultima instancia es tu responsabilidad, como tambien estoy en ambas lineas cliente-trabajador, si esta mejor o peor hecho no me importa lo ultimo que quiero es que funcione.
Pero no solo existe esa necesidad para contratar a un programador o a un equipo.
Tambien se debe valorar, tiempo, autonomia( que puedas hacerlo sin que nadie este encima), versatilidad(poder cojer desde un html hasta la BD mas compleja). Y muchas mas razones.
Con lo que si mañana te vuelven a llamar o no el cliente, sera en base a un conjunto de experiencias, en donde muchas veces dar po no dar el codigo fuente ni influye, pero si digo que el hecho de tener que pagar mas por el codigo o la negativa de darlo puede ser un handicap a la hora de trabajar contigo.
Y honestamente, mi codigo fuente no creo que sea mejor ni peor que el de nadie, y nadie me ha mirado las lineas para decir cuanto vale, al peso?, como bien dices LLops. Pero si me han valorado por mi rápidez, capcidad de cambios, versatilidad y responsabilidad, y eso es lo que se paga, a no ser que hagas algo que tenga precio, que sea solo tuyo, y no lo tenga nadie, vuelvo a las palabras de LLops con el ejemplo de Yugop.
Ademas sinceramente no soy un Webmaster que mantengo un sitio dioss me libre, con lo que si doy el codigo fuente puedo hacer otro desarrollo nuevo que es lo que me gusta.

Y habiendo vivido ambas experiencias como cliente y trabajador entiendo que la mejor solucion para todos es dar el codigo fuente.

Si pactas porcentajes, (20% al empezar, 30% mitad de proyecto y el resto al acabar, por ejemplo), sí entiendo que hasta que no entregas el código no te pagan el resto.

Pero como siempre, todas estas cosas mejor hablarlas al principio porque ahora lo tienes complicado…

Yo no tengo problema en entregar el código fuente, entiendo que es parte del encargo que me hizo el cliente. Ahora bien, éste me exige el código fuente ANTES de pagar, pues afirma que el trabajo no está finalizado hasta que no le entrego el código.

Qué debo hacer? entregárselo todo y confiar que me pague, o exigirle el pago antes del código fuente?

Yo he cumplido buena parte de mi trato, el desarrollo fue finalizado dentro de plazo, y el cliente lo tiene en explotación.

Gracias!

Lo cuento solo como informacion adicional.

Un saludo

1) Muchos proyectos no necesitan ningún tipo de mantenimiento, como por ejemplo un microsite para una campaña publicitaria. Se terminan, y no hay más. Además está claro que “siempre” utilizaremos nuestro “framework” para ir más rápido, pero para eso lo fabricamos en su día y con nuestro sudor. Que alguien me explique para qué quiere un cliente el código de un micro de este tipo…

2) Si se trata de un proyecto grande y con mantenimiento posterior al desarrollo inicial, pueden surgir muchas situaciones distintas. Pero voy a resaltar un caso: imaginemos que el cliente nos pide una aplicación, por ejemplo, un configurador de viviendas. Como cada 6 meses querrán un configurador distinto, me creo un “motor” basado en xml o base de datos que contemple mogollón de condicionales, anticipándome a posibles y/o futuros problemas.
Esta herrramienta me costará muchas horas en principio, pero facilitará mi futura tarea para nuevos configuradores. ¿Debo dar el código fuente de este motor? Ni de coña, a no ser que el cliente me lo haya pedido expresamente y pague por ello.

3) Como se ha comentado, cada caso es un mundo. Todo debe especificarse en un contrato por escrito, y no en llamadas de teléfono o emails informales. Hacer contratos de licencias, etc

4) Me parece bien que el cliente sepa qué está pagando. Si quiere el código y lo paga, porque él mismo lo va a mantener, tiene derecho a conocer la calidad del mismo, si esta comentado, si es modulable, etc. Pero si no lo paga, como si le damos un .fla en as2 con código encima de botones y gotoAndPlay. Si el resultado de la aplicación es bueno, no se puede quejar ni exigir nada.

@Zarate: Me alegro de que tengas clientes tan “buenos” y honrados. Muchos no son así. Me parece una locura lo del svn (yo también lo he hecho y no lo vuelvo a hacer). Compatir el svn con un cliente es como estar currando frente a tu monitor y tener un notas detrás de tu espalda viendo lo que haces. Además seguro que hará comentarios y se meterá en tu forma de hacer las cosas (también me ha pasado). Otra cosa es que se pacte entregar el código del proyecto en ciertos milestones, o que tu cliente participe activamente en el desarrollo. Entonces sí lo puedo entender.

Principalmente, el precio. Cuando haces proyectos a precios muy bajos para poder conseguir al cliente no creo que se le haya de regalar el código. No tanto por el código en si sino por una manera de hacer. Cuando entregas el código fuente al cliente no sólo le entregas lineas de programación sino tambien una experiencia adquirida a lo largo de muchos proyectos. Cuando un cliente desea hacer una página web para tener presencia en la red, tu sadisfaces esa necesidad; es decir, el cliente paga por tener su web, su sitio en internet, no por el conocimiento que requiere ese trabajo. Es como si al ir a comprar un coche le pidieses al fabricante que te pasara los planos por si te interesa cambiar algo. Y así puede haber multitud de ejemplos. El cliente paga por un servicio. Si tu como desarrollador le quieres regalar tu manera de hacer al cliente como un valor añadido tuyo, adelante.

En segundo lugar, tu entorno. Como empresa, has de competir con otras empresas y si consideras que tu manera de hacer las cosas tiene un valor del cual el resto carece regalarlo implica que tus competidores se enriquezcan de tu saber hacer. Esto último podría sonar casi a Microsoft y otras empresas que crean aplicaciones cerradas pero no hablamos de aplicaciones para millones de personas si no de una página web. La cual una vez hecha y entregado el código al cliente, deja de estar en tu poder, que tu manera de hacer las cosas pueda llegar a tus competidores que se pueden enriquecer con tu trabajo.

En definitiva, pienso que cuando el cliente paga es por un servicio, por su presencia en la red y que si desea tu manera de hacer las cosas se ha de pagar aparte.

Una solución a medias en estos casos es la de externalizar la información de la web. Es decir, yo con la web al cliente le proporciono un motor con el que poder presentar su información y que dicha información se recoja desde fuera del motor para que el cliente tenga acceso total a cambiar cualquier dato. En flash los .xml cumplen perfectamente este cometido así como otros formatos y encaso de querer ampliar la web sin contar con el desarrollador original se le explica como hacerlo ya que el sistema sería modular.