Going above and beyond with Inkscape 1.0

After almost 17 years in the making, Inkscape 1.0 is out. Let’s be fair: this is one of those cases when the version number doesn’t nearly represent what’s actually in the box. The software was perfectly usable right at the point of forking from Sodipodi back in 2003, I’m speaking as the eyewitness here. The v1.0 release should’ve happened years ago but the team took a very conservative approach.

Personally, I stopped using Inkscape 0.92.x and switched to what later became v1.0 a year ago or so. So far, it’s been a good run. I still have personal beefs with some UI solutions but I realize it’s partially due to using a toolkit that is OK for generic desktop applications and not exactly stellar for specialized software.

My personal impression, if you are interested, is that the current team is highly motivated to push this project in the direction of making it a better tool for illustrators. But user impressions are one thing and what developers actually do think is often a whole different thing. So this is an interview time.

I guess there’s just one disclaimer left to tell. Answers to my questions arrived after final GSoC slots had been announced, so at least one of the questions might not make as much sense to you as you’d probably expect to. Oh, and all the illustrations below are close-up parts of the about screen for Inkscape 1.0, made by Bayu Rizaldhan Rayes.

First of all, congratulations! This is a huge milestone. As a large project with a massive user base, I bet that you often feel overwhelmed because people expect so much of you. Some want Inkscape to become an animation tool, others want more CAD features (with constraints, no less), and the list goes on. But Inkscape started out with a mission to become THE editor of SVG files. I mean, even the version numbering scheme used to reflect the coverage of the W3C specification, like v0.50 for 50% coverage etc. (this never happened, I think). Now, the homepage doesn’t even mention the word “SVG”. So how do you actually market Inkscape these days?

Bryce Harrington: After we’d released a few versions of Inkscape, one of our users posted a drawing of a glowingly photorealistic car — it’s the one you’ve probably seen on the Wikipedia page for Inkscape. Seeing how our users were employing Inkscape made many of us realize the scope for Inkscape was incredibly broad.

Along with that, users appeared who hadn’t heard of SVG prior to Inkscape. SVG was just a file format, one of several possible ones they cared about. These users viewed Inkscape not as an “SVG editor” but something that solved even more general drawing needs.

In hindsight, there was a point in time where Inkscape did in fact fulfil that mission to become the de facto standard SVG editor. There really weren’t many options for GUI SVG editing back then, so as Inkscape developed it became the go-to for SVG file authoring. Even today, from laser engravers to game developers you see Inkscape referenced as an important tool. But at the same time there has grown a whole ecosystem of other SVG editing and viewing tools for various use cases.

Marc Jeanmougin: I tend to think of Inkscape as a multi-purpose vector graphics tool. It’s not (yet) THE tool for some precise vector goal, but it’s a good tool to get into vector graphics, and a good tool to achieve almost anything in this area (and the improvements we try to make into customizations possibilities will make it easier to have Inkscape be THE tool for specific goals). For me, the use of SVG is the only obvious choice of an open, hand-editable, web-friendly file format, and we want to insist more on being a vector tool than on technical discussion."

Ryan Gorley: Inkscape will ultimately end up at the intersection of well-documented, regularly requested features and what our developers are capable and interested in building. In this way we’re not like a software enterprise that is looking for growth markets and planning features that way. We have been somewhat constrained by what is possible within the scope of the SVG spec, but that may not always be the case, and there is still a lot we can do within the scope of SVG. Ultimately we will go where our users help us go by getting involved.

In fact, how much are you willing to modify the spec by introducing a further superset of SVG features to add features missing in the original spec? Do you have any kind of policy or informal agreement on that?

Marc Jeanmougin: Not more than strictly needed. There is a lot that can be done with SVG, and ideally we would only implement things that should be in the specifications. Of recent additions, only meshes are not doable in other ways, and not supported in other viewers. Many people (including many Wikipedia contributors) rely on Inkscape to create standard files that would look good on Wikipedia, and it would be detrimental to the SVG format and to Inkscape to add features that get in the way of this use.

