Yendo más allá con Inkscape 1.0, entrevista de Alexandre Prokoudine a los desarrolladores

(El artículo original y en inglés, fue publicado el 14 de mayo de 2020)

El 1 de mayo salió la versión 1.0 de Inkscape.
Algunos días después, el 14 de mayo, Alexandre Prokudine publicó una entrevista en Libre Graphics World a Bryce Harrington, Marc Jeanmougin, Ryan Gorley, Tavmjong Bah, Martin Owens y Alex Valavanis, desarrolladores del programa.
Con la ayuuda de deepl.com (y ajustándola según mi criterio) hice una traducción al español de ese artículo y lo publico a continuación.

Después de casi 17 años de trabajo, Inkscape 1.0 vió la luz.
Seamos justos: este es uno de esos casos en los que el humilde número de versión no representa lo que realmente incluye el programa. Como testigo puedo decir que ya era perfectamente utilizable desde el momento que se bifurcó de Sodipodi en 2003. El lanzamiento de la versión 1.0 debería haber ocurrido ya hace años, pero el equipo tomó un enfoque muy conservador.
Personalmente, hace alrededor de un año, dejé de usar Inkscape 0.92.x y me cambié a lo que luego se convirtió en la versión 1.0. Y, hasta ahora, me ha ido bien. Todavía tengo discrepancias con algunas soluciones de la interfaz de usuario, pero me doy cuenta de que se debe, en parte, al uso de un kit de herramientas que está bien para aplicaciones de escritorio genéricas pero que no es exactamente brillante para software especializado.

Mi impresión personal, si le interesa, es que el equipo actual está muy motivado para impulsar este proyecto en la dirección de hacerlo una mejor herramienta para los ilustradores. Pero las impresiones de los usuarios son una cosa y lo que los desarrolladores realmente piensan es, a menudo, otra cosa totalmente diferente. Así que es momento de entrevistarlos.

Supongo que sólo me queda una aclaración por hacer. Las respuestas a mis preguntas llegaron después de que se anunciaran los proyectos aceptados para el “Google Summer of Code”, así que al menos una de las preguntas podría no tener tanto sentido como sería de esperar. Además, todas las ilustraciones que acompañan el artículo son ampliaciones de la pantalla de "Acerca de" de Inkscape 1.0, obra de Bayu Rizaldhan Rayes.

En primer lugar, ¡felicitaciones! Este es un gran hito. Como un gran proyecto, con una base de usuarios enorme, supongo a que a menudo se sienten abrumados por las expectativas de la gente. Algunos quieren que Inkscape se convierta en una herramienta de animación, otros quieren más características CAD (con restricciones, inclusive), y la lista continúa.
Pero Inkscape comenzó con la misión de convertirse en EL editor de archivos SVG. Quiero decir, incluso el esquema de numeración de versiones se pensó para reflejar la cobertura de la especificación de la W3C, como 0.50 para el 50% de cobertura, etc. (aunque creo que esto nunca se llevó adelante). Actualmente, la página principal del programa ni siquiera menciona la sigla “SVG”.
Entonces, ¿cómo piensan que se presenta Inkscape en estos días?

Bryce Harrington: Después de haber publicado algunas versiones de Inkscape, un usuario publicó un dibujo fotorrealista de un brillante automóvil hecho con el programa - es el que probablemente ya hayas visto en la página de Wikipedia de Inkscape. Al ver cómo nuestros usuarios empleaban Inkscape, muchos de nosotros nos dimos cuenta de que su alcance era increíblemente amplio.

Junto con eso, aparecieron usuarios que no habían oído hablar del SVG antes de Inkscape. SVG era sólo un formato de archivo, uno de los tantos posibles que les interesaban. Estos usuarios veían a Inkscape no como un “editor de SVG”, sino como algo que resolvía necesidades de dibujo aún más generales.

En retrospectiva, hubo un momento en el que Inkscape cumplió de hecho con esa misión de convertirse en el editor estándar de SVG. En realidad no había muchas opciones para la edición con interfaz gráfica de SVG en ese entonces, así que cuando Inkscape se desarrolló se convirtió en el camino a seguir para la creación de archivos SVG. Incluso hoy en día, desde los grabadores láser hasta los desarrolladores de juegos, se refieren a Inkscape como una herramienta importante. Pero, al mismo tiempo, ha crecido todo un ecosistema de otras herramientas de edición y visualización de SVG para varios casos de uso.


