← Volver a la bitácora

Cómo proteger tu código al entregarlo, sin puertas traseras

El cliente necesita operar el sistema sin ti. Tú necesitas no perder tu palanca antes de cobrar. Hay una forma sucia de resolverlo y tres formas limpias.

Cuando entregas software a medida hay una tensión que nadie cuenta: el cliente necesita poder operar el sistema sin ti, y tú necesitas no quedarte sin palanca antes de cobrar. Las dos cosas son razonables y se estorban.

La salida fácil es sucia: dejar una puerta trasera, o un interruptor que apague la aplicación desde afuera. Es tentador porque resuelve el problema de una y nadie se entera.

El problema es «nadie se entera». Un sistema que puede apagar su proveedor sin que el cliente lo sepa es una bomba de tiempo: el día que se descubre —y se descubre— no hay explicación que sirva, y no la pagas solo con ese cliente.

Tres formas limpias que cubren lo mismo

La regla que sale de las tres es la misma: todo lo que el sistema hace, el cliente lo sabe. Puedes proteger tu trabajo tanto como quieras, siempre que no dependa de que el otro no se entere.

El efecto que no esperaba

Poner esto por escrito en la propuesta —qué está compilado, qué se entrega en cada fase, qué dice la licencia— hizo que la conversación de contrato fuera más corta, no más larga. El cliente que pregunta «¿y si mañana desapareces?» ya tiene la respuesta antes de preguntarla.

Y la cuenta sale: la entrega del proyecto de la agencia incluyó un manual de 17 páginas para que su encargado opere el sistema sin mí. Eso es lo contrario de una puerta trasera, y es la razón por la que me volvieron a llamar.