Bryce Harrington: Your question has been top of mind in the project’s strategy since before it even existed. SVG, like any protocol, has constraints; particularly for people that view Inkscape as more than just an SVG editor, the limitations felt unnecessarily arbitrary to abide by. Yet, sticking to the standard, despite its idiosyncracies, was in fact one of the rationale for establishing Inkscape, and that differentiated it from other vector graphics tools.

For these reasons, the Inkscape Project viewed the W3C’s SVG efforts as crucial to the software’s future. We consciously sought to address the limitations by working within the committe. Indeed, thanks to generous donations from thousands of Inkscape supporters, we were able to attend and participate in many of the W3C SVG working group meetings. We were one of the only all-volunteer organizations that did this — something this community should be proud of making possible. Tav, our representative in this committee, authored and promoted a number of important SVG features, several of which are now enshrined in the lastest SVG version.

One of the most remarkable benefits is that Inkscape can be used to author content that is then loaded into other tools or browsers. Inkscape takes seriously its role as a partner in a much larger ecosystem of FOSS graphics programs. Being able to interoperate with other software makes the ecosystem as a whole stronger and more powerful.

Tavmjong Bah: SVG is a dialect of XML and the wonderful thing about XML is that it is eXtensible. We don’t need to break SVG to implement cool things like Live Path Effects (which live in the Inkscape namespace). Multi-page SVG’s would be easy to handle this way.

The situation with the development of SVG didn’t look very good a few years back. What’s your outlook for the standard? As a project that is an obvious stakeholder, how much do you still participate in the W3C SVG working group?

Tavmjong Bah: The SVG working group still exists and the W3C management is committed to supporting it… although what that support ends up being, we’ve yet to see. Bi-weekly meetings are attended by only a few members and progress is slow. One hopeful thing is that there is quite a bit of discussion going on at the Git repository. Some features, important to Inkscape like mesh gradients have been postponed to post SVG 2.

Bryce Harrington: Fortunately, SVG is designed to be extensible, so at least the “Inkscape SVG” format can continue to be improved for Inkscape users. The problem will be loss of compatibility with other SVG-based tools such as web browsers. It’s unclear what could be done to better resolve this, hopefully smart people come up with some good ideas.

Martin Owens: I’d say we’re at the point of supporting SVG as much as possible, but we’ve mostly given up trying to add editing features to the SVG specification. As the W3C is dominated by web browsers who don’t need multi page or connectors.

I dare not say much more about W3C-specific things. I know that I’m personally disappointed that Inkscape’s considerable importance in the SVG creation space does not lend itself to getting the feature we intend to build into Inkscape into the actual SVG specification. This does lead to the problem that going forwards we’re likely to have browser incompatibilities (this about what a browser will show of a multi page svg). But this isn’t Inkscape’s official position, just my thoughts.

Inkscape v1.0 has quite a few new features, and the release notes deal with that beautifully. But a lot of work was done under the hood. Could you please summarize those changes and what they mean for the future development of the program?

Alex Valavanis: “My main work at the Boston hackfest, which was partially released in v1.0, was to move us away from the deprecated GtkAction API. Essentially, this was a case of separating code that deals with Actions (things that Inkscape can do) from the UI (the controls that make Inkscape do those things).

There are a few reasons why we needed to do this. First, GtkAction has been removed from Gtk+ 4, so it’s important for future-proofing. Second, and more importantly, it brings a lot of flexibility to the way Inkscape can be used and customised in future releases.

For example, custom UIs could be developed to tailor the Inkscape interface to particular applications, without having to touch the C++ code: think a bold, simplified “Inkscape for kids”, or a “Technical Inkscape” that eases the workflow for CAD/scientific illustration.

There has also been a lot of work on gradually migrating towards more modern C++ standards, which make the code safer, more reusable, flexible, and simpler to maintain. This has been accompanied by better use of continuous-integration tools to reduce bugs being introduced into the code-base. As a result, users should see fewer crashes, regressions, memory leaks and annoying Glib warnings!

Marc Jeanmougin: As for “under the hood”, I think the main thing that has most changed in Inkscape development compared to a few years back is our move to Gitlab. It has made it easier to discuss changes and technical progress, identify some regressions with continuous integration, and made the life of new contributors much easier.