Marc Jeanmougin: Yo tiendo a pensar en Inkscape como una herramienta de gráficos vectoriales multi-propósito. No es (todavía) LA herramienta para algún objetivo vectorial preciso, pero es una buena herramienta para iniciarse en los gráficos vectoriales, y una buena herramienta para lograr casi cualquier cosa en esta área (y las mejoras que tratamos de hacer en las posibilidades de personalización harán más fácil que Inkscape sea LA herramienta para objetivos específicos). Para mí, el uso de SVG es la única opción obvia de un formato de archivo abierto, editable a mano y amigable para la web, y queremos insistir más en ser una herramienta vectorial que en la discusión técnica.

Ryan Gorley: Inkscape terminará finalmente en la intersección de características bien documentadas y solicitadas con frecuencia y las capacidades e intereses de nuestros desarrolladores. De esta manera no somos como una empresa de software que está buscando mercados en crecimiento y planificando nuevas características en consecuencia. Hemos estado algo limitados por lo que es posible dentro del ámbito de las especificaciones del SVG, pero puede que no siempre sea así y, además, aún hay mucho que podemos hacer dentro del ámbito del SVG. En última instancia, iremos donde nuestros usuarios nos ayuden a ir involucrándose.

De hecho, ¿cuánto están dispuestos a modificar la especificación introduciendo un nuevo conjunto de características SVG para añadir capacidades que faltan en la especificación original? ¿Tiene algún tipo de política o acuerdo informal al respecto?

Marc Jeanmougin: No más de lo estrictamente necesario. Hay mucho que se puede hacer con el SVG, e idealmente sólo implementaríamos cosas que deberían estar en las especificaciones. De los agregados recientes, sólo las mallas no se pueden hacer de otra manera, y no son soportadas por otros visualizadores de SVG. Mucha gente (incluyendo muchos colaboradores de Wikipedia) confían en Inkscape para crear archivos estándar que se vean bien en Wikipedia, y sería perjudicial para el formato SVG y para Inkscape añadir características que se interpongan en el camino de este uso.

Bryce Harrington: Tu pregunta ha estado en primer lugar en la estrategia del proyecto incluso desde antes de que existiera. SVG, como cualquier protocolo, tiene sus limitaciones; particularmente para la gente que ve a Inkscape como algo más que un editor de SVG, esas limitaciones se sienten innecesariamente arbitrarias como para respetarlas. Sin embargo, atenerse a la norma, a pesar de sus idiosincrasias, fue de hecho una de las razones para establecer Inkscape, y eso lo diferenció de otras herramientas de gráficos vectoriales.

Por estas razones, el Proyecto Inkscape consideró que los esfuerzos de la W3C sobre el formato SVG eran cruciales para el futuro del programa. Conscientemente buscamos abordar las limitaciones trabajando dentro del comité. De hecho, gracias a las generosas donaciones de miles de colaboradores de Inkscape, pudimos asistir y participar en muchas de las reuniones del grupo de trabajo de SVG del W3C. Fuimos una de las únicas organizaciones de voluntarios que lo hizo (algo de lo que esta comunidad debería estar orgullosa de haberlo hecho posible). Tav, nuestro representante en ese comité, fue el autor y promotor de varias características importantes del SVG, varias de las cuales están ahora consagradas en la última versión del estándar SVG.

Uno de los beneficios más notables es que Inkscape puede utilizarse para crear contenido que luego se carga en otras herramientas o navegadores. Inkscape se toma en serio su papel como socio en un ecosistema mucho más amplio de programas gráficos de software libre. Ser capaz de interoperar con otros programas hace que el ecosistema en su conjunto sea más fuerte y poderoso.

Tavmjong Bah: SVG es un dialecto del XML y lo maravilloso del XML es que es extensible. No necesitamos romper el SVG para implementar cosas geniales como los Live Path Effects (que se alojan en el espacio de nombres de Inkscape). Los SVG multipáginas serían fáciles de manejar de esta manera.

