Libre Arts - 2023 in preview

When I started interviewing FOSS developers some 18 years ago, 7 out the 18 projects covered in this recap did not even exist, 1 was still distributed as proprietary software only, and most of the other projects were so far from their proprietary counterparts that it took a really boneheaded person to stick around in the hope to watch them flourish.

It is 2023 now. The struggle to keep feature and UX parity with proprietary counterparts is far from over for free/libre software projects. But the boneheaded people among us also have something to celebrate. We are witnessing that moment in time when, despite its many shortcomings, free software is good enough to help us do our job. Not in every use case, but increasingly often and pretty darn efficiently.

This is the moment where you can do an architectural design for a client with BlenderBIM, use OBS to screencast the process, then use Kdenlive to cut raw footage of that house being actually built, compose the background music with MuseScore, record a voiceover with Audacity, mix and master the entire soundtrack with Ardour, then publish the video to YouTube. And, for the most part, this will be business as usual.

Without further ado, I’m giving you the annual recap/preview of FOSS projects across the ecosystem: image editing, painting, photography, 3D, special effects, CAD, animation, video, and audio.

2022 was a really busy year for the project: late binding for CMYK, text outlines, Align/Distribute revamp, floating selections gone, linked layers replaced with layer sets, all the file format support updates… Phew!

There is very little left to do before version 3.0 can be released. The last major change is rewriting the menus code because the old way was obsoleted in GTK3. The team also started saying no to major new features. Most recently, they moved vector layers from 3.0 to 3.0.2. That would be one hell of a minor update!

Once version 3.0 is tagged and released, the team is likely to spend the first few weeks or months fixing bugs then move on to new stuff.

What should we expect in 3.2? Definitely some kind of non-destructive editing.

Possible:

  • AnySpace, which is the codename for a project resulting in editing possible in any color space based on any color model.
  • Vector layers and link layers. Both features have an unfinished implementation (in dedicated branches) and look like an obvious fit for the version 3.2.
  • GTK4 port, but really, only if they want to shoot themselves in the foot.

Both AnySpace and vector layers largely depend on CmykStudent staying active in the project. Link layers are Jehan’s baby, he’s known to scrap some of his experiments, but this one is clearly not of of them.

A full GTK4 port would be a major change because it would likely involve rewriting parts of GIMP with a scene graph and Vulkan and updating the code related to input devices which sounds like a major undertaking.

I’d be a fool to give you any estimations for v3.2 time of arrival. It does look like a multi-year effort though. If the team manages to keep the focus narrow enough (which hasn’t been the case so far), they can probably pull it off in two-ish years. Otherwise it will be another 4-5 years with development releases and backports into the stable branch.

In 2022, developers released version 5.1. Here are some of the release highlights:

  • More changes can be done to multiple selected layers
  • JPEG-XL is now supported, and support for WebP, Photoshop layered TIFF and Photoshop project files has been improved
  • Painting performance is now better, especially on Android
  • The fill tools now support continuous fill

With Krita 5.1 and its bugfix updates out of the way, developers are now actively working on the next feature release, 5.2, currently expected later this year. There is no roadmap per se, at least, for now. But there are some interesting changes proposed for inclusion. Here are some of them:

  • Modernized and optimized PNG file format support. Krita will get things like progress reporting for reading and writing PNG files.
  • Various EXR and TIFF exporting improvements
  • Faster time-to-first-render with OpenGL
  • Finalized rewrite of text layout code with Raqm, FreeType and Harfbuzz, which is a contemporary text layout stack with a very good support for OpenType features
  • Animation audio rewrite and use of FFmpeg for importing and exporting of video files, as well as fractional frame rates support

And then there’s under-the-hood work like the transition to using the Lager library to simplify separating UI from the backend and creating more sophisticated brush engines.

There is also ongoing work on improving the UI and functionality of various features like the drawing assistants, palettes, and the welcome screen. On a slightly more technical side, Krita is moving to Qt 5.15 and, later on, Qt6. They are also planning a switch to QML.