In terms of Inkscape itself, GTK changes, even if very frustrating, should lead to long term benefits, and IMO the overall code quality is improving over time, which means fewer bugs in the long run.

Apart from missing features, I think, two major complaints people still have with Inkscape are various UI issues and performance. UI/UX typically gets better when professionals get involved. As for performance, I’m guessing, some of that can be solved by better algorithms, and some could be improved by GPU-side rendering. Do you have a plan for any of that?

Marc Jeanmougin: Yes, and yes. Our community structure and the use of chat.inkscape.org make it easier for UX professionals to get involved in improvement discussions and for developers to contact them (rather than the IRC channel [that I still think is better in lots of ways, but it’s hard to convince non-developers of that]) and we already have examples of UX people coming to discuss some parts of the interface. As for performance, there are three big works planned:

• many performance problems are caused by our signals (what should be triggered when things happen in the interface), and some developers are planning to look into that
• GTK3 is a mess in terms of performance, and we are affected by its quirks a lot. Ideally, GTK4 should use GPU for the interface, and there are chances it will only improve.
• Making canvas rendering on GPU is a long-term goal we have, and we have a GSoC student this year working in exactly that, trying to get Pathfinder (a Mozilla GPU renderer) into Inkscape.

Bryce Harrington: What gets done depends on who shows up. In all-volunteer-driven organizations, the flow of value isn’t measured in money but rather in the time and effort that people put in. And those volunteers are motivated not by increased product sales, but by more personal and intrinsic reasons.

As a group, we’ve had discussions, plans, and ideas on how to increase performance and improve UI/UX. You can trust that there is no shortage of thinking here. But ultimately it depends on what kinds of volunteers show up, what their personal itches are, and how much energy they can commit.

You can look at the Mac port as a perfect example of this in practice. The poor Mac support was the biggest complaint we heard for Inkscape, yet none of us were Mac developers (or even users). But the desire was so strong that we were able to engage a number of volunteer Mac users to get involved, figure out solutions to the problems, and make it happen. This group is still not perfectly satisfied with the port, but they’ll keep hammering on it.

At the Boston hackfest, we discussed plans for reworking the internals to have a better structure between the “frontend” and “backend”, and for 1.0 a big chunk of this infrastructure work was achieved. However, ultimately it’ll depend on new volunteers to bring their ideas and muscle.

Ryan Gorley: One small way we’ve tried to attract more contributions on the UI/UX front was by creating a dedicated channel for these efforts on our team chat. That has prompted some good conversations, but we can certainly do more.

I have found that our developers are very receptive to input, but it is not always transparent to a newcomer who is working on what part of the project. I think we could do better helping make introductions. I’d love to see more UI/UX people participating in our hackfests.

The team of developers has changed quite a bit in the past several years. Last year at LGM (where you had a coding sprint), I saw quite a few new faces. In terms of how the project (as people) is structured, how much has changed? Do you still have developers who can hack on virtually any part of the source code, or do you now have more people who specialize in something? Like, the way Jabier is your LPE guy.

Bryce Harrington: The project composition has indeed changed dramatically. Many of us have gotten busy with other aspects of our professional and personal lives, leaving less time to volunteer. Burnout can be a problem, too.

But Inkscape was established with an egalitarian structure, that’s larger than any one person. This is why value is placed on making it inviting to new contributors — we have no idea who next year’s Inkscape maestro will be — maybe it could even be you? So, we love seeing new faces, and are understanding that old timers sometimes need to step back.

Structurally, one of the biggest changes has been establishing sub-teams within the project, allowing groups to specialize and optimise their skillsets. The project is really too big for one person to have a hand in everything, and the days are gone where every Inkscaper was knowledgeable in everything. The narrowed focus of these teams also makes the project more approachable by outsiders, who might find the project as a whole overwhelming.

Marc Jeanmougin: Personally, I’d like to introduce a concept like code owners, where some people would be supervising parts of the code (like LPE, GTK/UI, rendering, text, etc.), but that’s for future duscussions and we have a few people able to hack on any part of the code.