La situación con el desarrollo del SVG no se veía muy bien hace unos años. ¿Cuál es su perspectiva para el estándar? Como proyecto que es una parte interesada evidente, ¿cuánto participan todavía en el grupo de trabajo del SVG de la W3C?

Tavmjong Bah: El grupo de trabajo del SVG todavía existe y la dirección del W3C se ha comprometido en apoyarlo... aunque lo que ese apoyo implicaría, aún estamos por verlo. A las reuniones quincenales asisten sólo unos pocos miembros y el progreso es lento. Una cosa esperanzadora es que hay bastante discusión en desarrollo en el repositorio de Git. Algunas características importantes para Inkscape, como los gradientes de la malla, han sido pospuestas para después del SVG 2.

Bryce Harrington: Afortunadamente, el SVG está diseñado para ser extensible, así que al menos el formato “SVG de Inkscape” puede seguir siendo mejorado para los usuarios de Inkscape. El problema será la pérdida de compatibilidad con otras herramientas basadas en SVG, como los navegadores web. No está claro qué se puede hacer para resolver esto mejor, esperemos que aparezca gente inteligente con algunas buenas ideas.

Martin Owens: Diría que estamos en el punto de apoyar al SVG tanto como sea posible, pero mayoremente hemos renunciado a tratar de añadir características de edición a la especificación SVG. Ya que la W3C está dominada por los navegadores web que no necesitan multipáginas o conectores.

No me atrevo a decir mucho más sobre las cosas específicas de la W3C. Sé que estoy personalmente decepcionado de que la considerable importancia de Inkscape en el espacio de creación de SVGs no le permite conseguir que las características que pretendemos incorporar a Inkscape se incorporen a la especificación real del SVG. Esto nos lleva al problema de que al seguir adelante es probable que tengamos incompatibilidades con navegadores web (¿qué mostrará un navegador de un SVG multipágina?). Pero esta no es la posición oficial de Inkscape, es solo mi opinión.

Inkscape 1.0 tiene bastantes características nuevas, y las notas de lanzamiento tratan de eso maravillosamente. Pero tambień se ha hecho mucho trabajo bajo el capó. ¿Podrían resumir esos cambios y lo que significan para el futuro desarrollo del programa?

Alex Valavanis: Mi trabajo principal en el Boston Hackfest, que fue parcialmente publicado en la versión 1.0, fue alejarnos de la obsoleta API de GtkAction. Esencialmente, se trataba de separar el código que se ocupa de las acciones (cosas que Inkscape puede hacer) de la interfaz de usuario (los controles que hacen que Inkscape haga esas cosas).

Hay algunas razones por las que necesitábamos hacer esto. Primero, GtkAction ha sido eliminado de Gtk+ 4, así que es importante para estar preparados para el futuro. En segundo lugar, y más importante, aporta mucha flexibilidad a la forma en que Inkscape puede ser usado y personalizado en futuras versiones.

Por ejemplo, se podrían desarrollar interfaces personalizadas para adaptar la interfaz de Inkscape a aplicaciones particulares, sin tener que tocar el código C++: piense en un “Inkscape para niños” audaz y simplificado, o en un “Inkscape técnico” que facilite el flujo de trabajo para la ilustración CAD/científica.

También se ha trabajado mucho en la migración gradual hacia estándares C++ más modernos, que hacen que el código sea más seguro, reutilizable, flexible y fácil de mantener. Esto ha ido acompañado de un mejor uso de las herramientas de integración continua para reducir los errores que se introducen en el código base. Como resultado, los usuarios deberían notar menos crashes, regresiones, fugas de memoria y molestas advertencias Glib.

Marc Jeanmougin: En cuanto a “bajo el capó”, creo que lo que más ha cambiado en el desarrollo de Inkscape, en comparación con hace unos años, es nuestro traslado a Gitlab. Ha facilitado la discusión sobre los cambios y el progreso técnico, la identificación de algunas regresiones con la integración continua, y ha hecho la vida de los nuevos colaboradores mucho más sencilla.

En términos de Inkscape en sí, los cambios de GTK, aunque muy frustrantes, deberían conducir a beneficios a largo plazo, y, en mi opinión, la calidad general del código ha ido mejorando con el tiempo, lo que significa menos errores a largo plazo.