During the pandemic, the team had to deal with an influx of contributions and switched to two releases a year. So two major new versions were released in 2022: 4.0 and 4.2. As usual, the latest release was around winter holidays, so it’s too early to make predictions about features going (or not going) into the next one.

There’s nothing fancy going on in the 4.4 pipeline right now (again, too early). But while looking at pull requests, I stumbled upon something I can’t quite wrap my head around. Apparently, two very common operations, rotating and cropping, still cause a lot of grief for darktable users and require further tweaking.

Even more puzzling is a suggestion to map a double ‘r’ key press to activating rotation. Darktable is very configurable indeed, and being able to set up arbitrary shortcuts and even use something like Loupedeck is great. But I can’t help myself wondering if the team might want spending some quality time with UX people. Darktable is very powerful software that would really benefit from streamlining the UI. The team do have the development expertise to fix these and other issues.

In 2019, Johannes Hanika started working on a full darktable rewrite with acyclic graphs and Vulkan (and Imgui instead of GTK). The program incorporates a lot of ideas from darktable in a more modern approach to designing the architecture. For one, almost everything is done on a GPU. Which means you will need something more powerful than an integrated Intel GPU with its homeopathic-sized memory.

![](upload://5GofOLbjyCkwg86LQaAuJoQhL64.webp)

The program does expose the compositing graph to users although that’s not a prominently placed feature:

![](upload://dhu26Kap5yYWV546nsDD19QkrtL.webp)

In its current state, vkdt looks and feels rather technical and has some feature discoverability issues, same as darktable. Apart from a few long threads at Pixls, it hasn’t yet received as much attention from users and developers alike. This is likely to change in 2023: Johannes recently made the first public release, so it’s in the hands of the people now.

RawTherapee developers gave users a bit of a scare significantly decreasing activity in 2021 and almost entirely dropping out in the first half of 2022. Nevertheless, they did release version 5.9 with almost three years worth of changes: a spot removal tool, a local adjustments tool, a perspective correction tool, and various other new features and improvements.

![](upload://ge0l298C6N1TwSWhdIazYFccGNf.webp)

Most of the development is now happening in branches. By the looks of it, there will be enough work done for a new release later this year. They are adding the “Inpaint Opposed” highlights reconstruction method that you’ve seen in darktable 4.2 last year. There’s structure masks, multiple external editors, favorites management, and more.

If the past few releases are any indication, we are going to see v1.3 around April/May 2023. There has been a lot going on since v1.2:

  • new Shaper Builder tool to combine and subtract objects on the canvas,
  • a whole new editor for pattern fills,
  • revamped Live Path Effects dock,
  • improved Layers and Objects dock,
  • redesigned Filter Editor dock,
  • support for OKLab and OKLch color spaces,
  • support for margins on pages with on-canvas controls.

There’s even experimental OpenGL canvas rendering. And even more quality of life changes are in the pipeline right now.

![](upload://mo5uZKLwoyVwPMbNFfOvd7jpgIE.webp)

There is also some initial work being done on a GTK4 port, but that is likely to be postponed. It’s going to be a huge change for the project, and it’s probably a little too late to try fitting this into the current development and release cycle.

Personally, I’m very happy to see Inkscape team being this active. Even though technically Inkscape still doesn’t have full-time developers, they’ve been kicking some serious ass and I hope like hell that’s how things are going to be for years to follow.

Frankly, version 1.6 is long time overdue. The officially stable 1.4 series is extremely obsolete in virtually every aspect. If you still use it (why would you?), you don’t get a lot of really useful stuff, such as orphans and widows control, footnotes and end notes, cross references, a whole new text layout engine with support for RTL scripts and advanced OpenType features, PDF 1.6 exporting, and the list goes on.

These and many other changes are the results of the last nearly 14 years of development. I’m not kidding you here. The 1.5 branch was created in May 2009 by the late Peter Linnell. So all this and more is coming soon enough. According to Craig Bradney, the team is planning v1.6.0 release in 2023, as well as one or two 1.7.x releases.

My overall impression of the project’s situation hasn’t changed much since this video from two years ago:

The project badly needs both more developers and UX/UI love. Jean Ghali and Craig Bradney are pretty much on their own with this.

Right now, there’s not a terrible lot of information about what’s coming in v3.5 simply because it’s still at the alpha stage (v3.4 was released only a month ago).

So far, the assets browser and pose library received an update, and work on assets management is continuing. There are some Grease Pencil improvements, Open Shading Language can now be used with OptiX on the GPU, and then there’s this:

Most recently, the team posted about their progress adding a Metal-based viewport for macOS users. Long story short: impressive speed-up for rendering, still work to do on playback.

This seems to be the most actively developed free/libre BIM (Building Information Modeling) authoring software today. The project gradually switched from monthly releases will less changes to just a few releases a year, but with a ton of changes. So if you’ve been wondering why it’s not being talked about as often, that’s probably why.

Even with just three releases last year, it’s still well over a thousand of new features, enhancements, and fixes, most notably:

  • Brickschema integration by creating a 2-way link between IFC BIM models and Brickschema BMS models.
  • 2D drawings generation finally available
  • MEP modeling improvements: adding, removing, and editing ports for for ducts, pipes, and various equipment.
  • Federated IFC models with very fast loading and real-time navigation
  • New wall, slab, profile, and stair editing tools
  • New material and style manager and support for rendering styles and textures
  • Model loading to be 50% faster on Blender 3.3+

Dion Moult already made the first release this year, and it’s featuring the work of his GSoC2022 student Martina Jakubowska who made it possible to take buildings created with Sverchok nodes and parametrically convert them to IFC models. I don’t have the latest news from Dion regarding his plans, but I’ll update this post when I do.

The team released v0.20 last year with numerous improvements in virtually every workbench shipped by default: better architecture tools, more FEM features, easier to use drafting tools and 2D hatching, better Interoperability with OpenSCAD, and so much more.

There have been a lot of changes to make it worth cutting v1.0 later this year, especially in the Sketcher and TechDraw workbenches. The caveat here is that the team really want to have the infamous toponaming issue solved, but the existing patch has been proving difficult to merge. So it looks like v1.0 is not guaranteed this year. You can count on many other improvements to be added though!

I know people are looking forward to Blender’s real-time compositor project, but in the meantime Natron is a very capable software that (unlike Blender) supports OFX plugins.

(Screen capture from a recent impressive tutorial in Russian above)

The project hasn’t yet recovered from all the team changes years ago. Most work is still done by just a few people (Martin Rodriguez Reboredo recently joined the team). In he past few years, it’s been mostly under-the-hood changes that need to be done to make way for new fancy things later on.

Version 2.5.0 was released with a functional port to Python 3 in November 2022. Version 2.6.0 is coming soon with even more internal changes: a complete port to Qt 5.15, experimental support for Wayland, experimental support for CMake build system, and experimental Apple Silicon builds (already available). Once 2.6.0 is out, the team can re-focus on user-visible changes coming in 2.7.0 eventually.

One way to help them is for someone with DevOps skills to volunteer to help with Windows builds. This is what Ole-André Rodlie does currently, but he feels like his time is better spent working on core Natron issues/features.

This animation editor has been around for less than 3 years, it’s not hugely popular yet, but it’s been getting traction lately.

![](upload://zGX3UmHTngjqnFyYfqhMS93U2K6.webp)

Here are three major reasons for that: active development, exporting to animated SVGs, Lottie files, and animated Telegram stickers, and — most recently — support for Glaxnimate sequences in Shotcut and Kdenlive thanks to the MLT framework. So people are beginning to make little fun projects with this combo:

I talked to Mattia Basaglia (who you might know from his earlier project, Knotter) about his 2023 plans. In a nutshell, there’s already a number of new features ready to release, like animated positions on a path, basic support for RIVE animations, and better UI for smaller screens. Apart from that, layer masks are likely to get improvements.

Last year, the team delivered a strong series of updates of this non-linear video editor. Here are the changes that I personally find interesting:

  • Numerous usability improvements, e.g. the Render dialog and the Settings dialog have been updated
  • Improved system for tagging clips in the project bin, where you can now add, edit and reorder tags
  • Guides and Markers overhaul, with a new Guides dock, guides categories, and support for exporting guides as chapters
  • Basic subtitle styling
  • Glaxnimate integration and Lottie support
  • Audio recording overhaul

![](upload://b5X1AyoGanGJHanWReATazZzMyq.webp)

But most importantly, the team secured the development fund of slightly over 20K euro to finance development of the following features:

  • Nested timelines, which is already a work in the progress, expected to ship in 23.04
  • Improved effects workflow, expected later in 2023
  • Performance boosts, also expected later in 2023

The team also mentions several other goals: improved keyframing with easing types and curves, better support for video formats with alpha, support for projects with multiple resolutions, Qt6 and KF6 migration, and a render server. There are also various subtitles related improvements and new features in the works. And that’s just the things that are known beforehand. There will be more than that.

There’s also a roadmap that gives a fairly good idea what’s planned short-term and long-term.

There’s been an impressive amount of changes in Olive in 2022: WYSIWYG text editor, drawing shapes and transforming clips in the sequence preview, chroma key nodes, a basic color grading node, better performance when moving a lot of clips around, markers rewrite, the return of audio recording, subtitle renderer and editor, basics of multicam editing, a ton of usability improvements… Wow, let’s make a stop here. That’s easily a few major releases worth of work already.

![](upload://wyl1rF9ZTW1nXSlgW1iYUtPQdZc.webp)

I’ve been using Olive in real projects of tiny calibre (think 2 to 5 minutes long YT videos) and I’d say there are two major problems: stability and masks. I commonly do 2 to 4 hours long editing sessions, and in that time, it’s common for Olive to freeze 3 to 5 times. The program becomes unresponsive and it’s easier to kill it, restart, and do crash recovery than wait an unlimited amount of time for Olive to unfreeze. As for masks, there’s a very promising patch to make them way easier to use.

Just applying the most useful patches and fixing crashes and freezes would make Olive 0.2 a video editor you can easily recommend. At this point, however, I don’t feel confident saying that version 0.2.0 will definitely be out in 2023. The rewrite has been taking a long time, there’s no two ways about it. That and Matt moving to a different continent last year (Australia to USA).

On the other hand, as far as I can tell from conversations on Discord, there are no major changes planned until the release is done. It’s mostly bugfixing ahead. Crossing fingers then.

Last year’s release of version 7.0 opened the doors to a whole lot of new possibilities with the new non-linear sequencer. Ardour can only do playback of clips and cues so far, but recording clips is on the radar and likely to happen in the 7.x series.

What is definitely coming this year is simplified editing of notes’ velocities in a separate lane. This is one of the features users have been requesting for a very long time. There’s a development branch with some pre-alpha quality code. Extremely early work — I’m not even sure I should be posting the screenshot below. But the feature is being actively worked on, and it’s finally coming.

This arrival of cues in 7.0 is triggering another major change. As soon as you have cues, there needs to be some sort of a clip editor easily accessible in the Cue view. So it’s coming too, for audio and MIDI clips alike. And that, in return, means that Ardour can finally provide an alternative workflow for editing MIDI clips: in a context-sensitive bottom pane and, alternatively, in a separate window. Implementation details will be figured out along the way.

Another thing that is very high on the list of priorities is further work on tempo-mapping: building tempo maps that reflect live performance to allow better integration of computer-driven parts of a composition.

And then the team expect to see support for at least one and possibly three Novation Launchpad surfaces landing, with deep integration for Cue control and performance.

Alex was very active with Zrythm development throughout 2022. Here is a really compressed summary:

  • Various UX/UI improvements and quality-of-life changes like adaptive snapping
  • 14 built-in plugins, incl. compressor, delay, gate, distortion, reverb, parametric EQ, and more
  • Various drawing, DSP, and MIDI event processing optimizations
  • A LOT of work on chords, including inversions, transpositions, presets and preset packs, recording to chords tracks
  • More exporting features including support for AIFF, AU, CAF, W64
  • ECMAScript support for scripting in addition to Guile

But above all — a lot of bug fixes, because, let’s face it, it’s still the main issue in Zrythm, not the features (which are sufficient to start making music).

I’m not entirely sure the final release could be out this year. The status changed from alpha to beta in March 2022, but it seems like there’s a never-ending stream of bug reports. But at some point though, Alex will have to call it a day and tag a release. Let’s hope it’s sooner rather than later.

Last year, the combined old/new Audacity team delivered non-destructive stackable effects — something the community had been hoping for since early 2000s. This came with support for VST2 and VST3 effects.

They also had a successful Google Summer of Code project that is going to be merged after some changes — an option to display musical time (bars) in the horizontal ruler and a ‘Linear dB’ option in the vertical ruler — both contributed by Michael Papadopoulos.

The current activity in the project has multiple directions.

Paul Licameli is rewriting the monolithic source code into modules and libraries, and making various parts of the code toolkit-agnostic. This work also contributes to the Qt port (see below) in a major way.

Paul and another developer, Pietro Marcello, already spent some time making native plugins realtime-capable. Paul is now adding support for parallel processing to native plugins.

Dmitry Vedenko is working on the port to Qt/QML. The relevant branch has just become public on GitHub but it doesn’t do anything yet. This will take a while. In fact, if the work on MuseScore’s visual update is any indication, I don’t think we are going to see a Qt-based release this year. The new UI design is in the works though. Here’s one of the mockups:

![](upload://phRASDDuM3vWHIGqCzKG1j8I6sq.webp)

So for 2023, I see a potential for one or two larger updates delivering somewhat cleaner UI and performance, but much of the work will continue to be under the hood.

Shortly before the new year, the MuseScore team released much anticipated version 4.0 that is a complete overhaul of the program. Massive engraving improvements, new playback engine, huge free-of-charge sample library (downloadable separately), an entirely new user interface, VST3 support (sans Linux for now), and other changes are well worth the wait.

I don’t believe you could possibly miss the video by Martin Keary about the process of developing this version of MuseScore, but if you did, I do recommend watching it even if you have nothing to do with score engraving.

The community’s response to the release is overwhelmingly positive. I’ve watched a bunch of reviews of v4.0 on YouTube. People are going completely gaga about the release. One interesting idea I picked up in one of the reviews is that MuseScore now absolutely needs a video player for scoring music to footage synced to the timeline.

The first bugfix update is coming soonish, but right now the team is discussing the roadmap and will hopefully announce their plans to the community next week or so. Don’t know what they will announce, what I do remember is that they postponed the plan to add a sequencer and a full-blown pianoroll editor to be able to release v4 in this century. There also used to be an initiative to develop more guitar-centric features. How much of that is being planned — we’ll soon find out!

First of all, if you made it this far, wow!

The FOSS ecosystem today has this tantalizing effect: so many interesting new projects to try, so much to discuss, but we still have no human clones and the old-fashioned multiplication way takes years and no following-in-the-footsteps guarantee (perhaps, it’s for the better).

Like I said in the beginning, we are very fortunate to be where we are today. Things could have been worse. We could have been running 3DS Max on Windows Me (yikes) in a doomsday bunker (double-yikes), while eating radioactive rats (okay, enough).

I’m very thankful to each and every developer kind enough to respond to my messages and providing insights into their development plans. Also, huge thanks to David Revoy being this awesome no-nonsense person who showed us the way back when few people believed Linux could be a sensible platform for a 2D artist. The featured illustration is his work of art.

Libre Arts is a reader-supported publication. If you appreciate the work I do, donations are once again possible. You can subscribe on Patreon or make a one-time donation (see here for more info).

![](upload://spMbcPaafwqPqF4MX3MLR7gKzQ2.png)


This is a companion discussion topic for the original entry at https://librearts.org/2023/01/year-in-preview/
10 Likes

very impressive list with a lot of well researched info!

2 Likes

nice summary, thank you! did you notice though, that the embeded .webp videos don’t seem to work?

1 Like

you looking at it here or on librearts.org?

obviously not :sweat_smile: I was looking at the announcement on pixls.us, it looks great over at librearts.org.
it just didn’t come to my mind to browse the news over there.

We are going to switch some things soon once I get some free time to have @darix walk me through using the RSS scraper for embeds (so images and videos show up here as well).

For LA we may also remove the post content by default and have a link to the website directly.

2 Likes

Fantastic write up as usual. Thank you so much @prokoudine!

This is the moment where you can do an architectural design for a client with BlenderBIM, use OBS to screencast the process, then use Kdenlive to cut raw footage of that house being actually built, compose the background music with MuseScore, record a voiceover with Audacity, mix and master the entire soundtrack with Ardour, …

Yesssssssss!~

then publish the video to YouTube.

Nooooooo!! :laughing: This is when you publish your video on a lovely PeerTube instance, because PeerTube is also a fantastic FLOSS that has seen a lot of great improvements since last year. OK, and you can post a backup on YouTube :stuck_out_tongue:

But I can’t help myself wondering if the [darktable] team might want spending some quality time with UX people.

That would be a really interesting thing indeed. By the way, I remember there was a darktable survey a few months ago (I discovered the link too late, and it was already closed by the time I tried it). Have the results been shared and/or discussed?

Wow, that was a very long and nice article. And I only waited for this post to publish my blog post :stuck_out_tongue_winking_eye: :

3 Likes

I think one problem with FOSS is still the lack of coordination and collaboration. In theory, collaboration should be easy. But from what we see in reality, there could be a lot more collaboration.
For example, I don’t understand why there are several video editing programs (Shotcut, Kdenlive and some other small/early projects like Olive) and it’s not possible to join forces?

There is this stubborn attitude that anyone can take the code and fork it and make something better out of it. But if there would be real collaboration (also outside the areas of application, e.g. better coordination and cooperation between video, audio and image software), that would be a immense boost for FOSS.
Users would appreciate it if there was one leading software rather than many “good” ones. It’s also a reason why new potential users are overwhelmed and discouraged from donating to a project.

That is an easy example actually.

Shotcut is an NLE by former Kdenlive contributor who wanted his own project again (former project was Kino).

Kdenlive is Kdenlive. Just like Shotcut, it relies on
the MLT backend.

Olive uses an entirely different architecture, it will never use MLT.

I think one problem with FOSS is still the lack of coordination and collaboration. In theory, collaboration should be easy. But from what we see in reality, there could be a lot more collaboration.

FOSS is a fragmented mess, and will always be that way :slight_smile:

1 Like

I think this is as it should be. With freedom, everyone can take things in the directions they want to.

2 Likes

I didn’t notice OpenShot on the list

That’s something I hear quite a bit :slight_smile:

There’s 25 hours of my work in the post above. And then there are at least as many projects I can think of that deserve being covered. Double that time, and you are looking at 1+ week of full-time work with little monetary reward. And you’d get a post that would be pretty much unreadable in its entirety because of the sheer size of it. So I have to decide on my priorities.

No offense was intended

None taken! :slight_smile:

1 Like