121 En las tripas de Archicad

121 En las tripas de Archicad

Graphisoft nunca ha sido muy partidario de dejarnos trastear con la API de Archicad. Tampoco es que esa API sea de fácil acceso, ya que está en lenguaje C++, increíblemente potente, pero para una élite de programadores. No es que la API estuviera cerrada a cal y canto, pero sólo era accesible a los desarrolladores y partners reconocidos por Graphisoft, y en general, se empleaba para el desarrollo de complejos addons producidos por no más de media docena de desarrolladores que se veían con fuerzas para meterse en las tripas de Archicad..

Detrás de esta decisión empresarial de Graphisoft subyace una de las causas por las que Revit se ha posicionado como el gran dominador del mercado. Autodesk tuvo la suficiente visión para reconocer el win-win que se produciría cuando se juntasen una API en un lenguaje usado por una gran comunidad de programadores como es C#, unido a una población de usuarios ávidos de implantar la última demanda de prestaciones para resolver ese problema propio o tener esa funcionalidad específica en su despacho. De ahí a una tienda de aplicaciones para Revit donde los pequeños addons suman miles, y que ha permitido a Revit superar sus muchas carencias a precio de saldo. En realidad, a Autodesk implementar mejoras le sale gratis. Lo hacen sus clientes por amor al arte.

Después de unos años de sostener una política empresarial que a todas luces se veía errónea, parecía que Graphisoft daba su brazo a torcer y permitía acceder de un modo limitado, eso sí, a la API de Archicad mediante un puente intermedio, Python, pero un puente, al fin y al cabo, que nos abre las puertas a entrar en las tripas de Archicad. Un lenguaje interpretado que tiene millones de desarrolladores capacitados. Pero pasado el tiempo se constata que ese movimiento fue un quiero y no puedo, a duras penas una justificación para decirnos a los usuarios “véis, ahí está lo que queríais, pero no lo usa nadie”. Sin publicidad, formación ni capacidades serias, el experimento estaba destinado al fracaso.

Pero de repente, los usuarios de Archicad recibimos una llamada en Twitter a participar en el desarrollo de un genuino y verdadero acceso a la API. Y para hacerlo más apetitoso, a través de programación visual con Grasshopper. Jorge Beneitez y sus mariachis se habían puesto manos a la obra y tocaban a rebato para que la comunidad haga lo que Graphisoft no quiere hacer. Así que nos hemos traído al mismísimo Jorge Beneitez y a uno de sus primeras espadas en este proyecto, Aitor Leceta, que ya estuvo con nosotros en el episodio 84 hablando de diseño generativo, para charlar del proyecto tAPIr y de las entrañas de Archicad.

¿Qué es el proyecto tAPIr?

Los usuarios de Archicad tenemos a Grasshopper como una herramienta para traer un poco de diseño paramétrico al entorno archicadiano, poco capaz para ese tipo de trabajos. Pero un día apareció un tuit de Jorge Beneitez anunciando la posibilidad de acceder a la API de Archicad a través de Grasshopper, con una llamada a la acción a través de un canal de Discord. Nos pedía participar en un proyecto llamado tAPIr. ¿Qué es el proyecto tAPIr y qué significa ese nombre?

Posibles e imposibles

Las cosas que se pueden hacer con una API no son ilimitadas. De hecho, actualmente, en Archicad tenemos un acceso a la API mediante JSON y Python, pero que en general tiene una funcionalidad limitada.

Si el camino que buscamos para entrar en las tripas de Archicad es mediante una herramienta de programación visual la cosa se complica un poco más. Así que cabe la cuestión de que al final, las enormes alforjas no se justifiquen para lo corto del viaje. En realidad ¿Hasta dónde llegan las posibilidades con la API? ¿Qué vamos a poder hacer y qué no?. 

Creando comunidad

Lo hemos visto anteriormente. Es más fácil caminar a hombros de gigantes que inventar la rueda un millón de veces. Apoyarse en una comunidad, o directamente crearla supone un factor crítico a la hora de crear y mantener el código de una aplicación. Como vimos con ifc.js, incluso lo puede convertir en algo rentable y apetecible.

Las formas de apoyarse en una comunidad son muchas. Puedes compartir el proyecto empresarial con esa comunidad, puedes implicarte en el mantenimiento del software open source en el que te apoyas, puedes igualmente colaborar dejando parte de tu desarrollo como software open source para que luego terceros lo sigan desarrollando. Así que ¿Cómo va a gestionar el proyecto tAPIr la enorme respuesta que ha tenido por parte de los usuarios de Archicad?

Hacia dónde vamos

Un proyecto de software tiene que tener un proyecto de empresa detrás. Ideas de cómo desarrollar el producto, a quién va dirigido, qué demanda cada tipo de cliente y cómo hacer que el producto sea rentable a largo plazo. Recientemente hemos visto la diferencia de planteamientos a nivel empresarial entre ifc.js y ifcopenshell, donde la existencia de un proyecto empresarial marca la diferencia entre uno y otro. ¿Cómo va a desarrollarse el proyecto tAPIr para ser rentable? ¿Cuál es su hoja de ruta como producto? ¿Qué funcionalidades pueden atisbarse en esa hoja de ruta?

Recursos citados en el episodio

• Proyecto tAPIr
• Repositorio proyecto tAPIr en github
• Grasshopper
• Airtable
• Speckle
• ifc.js
• Airtable Python Wrapper
• Mallard
• ¿Qué es una API?
• Archicad API
• Apuntarse al canal de Discord del proyecto tAPIr