Aparte de las características que faltan, creo que dos de las principales quejas que la gente todavía tiene con Inkscape son varios problemas con la interfaz de usuario y de rendimiento. La interfaz y la experiencia de usuario generalmente mejoran cuando se involucran profesionales. En cuanto al rendimiento, supongo que algunos de ellos se pueden resolver con mejores algoritmos, y otros se podrían mejorar con el renderizado por GPU. ¿Tienen un plan para algo de eso?

Marc Jeanmougin: Sí, y sí. Nuestra estructura de comunidad y el uso de chat.inkscape.org facilitan que los profesionales de UX (experiencia de usuario) se involucren en discusiones sobre mejoras y que los desarrolladores se pongan en contacto con ellos (en lugar del canal de IRC [que sigo pensando que es mejor en muchos aspectos, pero es difícil convencer de ello a los no desarrolladores]) y ya tenemos ejemplos de gente de UX que viene a discutir algunas partes de la interfaz. En cuanto al rendimiento, hay tres grandes trabajos previstos:

• muchos problemas de rendimiento son causados por nuestras señales (que deben ser activadas cuando suceden cosas en la interfaz), y algunos desarrolladores están planeando investigar eso
• GTK3 es un desastre en términos de rendimiento y nos afectan mucho sus peculiaridades. Lo ideal sería que GTK4 utilizara la GPU para la interfaz, y hay posibilidades de que sólo mejore.
• Hacer el renderizado del lienzo en la GPU es un objetivo a largo plazo que tenemos, y este año tenemos a un estudiante del GSoC trabajando exactamente en eso, tratando de incluir Pathfinder (un renderizador de la GPU de Mozilla) en Inkscape.

Bryce Harrington: Lo que se haga depende de quién aparezca. En las organizaciones voluntarias, el flujo de valor no se mide en dinero, sino en el tiempo y el esfuerzo que su gente invierte. Y esos voluntarios están motivados, no por el aumento de las ventas de productos, sino por razones más personales e intrínsecas.

Como grupo, hemos tenido discusiones, planes e ideas sobre cómo aumentar el rendimiento y mejorar la interfaz y experiencia de usuario. Puedes confiar en que no escatimamos en pensamiento en este tema. Pero en última instancia depende de qué tipo de voluntarios se presenten, cuáles son sus intereses personales, y cuánta energía pueden comprometer.

Puedes ver la versión para Mac como un ejemplo perfecto de esto en la práctica. El pobre soporte para la versión para Mac fue la mayor queja que escuchamos sobre Inkscape, sin embargo ninguno de nosotros era desarrollador de Mac (ni siquiera usuarios). Pero el deseo era tan fuerte que pudimos involucrar a un número de voluntarios usuarios de Mac, que pensaron  soluciones a esos problemas y los hicieron realidad. Este grupo todavía no está completamente satisfecho con el estado de la versión para Mac, pero seguirán trabajando en ella.

En el Hackfest de Boston, discutimos sobre planes para reelaborar las tripas y obtener una mejor estructura entre el “frontend” y el “backend”, y para la versión 1.0 se logró una gran parte de este trabajo de infraestructura. Sin embargo, en última instancia, dependerá de nuevos voluntarios que aporten sus ideas y su trabajo.

Ryan Gorley: Una pequeña forma en que hemos tratado de atraer más contribuciones para el área de la interfaz y experiencia de usuario fue creando un canal dedicado a ese tema en el chat de nuestro equipo. Eso ha dado lugar a algunas buenas conversaciones, pero sin duda podemos hacer más.

He descubierto que nuestros desarrolladores son muy receptivos a las aportaciones, pero no siempre es transparente para un recién llegado que está trabajando en qué parte del proyecto. Creo que podríamos hacer mejor ayudando a hacer introducciones. Me encantaría ver a más gente de interfaz y experiencia de usuario participando en nuestros festivales.

El equipo de desarrolladores ha cambiado bastante en los últimos años. El año pasado en “Libre Graphics Meeting” (donde tuvieron un “sprint” de programación) vi varias caras nuevas. En términos de cómo está estructurado el proyecto (en cuanto a personas), ¿cuánto ha cambiado? ¿Todavía tienes desarrolladores que pueden hackear prácticamente cualquier parte del código fuente, o ahora tienen más gente que se especializa en ciertas áreas? Algo así como el caso de Jabier, que es el especialista en LPE.

