PhotoCraft y el precio del software gratuito en la era de la IA
Una reimplementación independiente de Photoshop plantea una pregunta más amplia: cuando la IA facilita la creación de software, ¿quién paga la fiabilidad, el mantenimiento y el próximo gran avance?
Ilustración editorial original de Telli.sh. Es un diagrama conceptual, no una captura de PhotoCraft ni una previsión económica cuantificada.
Una aplicación creativa conocida, reconstruida públicamente y disponible sin suscripción: cuesta no entusiasmarse ante esa posibilidad. Para estudiantes, creadores ocasionales y personas a quienes las herramientas profesionales les resultan demasiado caras, el acceso gratuito puede marcar la diferencia entre tener una idea y poder llevarla a cabo. Pero el entusiasmo es solo el principio de la historia. Si la IA reduce sustancialmente el coste de recrear software, también nos obliga a preguntar quién seguirá desarrollando las capacidades que vale la pena recrear.
PhotoCraft vuelve concreta esa pregunta. Es un editor de imágenes independiente escrito en Rust, parte de la familia ArtCraft, desarrollado con ayuda de IA y diseñado para trabajar con documentos de Photoshop por capas. El cambio importante es que un equipo pequeño puede intentar crear y publicar una aplicación amplia y técnicamente exigente. Sus funciones anunciadas hacen tangible la ambición; queda por comprobar si funcionan con los documentos y flujos de trabajo de los que dependen los lectores. Proyecto PhotoCraft, Phoronix, 7 de octubre de 2026
PhotoCraft reconstruye flujos de edición conocidos
PhotoCraft es un proyecto independiente, no un lanzamiento de Adobe. Su repositorio anuncia capas, máscaras, capas de ajuste, texto editable, vectores y flujos de trabajo PSD/PSB. En su evaluación de paridad del 10 de octubre de 2026, el proyecto sigue en fase alfa: sus responsables estiman una preparación para el trabajo profesional de alrededor del 45 % y dicen que el intercambio PSD con Photoshop aún no es suficientemente fiable para una beta. Son mediciones y estimaciones del propio proyecto, no una evaluación independiente. Repositorio de PhotoCraft, evaluación de paridad, 10 de octubre de 2026
Reimplementar comportamientos similares a Photoshop no es lo mismo que publicar el código fuente de Adobe. PhotoCraft describe su enfoque como una reimplementación de sala limpia. Una interfaz familiar puede facilitar el aprendizaje, pero la compatibilidad sigue dependiendo de los documentos, complementos, fuentes y flujos de producción que use cada lector.
El código se ofrece bajo los términos MIT o Apache-2.0, mientras que los avisos, los recursos incluidos y la marca requieren atención por separado. Una licencia de código permisiva no debe interpretarse como permiso para reutilizar todas las marcas o ilustraciones asociadas a un repositorio. Quienes contemplen redistribuirlo deberían consultar las licencias y los archivos de atribución reales, en vez de tratar «gratis» como una autorización universal. Este artículo no resuelve la situación jurídica de la ingeniería inversa en ninguna jurisdicción. Licencia y créditos, archivo de atribución
La compatibilidad es un flujo de trabajo, no un recuento de menús
La amplitud de funciones es solo una parte de la compatibilidad. En su evaluación del 10 de octubre, el proyecto informa que 133 de 256 archivos PSD de referencia creados con Photoshop superan su prueba de fidelidad actual y señala carencias de rendimiento, estabilidad, interacción y soporte del ecosistema. Son indicios útiles de pruebas en curso, no calificaciones independientes de todos los flujos de trabajo. Evaluación de paridad de PhotoCraft
Imaginemos que una diseñadora prueba una alternativa con un cartel sencillo. Se abre, la capa de texto sigue siendo editable y la exportación se ve bien. Es un avance significativo. Ahora imaginemos que la misma diseñadora recibe un archivo de cliente con perfiles de color poco habituales, recursos vinculados, efectos de complementos y una tipografía ajustada con cuidado. Esa segunda tarea plantea otra pregunta: si se mantienen las expectativas acumuladas durante años al intercambiar el archivo entre personas, equipos y versiones.
Empieza con copias y un flujo de trabajo acotado. Prueba con un cartel o una imagen de producto por capas: conserva el texto editable, ajusta una máscara, exporta un PNG y vuelve a abrir el proyecto y el PSD en las herramientas que usan tus colaboradores. Para trabajo con clientes, añade un perfil de color representativo, un recurso vinculado o un efecto antes de confiar en el intercambio. Comprueba cómo se gestionan las funciones no compatibles para evitar que el contenido se aplane o se descarte sin aviso.
Esta distinción no es un argumento contra el proyecto. Es la diferencia entre apreciar un logro y prometer en su nombre. Las alternativas tempranas merecen margen para mejorar, y los usuarios merecen información suficiente para decidir cuándo conviene experimentar. Sustituir esa relación por la palabra «terminado» no beneficia a ninguna de las partes.
El acceso gratuito abre oportunidades reales
El argumento más sólido a favor del código abierto empieza por quienes antes no podían participar. Una suscripción recurrente puede ser razonable para un estudio y difícil de asumir para alguien que hace un trabajo escolar, un boletín comunitario o ilustraciones de vez en cuando. Un editor accesible permite practicar, equivocarse y desarrollar habilidades sin convertir cada mes de aprendizaje en una decisión financiera. Eso importa aunque, al principio, la herramienta cubra solo una parte de las necesidades profesionales.
La disponibilidad del código fuente aporta otro tipo de acceso. Una comunidad local puede mejorar la compatibilidad lingüística. Un especialista en accesibilidad puede examinar una interacción que excluye a ciertos usuarios. Una institución puede conservar una versión útil sin depender por completo de la hoja de ruta comercial de un proveedor. Son beneficios posibles de una base de código abierta, no logros automáticos de un proyecto concreto. Solo se hacen realidad cuando alguien realiza el trabajo y el proyecto puede integrarlo y mantenerlo.
La competencia también cambia las preguntas que deben responder los proveedores establecidos. Si una alternativa resuelve bien las tareas cotidianas, los clientes pueden preguntar con más claridad qué aporta un producto prémium: capacidades más profundas, mejor soporte, colaboración fiable o un ecosistema excepcional. Una suscripción ya no se justifica simplemente por la ausencia de alternativas. Debe explicar el valor de la relación continua.
No hace falta fingir que todo el mundo quiere el mismo modelo. Algunas personas valoran una herramienta sin conexión que puedan conservar indefinidamente. Otras prefieren actualizaciones y soporte gestionados. Una organización pequeña puede combinar ambas opciones. El código abierto es valioso, en parte, porque amplía las alternativas, en vez de imponer una única teoría sobre cómo financiar o distribuir software.
Una réplica más barata no vuelve gratuita la innovación
No me preocupa que los usuarios puedan obtener software útil gratis. Es un beneficio que merece protección. Lo que me preocupa es que reproducir un flujo de trabajo existente y descubrir el siguiente flujo de trabajo valioso son inversiones distintas. Una réplica puede aprovechar un producto que ya resolvió muchos problemas de diseño difíciles. Aun así, alguien debe identificar problemas nuevos, asumir apuestas inciertas y cargar con el coste de los experimentos que fracasan.
La misma distinción se aplica después del primer lanzamiento. Mantener la compatibilidad con un sistema operativo que cambia no es una tarea puntual. Tampoco lo es investigar un informe poco frecuente de pérdida de datos, responder ante una dependencia vulnerable o verificar un formato de importación inusual. La IA puede ayudar con estas tareas, pero esa ayuda no hace desaparecer la responsabilidad. Alguien debe decidir qué es correcto, verificarlo y responder cuando una solución crea otro problema.
Un ecosistema puede parecer saludable mientras depende de una cantidad reducida de trabajo invisible. Los usuarios ven las funciones nuevas, pero no necesariamente al responsable agotado que clasifica cientos de informes. Una organización puede depender encantada de código gratuito sin financiar nunca su mantenimiento. Si una reproducción más barata reduce los ingresos sin sustituir los mecanismos que sostienen el mantenimiento, el resultado podría ser más aplicaciones disponibles y menos aplicaciones fiables.
Es un riesgo, no una predicción de que el código abierto destruya inevitablemente la innovación. Los proyectos abiertos pueden crear negocios, recibir subvenciones, atraer patrocinio y repartir el desarrollo entre organizaciones. Los proyectos comerciales también pueden descuidar el mantenimiento o encerrar a los usuarios en un mal servicio. La pregunta pertinente no es qué etiqueta garantiza la virtud, sino si el modelo de financiación recompensa con el tiempo el trabajo que necesitan los usuarios.
¿Por qué deberían pagar los usuarios si el código abunda?
Marco editorial original. Las tres responsabilidades pueden corresponder a uno o varios equipos; generar código no completa automáticamente ninguna de ellas.
Una respuesta consiste en separar el acceso a una capacidad de las garantías que la rodean. Un editor local gratuito puede ofrecer un valor considerable. Una distribución con soporte podría cobrar por versiones firmadas, actualizaciones probadas y ayuda con archivos difíciles. Un servicio colaborativo podría cobrar por almacenamiento, permisos, sincronización y recuperación. Son ejemplos de posibles modelos de negocio, no servicios que hayamos confirmado que PhotoCraft venda actualmente.
La capa de infraestructura me parece especialmente importante. Una función puede impresionar por sí sola y resultar frágil en el trabajo diario. Un servicio fiable requiere copias de seguridad que realmente se puedan restaurar, reglas de acceso claras, fallos observables y un plan para los incidentes. Cuando varias personas dependen de la misma información, el coste de un sistema no disponible o incoherente puede superar el precio de la propia función.
Pero «infraestructura» no debería convertirse en una excusa vaga para otra suscripción. Un proveedor debería poder explicar qué opera, qué ocurre cuando falla y cómo puede marcharse un cliente. El almacenamiento sin exportación puede ser una trampa. Prometer copias de seguridad sin un proceso de recuperación es quedarse a medias. La confianza se gana con compromisos concretos y cumplimiento reiterado, no poniendo la palabra «gestionado» junto al código abierto.
El servicio y la propiedad pueden coexistir. Los usuarios pueden conservar archivos en formatos estándar y copias locales mientras pagan por una colaboración fiable. Las empresas pueden aportar mejoras al proyecto original y obtener ingresos por operar el software. El modelo más saludable quizá ofrezca el código fuente y deje el servicio como opción, con costes de cambio derivados de una comodidad real y no de retener el acceso al trabajo propio.
El software personal podría volverse más práctico
Si la implementación se abarata, resolver problemas más pequeños empieza a merecer la pena. Una fotógrafa podría querer una interfaz organizada en torno a una tarea de exportación repetitiva, en lugar de una paleta universal de herramientas. Un docente quizá necesite una pantalla de revisión adaptada a una clase concreta. Un grupo de investigación podría preferir un flujo de trabajo que mantenga visible un paso específico de validación. Son direcciones plausibles, no la afirmación de que un agente personal ya pueda crear cualquier aplicación con seguridad.
Antes, un requisito tan específico solía acabar en una hoja de cálculo, una macro o una concesión dentro de un producto mayor. El desarrollo asistido por IA podría facilitar que esas concesiones se conviertan en interfaces diseñadas para un propósito concreto. Eso cambiaría el papel de la personalización. En vez de elegir entre ajustes que alguien había previsto, el usuario podría describir un flujo de trabajo y ayudar a dar forma a una pequeña pieza de software para ese fin.
La parte difícil es conservar las cualidades que hacen útil al software compartido. Una modificación personal puede dejar de ser compatible con actualizaciones futuras. Un asistente generado podría resolver el caso normal y gestionar mal una eliminación o una recuperación. Un flujo de trabajo que su autor entiende quizá resulte imposible de comprender para un colega. Por eso la personalización necesita límites, documentación y cambios reversibles, no solo un ciclo de generación entusiasta.
También hay que considerar cómo se distribuye la experiencia. Un usuario con confianza técnica puede inspeccionar una modificación; otra persona quizá no sepa distinguir un cambio inocuo de interfaz de un programa que lee archivos o envía datos a otro lugar. Si se extiende el software personal, los modelos de permisos comprensibles serán más importantes, no menos. Facilitar la creación no debe trasladar silenciosamente toda la carga de mantenimiento y seguridad a quien solicita la herramienta.
Claude Code Mods ofrece una pequeña muestra de esa dirección
Claude Code Mods es un ejemplo concreto de cómo un entorno personalizable puede transformar una herramienta. La documentación de Anthropic describe manejadores en JavaScript o TypeScript capaces de modificar elementos e interacciones de la interfaz en Claude Code. Es más que pedirle al modelo que responda con otro tono: permite que pequeños fragmentos de código remodelen partes del entorno de trabajo. Descripción oficial de Mods, consultada el 12 de octubre de 2026
La misma documentación advierte que los mods no están aislados y se ejecutan con los permisos del usuario. Eso hace que el ejemplo sea útil de dos maneras. Apunta hacia un software cada vez más personal y muestra por qué ese software sigue necesitando una base fiable. Una modificación cómoda no se vuelve segura automáticamente porque haya ayudado a escribirla una IA.
Para mí, PhotoCraft interesa menos como veredicto sobre un proveedor establecido que como pregunta sobre la próxima economía del software. El código abierto puede poner capacidades potentes en manos de más personas. Al mismo tiempo, siguen haciendo falta financiación para descubrir, mantener y operar con fiabilidad. A medida que la IA facilite recrear y personalizar interfaces, espero que el software se vuelva más personal y que la infraestructura compartida que lo sostiene gane importancia. Claude Code Mods ofrece una muestra modesta pero reveladora de ese futuro: la herramienta puede cambiar para adaptarse a quien la usa, pero alguien todavía tiene que hacer fiable el terreno que la sostiene.
Conserva un registro revisable de tu investigación sobre IA
Para quienes recopilan sus propias notas de investigación, Telli.sh es un espacio opcional para organizar el material y los resúmenes derivados. Crear un espacio de notas.