Tavmjong Bah: Inkscape’s codebase is very large and takes quite a while to learn (and I am still learning about it all the time). Some of the code is very complex, like the text rendering part… and it’s very hard to get right. Still, there are areas where newcomers can get involved and make a difference. As some people move on, others come to take their place.

One thing you were planning to do a while ago was to start doing paid development. I think (but not sure) the idea was to use the donations you get to pay people to work on Inkscape. But right now, it seems that some of Inkscape developers (Tav, Marc, maybe others) still have personal campaigns at Patreon. Have you abandoned that plan?

Bryce Harrington: This is another topic worthy of an entire article itself, and another one with no shortage of ideas.

There’s essentially two problems. First, donations to Inkscape aren’t quite large enough to reliably cover the annual salary for a developer. Inkscape could really use people with a passion for fundraising to help us solve this — finding a volunteer for this would be a game changer for the project. Second is administrative — setting up contracts for hiring, and overseeing their work tasks.

These hurdles are not insurmountable, and Inkscape’s taken some experimental shots at solving them, but paid development is a tricky proposition to get right. And given the wider economic disruptions of the world today, it seems unreasonable to ask users to increase donations to a level that Inkscape would need to sustain development financially. Hopefully the idea can be revisited in the future, but for now it’s probably best to focus on enhancing our volunteer base.

Marc Jeanmougin: I’m not sure what to answer here… I still think having full-time people on the project would benefit it, but it would be a big step for the project and it’s always very hard to commit into this.

Ryan Gorley: There is still a lot of sincere disagreement within the project about how we would best go about paid development. The Patreon approach is one of many that have been discussed, but none have been officially advanced by the project. I know that will continue to be a topic of discussion because we’d all like to bring our users the features they want and reward our contributors for the excellent work they do.

Are you comfortable with the development pace? If you wanted to make the dev cycle shorter and thus deliver updates at a faster pace, what kind of project changes would you introduce?

Marc Jeanmougin: I think we should more frequent updates, maybe with a list of specific things we’d want for the next release be decided shortly after a release…

Ryan Gorley: I know that smaller, more frequent hackfests have been discussed.

Bryce Harrington: ‘Release early, release often’. I’d love to see faster, smaller development cycles. When things go too long between releases, it takes extra long to stabilize, and the longer between releases, the higher expectations are on each release. However, release engineering is hard work.

The conversion to GTK3 was a special case that really required a longer than normal development cycle. I hope that with that in the rear view mirror, that releases could be faster and lighter, but we’ll have to see how things go.

Every software project has something that needs doing, whether it’s missing features or some website work, or social media wrangling. What kind of skills would you say are in greatest demand in Inkscape?

Bryce Harrington: The build up to 1.0 involved higher attention to stabilization work, but with this release completed, work can shift to meatier development work. This would be a great time for new developers to get involved, learn the codebase, and undertake some of these more ambitious ideas.

The developers are already discussing updating the codebase to C++17, and anyone interested in polishing up their C++ skills might find that a great way to learn the codebase, help the project, and improve development skills at the same time.

Bug work (both triage and fixing) will always be crucially important areas where contributors will always be needed and heartily welcomed.

As mentioned above, fundraising has come up as an area where demand exceeds capacity by a fair shot. Even a small amount of help in this area could push Inkscape to sustainability.

Marc Jeanmougin: Not sure, we need everything :) Is there any skill description for someone able to manage a release, monitor bugs, fix them, and coordinate with everyone while doing so?

Martin Owens: As for skills related to website work, we need Django (Python) developers. But more than that, we need sysadmins to look after some of the infrastructure. Some people who won’t just pop in and out now and then, but people who can commit to helping out in the long term. People with experence and skill that can prevent the kind of issues we had with downloads during the launch. Or help us put together new infrastructure. Programmers are great, but honestly, infra needs sysadmins.

Ryan Gorley: I think there is enough to be done that nearly anyone could make a difference if they expressed their willingness and stuck around long enough to find the need that is a good fit for them. Everything is connected. Yes, more developers would be great, but someone willing to document bugs or triage new issues makes life easier for the developers we have.

We’re still testing and migrating bugs from our old bug tracker to Gitlab, which is something any Inkscape user to get involved with. The skill most in demand is the skill whoever reading this has. Come get involved.