Bryce Harrington: Ciertamente, la composición del proyecto ha cambiado dramáticamente. Muchos de nosotros nos hemos ocupado de otros aspectos de nuestras vidas profesionales y personales, teniendo menos tiempo para ser voluntarios. El “burnout” también puede ser un problema.

Pero Inkscape se estableció con una estructura igualitaria, que es más grande que cualquier persona. Por eso se valora el hecho de invitar a nuevos colaboradores - no tenemos ni idea de quién será el maestro de Inkscape del año que viene - ¿quizás podrías ser tú? Por lo tanto, nos encanta ver nuevas caras, y se entienque que, a veces, los veteranos necesiten dar un paso atrás.

Estructuralmente, uno de los mayores cambios ha sido el establecimiento de subgrupos dentro del proyecto, permitiendo la especialización y la optimización de habilidades. El proyecto es realmente demasiado grande para que una persona tenga sus manos sobre todo, y ya han pasado los días en que cada “Inkscaper” tenía conocimientos en todas las áreas. El enfoque reducido de estos equipos también hace que el proyecto sea más accesible para los que llegan de afuera, que podrían encontrar abrumador el proyecto entero.

Marc Jeanmougin: Personalmente, me gustaría introducir el concepto “propietarios de código” (o algo por el estilo) donde algunas personas estarían supervisando partes del código (como LPE, GTK/UI, renderizado, texto, etc.), pero eso es para futuras discusiones y tenemos algunas personas capaces de trabajar sobre cualquier parte del código.

Tavmjong Bah: La código base de Inkscape es muy grande y lleva bastante tiempo aprenderlo (yo todavía lo estoy aprendiendo, todo el tiempo). Algunas partes del código son muy complejas, como la parte de renderizado de texto... y es muy difícil hacerlo bien. Aún así, hay otra áreas en las que los recién llegados pueden involucrarse y marcar la diferencia. A medida que algunas personas se van, otras vienen a ocupar su lugar.

Una cosa que planeaban hacer hace un tiempo era empezar a pagar por el desarrollo. Creo (pero no estoy seguro) que la idea era usar las donaciones que reciben para pagarle a la gente para que trabaje en Inkscape. Pero ahora mismo, parece que algunos de los desarrolladores de Inkscape (Tav, Marc, tal vez otros) todavía tienen campañas personales en Patreon. ¿Han abandonado ese plan?

Bryce Harrington: Este es otro tema digno de un artículo entero en sí mismo, y hay varias ideas al respecto.

Esencialmente hay dos problemas.
Primero, las donaciones a Inkscape no son lo suficientemente grandes para cubrir el salario anual de un desarrollador. Inkscape podría utilizar gente con pasión por la recaudación de fondos para ayudarnos a resolver esto - encontrar un voluntario en esta área sería un cambio radical para el proyecto.
Segundo, la administración: establecer contratos de trabajo y la supervisión de sus tareas acordadas.

Estos obstáculos no son insuperables, e Inkscape ha tomado algunas medidas experimentales para resolverlos, pero el desarrollo remunerado es una propuesta compleja para llevarla adelante de forma correcta.
Y dadas los grandes inconvenientes económicos del mundo actual, parece poco razonable pedir a los usuarios que aumenten las donaciones al nivel que  necesitaría Inkscape para sostener su desarrollo financieramente. Esperemos que la idea pueda ser revisada en el futuro, pero, por ahora, probablemente sea mejor centrarse en mejorar nuestra base de voluntarios.

Marc Jeanmougin: Yo no estoy seguro de qué responder aquí... Sigo pensando que tener gente a tiempo completo en el proyecto sería beneficioso, pero sería un gran paso para el proyecto y siempre es muy difícil comprometerse con esto.

Ryan Gorley: Todavía lidiamos con sinceros desacuerdos dentro del proyecto sobre la mejor manera de encarar el desarrollo pagado. La financiación a través de Patreon es una de las muchas posibles formas que se han discutido, pero ninguna ha sido oficialmente lanzada por el proyecto. Sé que esto seguirá siendo un tema de discusión porque a todos nos gustaría ofrecer a nuestros usuarios las características que solicitan y, además, recompensar a nuestros colaboradores por el excelente trabajo que hacen.

