El riesgo no empieza con la carta de renuncia. Empieza semanas antes, cuando el ingeniero todavia tiene sesion abierta en cada repositorio, todavia tiene acceso completo a los documentos de diseño, y ya ha empezado a pensar en lo que sigue. Esa ventana de tiempo es silenciosa, no activa ninguna alerta, y parece un martes cualquiera. Tambien es el momento en que una startup pierde el registro mas claro de quien construyo realmente que.
Lo que realmente sale por la puerta
Rara vez es el producto terminado. El repositorio de produccion suele estar bien: tiene historial de commits, un registro de cambios real, y mas de una persona que puede dar fe de el. Lo que desaparece es todo lo que lo rodea. Un repositorio privado creado para un primer prototipo antes de que existiera el repositorio "oficial". Un documento de diseño pegado en un correo personal porque Slack fallo ese dia. Una rama que nadie fusiono porque la funcionalidad quedo pospuesta, pero que aun contiene la primera version funcional de una idea que la empresa lanzo despues con otro nombre. Nada de esto parece importante mientras la persona sigue en el equipo. Todo se vuelve motivo de disputa el dia en que ya no lo esta.
Un cofundador tecnico que se marcha tras un desacuerdo es la version mas aguda de este problema. Dos personas pueden recordar los mismos seis meses de forma completamente distinta, y una vez que la relacion se ha roto, ya no existe un relato compartido de quien escribio que linea primero, de quien hizo el boceto que se convirtio en arquitectura, o de cuando una idea determinada tomo forma en realidad. Lo que queda es memoria contra memoria, y eso no es prueba.
No solo afecta a los fundadores. Un contratista que construyo la primera version de una funcionalidad antes de ser contratado a tiempo completo. Un becario cuyo proyecto de verano se convirtio, sin que nadie lo notara, en una pieza central del producto. Un freelance que dibujo el diagrama de arquitectura original. Todos ellos dejan el mismo tipo de vacio, normalmente sin que nadie lo note hasta que una disputa obliga a alguien a buscar una prueba que nunca se conservo.
Por que sellar "en los grandes hitos" deja el hueco abierto
La mayoria de los equipos tecnicos que piensan en esto, piensan en el momento equivocado. Se etiqueta una version. Se firma un contrato. Eso es lo que se sella, si algo se sella. La rama exploratoria que dio forma a la version, el primer prototipo que demostro que la idea siquiera era viable, el documento de diseño interno en el que realmente se basa la version: todo eso rara vez recibe el mismo tratamiento, porque nadie pensaba en una salida mientras todavia escribian codigo juntos. Eso es exactamente al reves. El material con el rastro documental mas debil es justo aquel del que un ingeniero que se va tiene el recuerdo mas claro, y a menudo el instinto mas fuerte de reclamar el credito.
Lo que el sellado continuo realmente establece
La solucion no es un equipo legal mas grande. Es tratar el sellado como una parte habitual de como se guarda el trabajo tecnico, no como un paso reservado para lanzamientos y firmas. En la practica eso significa un habito tan sencillo como una fusion hacia la rama principal: codigo fuente sellado con una cadencia regular en lugar de solo en el lanzamiento, un documento de diseño sellado el dia en que se comparte con el equipo en lugar del dia en que se finaliza, un primer prototipo sellado la semana en que se ejecuta por primera vez en lugar de meses despues, si es que llega a sellarse. Nada de esto depende de recordar que una salida pueda ocurrir. Solo necesita ser ya la forma en que trabaja el equipo. Segun el articulo 41 del eIDAS, un sello de tiempo electronico cualificado goza de una presuncion de exactitud sobre la fecha y hora que indica, y de la integridad de los datos que cubre. En Suiza, una firma emitida a traves de un proveedor acreditado por ZertES tiene el mismo peso legal que una firma manuscrita. A ninguno de los dos marcos le importa quien siga empleado cuando finalmente surge una disputa. A ambos les importa que se registro y cuando, que es justo la parte de la historia que no cambia segun quien la cuente.
Imaginemos a dos fundadores que construyen juntos la primera version funcional de un producto, y que se separan mal dieciocho meses despues. Si el primer prototipo y el documento de diseño que lo origino se sellaron la semana en que se escribieron, existe un registro fechado y a prueba de manipulaciones, independiente de la memoria o de la relacion actual de cualquiera de los dos. Si no se sellaron, la disputa se reduce a quien resulte mas convincente, una posicion en la que ninguno de los dos fundadores deberia querer estar.
Lo que esto no hace
El sellado no sustituye un contrato laboral ni una clausula de cesion de propiedad intelectual, y no resuelve una disputa por si solo. Una empresa sigue necesitando los acuerdos subyacentes que establecen, en primer lugar, a quien pertenece el trabajo producido. Lo que añade el sellado es el registro probatorio que una disputa realmente necesita una vez que esos acuerdos existen: la prueba de que existia, en que forma, y cuando, que ninguna de las partes puede reescribir en silencio una vez terminada la relacion.
Convertirlo en habito antes de la salida, no despues
Para cuando alguien presenta su renuncia, ya es tarde para empezar a sellar el trabajo que mas importaba. Las startups que evitan este conflicto son las que hicieron del sellado una parte de como guardan su trabajo tecnico desde el principio, igual que hicieron del control de versiones una parte de como lo escriben. Vea como funciona esto para equipos de software y de propiedad intelectual antes de que la proxima salida, prevista o no, convierta la pregunta en urgente.
