En la evaluación de la primera semana de octubre de su propio repositorio, el equipo de PhotoCraft escribió que la paridad real con Photoshop “is still well below 50%” (sigue muy por debajo del 50%). Calculaban que un profesional podría cambiarse para el trabajo diario en algo entre 25% y 35%. El 10 de octubre volvieron a medir: después de unos 700 PRs, ponen esa cifra en cerca de 45%, entre 40% y 50%. Sigue sin llegar a la mitad.

Lo dicen del proyecto que usan Raymond y Naval para hablar de la muerte del software cerrado. Está en su roadmap, y vale la pena leerla antes de reaccionar al ruido.

Qué es PhotoCraft, y qué dice de sí mismo

PhotoCraft es un editor de imágenes escrito en Rust, con capas, máscaras, estilos, filtros y soporte de archivos PSD reales. Es de código abierto con licencia MIT o Apache-2.0, y se declara en “early alpha” (alfa temprana). Su README dice que es una reimplementación clean-room, “implemented from public specs and observed behaviour only. No proprietary code, shaders or assets” (hecha solo desde especificaciones públicas y comportamiento observado, sin código, shaders ni recursos propietarios).

Sus reglas internas prohíben copiar código propietario, usar fuentes descompiladas o código filtrado. Y en su hoja de ruta anotan que algunos formatos de cámara siguen bloqueados “by clean-room limits” (por límites del clean-room).

Aquí hay que ser justo con las dos partes. Lo que puedo leer son las reglas y las declaraciones del proyecto. No puedo auditar si se cumplieron, y desde un README nadie puede. Un clean-room en sentido estricto separa a quien estudia el producto original de quien escribe el código nuevo, y no encontré documentada esa separación. Tampoco encontré evidencia de que se haya violado.

Lo que dijeron Raymond y Naval

Eric S. Raymond escribió que “the end of software secrecy is almost upon us” (el fin del secreto del software está casi aquí), y contó que logró descompilar con ayuda de IA un juego de DOS. Según el análisis de explainx, lo que Raymond sugirió sobre PhotoCraft (que salió de descompilar Photoshop) es especulación suya, y el proyecto dice haber trabajado de otra forma. Ese análisis tampoco encontró documentado el proceso de desarrollo.

El 7 de octubre Naval lo citó y escribió: “Models are the last moat in software” (los modelos son el último moat, o ventaja competitiva, del software). Agregó que la IA puede reescribir ensayos, descompilar software y recodificarlo, pero que los modelos no quieren ser “distilled” (destilados, o sea, copiados entrenando otro modelo con sus respuestas). Y espera que más software “retreat to the server” (se retire al servidor) para resistir eso.

Es una apuesta razonable para un producto que es un modelo. Para casi todo lo demás tiene un problema: esconder el código en un servidor oculta el código, no el comportamiento. Y el comportamiento es justo lo que una reimplementación desde la especificación copia.

Lo que se puede copiar y lo que no

Mira lo que PhotoCraft logró según sus propios números. Abre archivos PSD reales y los guarda sin perder el contenido: 169 de 169 archivos de su corpus de prueba se reimportan idénticos. Esa parte es especificación pública más trabajo.

Ahora mira lo que no logró, según el mismo documento. Faltan 14 herramientas. Cero funciones de IA generativa. Casi nada de ecosistema: sus plug-ins no son compatibles con los de Photoshop. Y algo que me parece lo más revelador: dicen que muchos arreglos pasaron sus pruebas pero no han sido validados por usuarios, y que los primeros días de uso público mostraron problemas básicos que sus pruebas no veían.

Eso último no está en ninguna especificación. Es el trabajo de años de usuarios reales golpeando casos límite, y de un equipo que los arregla. Es lo que una reimplementación tarda en reconstruir, aunque el comportamiento visible esté copiado en semanas.

Mi lectura, con confianza media: si tu producto se puede describir completo en un documento, hoy se puede reimplementar. Lo defendible es lo que no cabe en ese documento. Los datos acumulados de tus clientes. Las integraciones con sus sistemas. Los casos límite que descubrieron contigo. El soporte, y la responsabilidad contractual de que funcione. Y el equipo que sabe por qué el producto se comporta así.

Ya escribí sobre una versión de esto en el entorno de ejecución ya es un commodity, con el flujo de trabajo como lo que queda. PhotoCraft lo confirma desde el otro lado: copiar la interfaz es fácil, copiar el flujo que un profesional repite diez mil veces no.

Qué hacer si vendes software

Haz una lista de lo que tu producto hace y márcala en dos columnas. Una, lo que un competidor podría reconstruir leyendo tu documentación y usando tu producto. Otra, lo que no. Si la segunda columna es corta, ese es el trabajo del próximo año.

El servicio de Socio Tecnológico de IQ Source está pensado para empresas de software que prefieren mantener adentro el diseño del producto y el conocimiento del dominio, y contratar afuera la construcción. Ese reparto cobra más sentido si la construcción se vuelve más barata de copiar: lo que vale proteger es lo que ya está adentro. Empieza por la lista de las dos columnas, y si quieres compararla con otra mirada, la revisamos contigo.

Separa lo copiable de lo defendible en tu producto