1. lo de entregar código depende de la licencia. lo que sí debe ser práctica y el que no lo hace está pagando la novatada, es precisamente especificar las reglas de la licencia. así como existen diferentes licencias, unas de open source y entre esas también existen diferentes tipos delicencia, otras de uso exclusivo, otra cosa es desarrollo ala medida, otras como lo s sistemas operativos donde por comprar windows no le entregan el código de windows, cuando se firma el contrato debe especificarse qué es lo que se entrega. si es und esarrollo a la medida, y no una herramienta que se vende a varias compañías, es posible que en el contrato que se firma y que las partes acuerda, puedfe que vaya lo de entrega de fuentes, y así mismo, que esas fuentes no se revenderán ni se usarán por terceros ni con otros propósitos que los que se establecen en el contrato d elicencia original.
y si el contrato está bien hecho, de hecho debería tener cláusulas acerca de transferencia delicencias, como qué pasa si deciden vender el sistema a otra compañía o algo así

más bien, en vez de mencionar buenas prácticas que asíc omo están acá están bastante incompletas, mencionar que para loq ue tiene qué ver con informática, así como existenm normas iso, también existen normas que tieen qué ver con la redacción de contratos, y eso sí debería ser buena práctica, y se pyede reglamentar simplemente estableciendo la certificación. si yo hago una herramienta y la voy a vender a varios entonces entrego las fuentes, y que aunque la legislación es débila cá en uestión de informática (no existen patentes der algoritmos, todo está cubierto como derechos de autor como obra literaria, y los casos legales son como los de jsuticia penal donde uno se pregunta dónde está lña justicia, que se demuestra la derivación de algo que se entregó con acuerdo de confidencialidad y lo revenden como si lo huebiarn hehco ellos), pues si no se establece que hay qué entregar fuentes, no se entrega fuentes. por otro lado puede que contratar con ciertas entidades sea requisito entregar fuentes. los de la c´ñamara de comercio no saben de lo que están hablando, y no debefrían opinar sin haberse enterado antes

2. mantenimiento es distinto a soporte. para eso están los contratos. sí, el hecho de hacer la aplicació no implica que sehaga soporte; para eso se establece en el contrato en qué consiste lo que hacela compañía o qué eslo que entrega, y tampoco incluye operación dela herramienta si eso no está en elc ontrato, y todo contrato de desarrollo se firma en base a unos requerimientos. si no hay requerimientos acordados por las dos partes, no tiene por qué hacerse. acá no hay buenas prácticas genéricas, porque no hay aplicaciones genéricas qu eincluyan requerimientos genéricos. Por otro lado, todo trabajo que sehace tiee garantía, y eso sí es ley y está reglamentado en el código de comercio, y no sólo para aplicaciones o programas sino para todo lo que está cubierto en el código de comercio. la garantía o lo que cubre la garantía debe es`pecificarse en el contrato, y eso incluye el arreglo del programa o el soporte o la capacitación sobre los arreglos o lo que sea. lo que cubra la garantía S´´I debe estar en el contrato. y la garantía no es implícita, y sí existe como ley, pero para evitar ambiguedades debe quedar explícito de qué es lo que cubre, cómo lo cubre y por cuánto tiempo

3. igual que punto anterior, eso se debe aclarar entyre desarrollador y cliente. no es práctica estandarizada

6. actualización de manuales: uno delos graves problemas en el desarrollo es hacer algo sin requisitos o requerimientos acordados. si no, hay ambiguedad tanto por el desarrollador como el cliente en cuanto en dónde termina el desarrollo. que el desarrollador haga algo chambón y diga ya terminé. o el cliente quiera que le haganc osas que no se habían acordado y el desarrollador sia con un proyecto indefinidamente en cosas que nos e habían acordado. lo de actualización del manuales y demás. se entiende que los manuales deben corresponder a lo que hace la herramienta y si la herramienta cambia los manuales dse deben ajustar, si es que el contrato incluía manuales, porque puede que en cambio sea una capacitación al personal, y que el personal haga los manuales. pero si el desarrollo no es indefinido, y a la herramienta no se le van agregar funciones con elt iempo, ni es un proyecto indefinido sino que se desarrolla y ya, este punto no se aplicaría. ni existe la obligación de cambiar la herramienta si no fue eso lo acordado, que sería como decir que tieen actualizaciones gratis indefinidamente. si no es eso lo que se acordó, por qué toca hacerlo así. eso depende de lo acrodado