¿Se sienten cómodos con el ritmo de desarrollo? Si quisieran acortar el ciclo de desarrollo y así publicar las actualizaciones a un ritmo más rápido, ¿qué tipo de cambios en el proyecto introducirían?

Marc Jeanmougin: Creo que deberíamos hacer actualizaciones más frecuentes, tal vez se debería decidir una lista de cosas específicas que querríamos para la siguiente versión enseguida de cada lanzamiento...

Ryan Gorley: Sé que se ha discutido la posibilidad de “hackfests” más pequeños y frecuentes.

Bryce Harrington: “Publicar pronto, publicar a menudo”. Me encantaría ver ciclos de desarrollo más rápidos y pequeños. Cuando las cosas se extienden demasiado tiempo entre los lanzamientos, toma más tiempo la estabilización y cuanto más tiempo pasa, mayores son las expectativas sobre el siguiente lanzamiento. Sin embargo, la ingeniería de lanzamientos es un trabajo complejo.

La conversión a GTK3 fue un caso especial que realmente requirió un ciclo de desarrollo más largo de lo normal. Espero que con eso en el espejo retrovisor, los lanzamientos puedan ser más rápidos y ligeros, pero tendremos que ver cómo van las cosas.

Todos los proyectos de software tiene algo que necesita hacerse, ya sea que le falten características al programa o algún trabajo en el sitio web, o los debates en las redes sociales, etc. ¿Qué tipo de habilidades dirían que son las que Inkscape está demando actualmente?

Bryce Harrington: El armado de la versión 1.0 implicó una mayor atención al trabajo de estabilización, pero con esta versión ya completada, el trabajo puede cambiar a un desarrollo más sustancioso. Este sería un gran momento para que se involucren nuevos desarrolladores, aprendan el código base y emprendan algunas de estas ideas más ambiciosas.

Los desarrolladores ya están discutiendo la actualización del código base  a C++17, y cualquiera que esté interesado en pulir sus habilidades en C++ podría encontrar que es una gran manera de aprenderse el código base, de ayudar al proyecto, y de mejorar las habilidades de desarrollo al mismo tiempo.

El trabajo con errores (tanto el de trillaje como el de corrección) siempre será un área de importancia crucial en la que los colaboradores siempre serán necesarios y bienvenidos.

Como ya se ha mencionado, la recaudación de fondos se ha convertido un área en la que la demanda excede la capacidad por mucho. Incluso una pequeña cantidad de ayuda en esta área podría empujar a Inkscape hacia su sustentabilidad.

Marc Jeanmougin: Yo no estoy seguro, necesitamos todo :) ¿Hay términos de referencia para alguien capaz de manejar un lanzamineto, controlar los errores, corregirlos, y coordinar con todos mientras lo hace?

Martin Owens: En cuanto a las habilidades relacionadas con el trabajo en el sitio web, necesitamos desarrolladores Django (Python). Pero más que eso, necesitamos administradores de sistemas que se ocupen de parte de la infraestructura. Algunas personas que no sólo entren y salgan de vez en cuando, sino que se comprometan a ayudar a largo plazo. Gente con experiencia y habilidad que pueda prevenir el tipo de problemas que tuvimos con las descargas durante el lanzamiento. O que nos ayuden a crear una nueva infraestructura. Los programadores son geniales, pero seamos sinceros, la infraestructura necesita administradores de sistemas.

Ryan Gorley: Creo que hay suficiente por hacer para que casi cualquiera pueda marcar la diferencia si expresa su voluntad y se queda lo suficiente para encontrar la necesidad que sea adecuada para sí. Todo está conectado. Sí, evidentemente que más desarrolladores sería genial, pero alguien dispuesto a documentar errores o a rastrillar nuevos problemas, le haría la vida más fácil a los desarrolladores que ya tenemos.

Todavía estamos probando y migrando los errores de nuestro viejo rastreador de errores a Gitlab, que es algo en lo que cualquier usuario de Inkscape puede involucrarse. La habilidad más demandada es la que tiene quien esté leyendo esto. Ven a involucrarte.