Search the site

Escaping Engine Lock-In: Open-Source Tech Stacks hero image

Escaping Engine Lock-In: Open-Source Tech Stacks

This is the article version of my presentation for Every Game Talk Possible Sydney 2026. You can download the presentation slides here1.

The Scenario

You’ve picked a game engine. Your team knows how to use it, your assets import nicely, and you’ve got a game taking shape. Good stuff.

Then something changes. A tool becomes more expensive. A service you depend on shuts down. You need a platform that your current stack doesn’t support. Or there’s a bug blocking your work, and you can’t fix the software causing it.

How much of your project would you have to change to deal with that?

That’s the question behind engine lock-in. And answering it means looking at more than the engine.

I’ve been doing freelance and solo development through BigfootDS since 2012, teaching IT and game development at AIT since 2016, and building open-source tools since 2020. My work began in graphic design and 3D animation, but these days I’m almost entirely focused on programming. So, I tend to look at a game project as a collection of jobs that need doing, with a choice of tools for each job.

The short answer for this article: break your project into smaller parts, and explore open-source tools for those parts. You can start with the asset pipeline or build process while keeping your current engine.

Why We Went to Game Engines in the First Place

An engine gives us a heap of work that somebody else has already done. Rendering, input, audio playback, asset importing, and platform support all take time to build. Reusing those systems lets a team spend more of its time making the game.

Shared tools also give people skills they can take between studios. A developer who already knows the engine has less to learn before they can contribute to a project using it.

The 2026 GDC State of the Game Industry survey2 gives some context: 42% of surveyed developers named Unreal Engine as their primary engine, and 30% named Unity. Those are survey responses, rather than a count of every game project, but they show how much work centres on a few shared tools.

An engine history timeline beside the GDC survey chart showing Unreal Engine at 42%, Unity at 30%, in-house engines at 19%, and Godot at 5%.
Slide 4: The engine timeline and 2026 GDC engine survey results used in the presentation.1

Using an existing engine makes sense. The question is how much of the rest of your business needs to depend on that same choice.

What Is Engine Lock-In?

Choosing an engine creates dependencies. Some are obvious, like the programming language and rendering system. Others turn up later:

  • The formats used for 3D models, animation, textures, and other assets.
  • Version control and the way the team shares large files.
  • Build machines, deployment scripts, and supported target platforms.
  • Plugins, online services, and the data stored in those services.
  • Staff experience, recruitment, documentation, and collaboration habits.

You’re locked in when replacing those dependencies becomes too expensive. That expense might be money, but it can also be months of retraining, rebuilding tools, or converting content.

Unity’s 2023 Runtime Fee announcement is a useful example. Developers had already committed work to an engine when its vendor announced a different charging model. For the current context, Unity cancelled the Runtime Fee on 12 September 20243. The lesson I take from that episode is to consider how a supplier’s decisions could affect a project you’ve already spent years building.

The slides also point to Tencent’s investment in Epic Games, which Tencent originally announced in 20124. Ownership and governance belong in the evaluation too: who makes decisions about the tools your project depends on?

Slide showing the 2023 Unity Runtime Fee news and a 2013 report about Tencent investing in Epic Games.
Slide 6: The Unity Runtime Fee and Tencent investment examples from the presentation.1

Creative software gives us an example outside game development. The Adobe pricing examples in the slides raise the same question as an engine subscription: if the terms or availability change, can you keep working with your own files? Ask that of your hosted wiki and project management service too.

Slide comparing news about Adobe Creative Suite pricing with an Australian Creative Cloud subscription price screenshot.
Slide 7: The historical Adobe pricing examples used in the presentation.1

What Open Source Gives Us

Open-source software gives us options to inspect, modify, and redistribute the tools we use, under their licences. The Open Source Initiative’s definition5 explains the freedoms involved. A free download alone doesn’t tell you whether a tool provides those freedoms.

For a game project, that can mean choosing when to update a tool, adapting it to a particular workflow, or keeping a working version available when the original maintainers move on. It can also mean paying someone to fix a problem in the tool, because the source code is available to work on.

That is where digital independence becomes practical. You have more control over the software and processes your business needs to keep running.

There are still costs. Somebody has to learn the tool, maintain any changes, and run the infrastructure if you’re hosting it yourself. OpenProject’s Community edition documentation6, for example, explicitly calls out the server administration knowledge needed to operate it properly. Removing a subscription doesn’t remove the work behind the service.

Your Game and Your Tools Have Separate Licences

Your game contains your work. Your tech stack contains other people’s work. Open source gives you permission to do more with that stack, subject to the licence for each component.

Godot’s licence page7 is a handy concrete example. The engine uses the MIT licence, and Godot explains that you can choose the licence for your own game. You still need to include the engine’s copyright and licence notices when distributing it, along with the relevant notices for its third-party components.

Slide explaining that your game and technology stack contain separate work, beside an excerpt from Godot licensing information.
Slide 9: The distinction between your game content and the tools used to create it.1

An art tool’s licence and the rights to artwork made with it are separate questions too. Blender’s licensing information8 explains that your artwork and saved data files are yours to use.

So, check the actual tool, dependency, and asset licences. A sound pack, a plugin, and the application loading them can all have different conditions.

Breaking a Game Project Into Smaller Parts

The typical game development pipeline looks something like this:

  1. Artists make images and 3D assets in specialist applications.
  2. Programmers write code in an editor or integrated development environment.
  3. Audio specialists create and edit sound.
  4. The engine combines those outputs into a playable game.
  5. Build and publishing tools get that game to players.

Each step gives us something we can evaluate separately. An illustration tool needs to produce assets the game can use. A build system needs to run the project’s build process. A support system needs to help the team answer player requests.

Those are different jobs, and plenty of them exist outside game development.

This is why I recommend searching for the feature you need. If you need a translation workflow, search for localisation management. If you need to turn a folder of images into a packed asset, search for asset packing. Looking only for a complete game development solution can hide useful tools from other fields.

Let your specialists use tools suited to their work, then agree on how their outputs enter the project. Test that handover with real assets. A model importing successfully is a start, but you also need to check its materials, animation, scale, and anything else your game relies on.

My Bubble: Web Technology for Games

My own example in the talk uses Krita for images, Blender for 3D assets, Visual Studio Code or Notepad++ for code, and Audacity for audio. The game itself uses HTML, CSS, and TypeScript.

From there, the delivery path depends on where the game will run:

  • Vite9 handles the web development and build workflow.
  • Electron10 provides a desktop application using web technology, with support for Windows, macOS, and Linux.
  • Capacitor11 provides a native runtime for web applications on platforms including Android and iOS.
Slide showing Krita, Blender, code editors, and Audacity feeding an HTML, CSS, and TypeScript game, with Electron for desktop, Vite for web, and Capacitor for mobile.
Slide 11: The stack from my talk. Asset creation, game code, and delivery each have their own tools.1

Godmaker is one example from my own work. This approach suits the kind of software I’m building, but you’ll need to test it against your own game’s requirements. Wrapping a web application for desktop or mobile still leaves platform integration, performance testing, and distribution work to do.

Slide showing a Godmaker world map screenshot and the Godmaker title artwork.
Slide 12: Godmaker, one of the game projects shown in the presentation.1

There’s also a distinction worth making in that list: Microsoft’s Visual Studio Code distribution uses a Microsoft product licence12, while the underlying Code - OSS source uses MIT. VSCodium13 provides a separate distribution built from that source. Check the extensions you need as part of the choice too.

Evaluating Tools for Your Team

Finding a tool is the easy bit. Figuring out whether you can depend on it takes more work.

These are the questions from the talk that I’d start with:

  1. Does it support our development environment? Check the operating systems, hardware, and existing tools your team actually uses.
  2. Does it support the game’s target platforms? Test the required export or integration path early.
  3. Does it have useful documentation and support? Try following the documentation for a real task, and look at how the community handles problems.
  4. Does it work well for developers doing similar work? A successful project with similar requirements tells you more than a feature checklist on its own.
  5. What happens if we have to replace it later? Try exporting the data and using it elsewhere. Find out which features or files would be difficult to move.
Slide listing development environment, target platform, documentation, community experience, and replacement cost questions.
Slide 16: The five questions for evaluating a tool before depending on it.1

I’d also check who maintains the project, how it handles updates, and what your team would need to maintain locally. A public repository gives you a place to investigate those questions.

Keeping a private fork can solve a particular problem, but then you have changes to maintain alongside upstream releases. That work needs a place in the project plan.

Mega Crit’s Godot Evaluation

Slay the Spire 2 appears in Godot’s official showcase14, and Mega Crit’s evaluation of the engine gives us a useful example of how to approach a change like that.

Casey Yano’s account of evaluating Godot15 is useful because it describes a trial with actual game development work. Mega Crit evaluated the engine, then built a small game, Dancing Duelists, to find problems before committing further.

The write-up covers content pipelines, C# integration, user interface work, and texture packing. It includes things Yano liked and things that were annoying. That’s the sort of detail I want when evaluating a dependency.

Slide showing Slay the Spire 2 in the Godot showcase and Mega Crit's statement about moving away from Unity.
Slide 18: Mega Crit and Slay the Spire 2 in the open-source migration example.1

For your own project, a small trial could include importing representative assets, implementing one awkward screen, saving and loading data, and producing a build for a required platform. Pick the tasks most likely to reveal a reason the tool won’t suit you.

Ludeon’s In-House Engine

The talk also includes a different route: moving to custom internal tools. On 12 October 2026, Ludeon announced RimWorld’s move from Unity to its Waylith engine for update 1.716. At the time of this article, that update is available on the unstable beta branch, with the main branch still on 1.6.

Slide showing the Waylith engine announcement and a community explanation of separating game simulation from engine rendering.
Slide 17: RimWorld and the move to custom internal tooling.1

Waylith is an example of a studio taking responsibility for its own engine. The announcement doesn’t present it as a public open-source replacement you can download for your own project.

I include both examples because the work involved is different. Adopting a shared open-source engine and maintaining an internal engine give a team different responsibilities. Either choice deserves an evaluation against the people and time available to maintain it.

The Boring Jobs Are Good Places to Start

Waiting for builds sucks. Repeating the same tests is annoying. Uploading releases by hand gets tedious.

Those are useful problems to tackle because you can usually describe the repeated steps. A build process might need to check out the project, install its dependencies, run tests, produce a build, and store the result somewhere the team can access.

Forgejo Actions17 and Jenkins18 are options to explore for that automation. You’ll still need the appropriate build tools, platform access, and credentials for whatever you’re building and publishing.

Godmaker GitHub Actions workflows showing project tests, draft release creation, a React app build, parallel Android, Windows, Ubuntu, and macOS builds, release publishing, and deployment to Google and Steam.
Slide 21: Godmaker’s GitHub Actions workflows automate testing, platform builds, releases, and deployment.1

Builds, Tests, and Publishing

Continuous integration and continuous delivery or deployment, usually shortened to CI/CD, cover a lot of this work. For a game, useful tasks might include:

  • Testing game logic when code changes.
  • Building the game for supported platforms.
  • Keeping build outputs and logs together so testers can identify the version they’re using.
  • Uploading an approved build through the distribution platform’s tools.

The talk points to All About Mighty Build and Test19, from 18 August 2023, as an example of build and testing infrastructure. Mighty Games describes its service20 as an automated pipeline that tests games and reports problems. It’s a useful example of the work you can automate, rather than a claim that every service in the example is open source.

Credits, Version Numbers, and Dependency Records

Slide showing build, test, and proof bots, with a pipeline from version control through game builds to supported platforms.
Slide 19: The Mighty Build and Test example of automated game builds and tests.1

The slides also group automated credits, version numbering, and software bills of materials alongside CI/CD.

Slide grouping automated testing, builds and publishing with credits, version numbers, SBOMs, design tools, LiveOps, and ChatOps.
Slide 22: Automation, credits, dependency records, design tools, and game infrastructure.1

A software bill of materials, or SBOM, records components used in a piece of software. SPDX21 provides a standard for sharing that information. It gives you a way to record dependencies that might otherwise remain scattered across package files and build tools.

You can use automation to produce credits and dependency records, or to put the same version number into the game and its build output. If you’re interested in the attribution side, I’ve written more in Helping Others Cite Your Software22.

Design Tools and Game Infrastructure

Internal tooling can be just as useful. Some of the examples I cover are a custom trading card game set designer, simulations for games with lots of data, asset packers, and living design documents that connect to the game. A tool made for your own workflow can also become a product other teams use.

For example, a card set designer could store the card data once and export it for both a printable layout and the game. That gives you a specific problem to solve: keeping two outputs consistent when a designer changes a card.

Online infrastructure gives us more places to look. Accounts, news feeds, player support, and configuration services all involve work that web developers already do. Live operations, often called LiveOps, covers ongoing operation and updates. ChatOps brings operational commands or reports into a team’s chat workflow.

Architecture diagram for The Bestest Beehive, showing connections to separate authentication, account, news, multiplayer session, configuration, commerce, player data, website, support, issue tracking, forum, and email services.
Slide 23: The Bestest Beehive diagram shows how much supporting software can sit around a game.1

Each box in that diagram is a separate responsibility to think about. You might use an existing service, adopt an open-source tool, or build the part you need. The diagram is an example to examine, rather than a requirement to give every small game its own collection of services.

An Open-Source Solution Shopping List

These are the tool categories from the talk, with links so you can start exploring. The familiar tools column gives context for the job each row covers. Some familiar tools also have free editions or open-source components.

Treat this as a starting list for evaluation. The tools differ in features, file compatibility, and maintenance requirements. Open-source projects can also charge for packaged downloads, hosting, support, or additional editions, so check the version and delivery option you’re considering.

On narrow screens, scroll each table sideways to see all three columns.

Engines, Code, and Visual Assets

Work Tools to explore Familiar tools for this work
Game engine Godot23, UPBGE24, or a framework assembled for your game Unity25, Unreal Engine26
Code editing VSCodium13, Visual Studio Code12 with the distribution distinction discussed above Visual Studio Community27
Illustration, image editing, and photography Krita28, GIMP29, darktable30 Photoshop31, Procreate32, Lightroom33
Vector art Inkscape34 Illustrator35
Pixel art and sprite animation Pixelorama36 Aseprite37
User interface design and prototyping Penpot38, Pencil39 Figma40, Sketch41, Balsamiq42
3D modelling Blender43 3ds Max44, Maya45
Digital sculpting Blender43 ZBrush46

Materials, Animation, Narrative, and Audio

Work Tools to explore Familiar tools for this work
Texture painting Blender43, ArmorPaint47 Substance 3D Painter48, Mari49
Procedural materials Material Maker50 Substance 3D Designer51
Procedural modelling Blender Geometry Nodes52 Houdini53
2D animation OpenToonz54, Krita28, Synfig55 Toon Boom Harmony56, TVPaint57, Moho58
3D animation and rigging Blender43 Maya45, MotionBuilder59
Narrative design Ink60, Twine61 articy:draft62
Music composition and production LMMS63, Ardour64 FL Studio65, Cubase66, REAPER67
Sound editing and recording Audacity68, Ardour64 Audition69, REAPER67, Pro Tools70

Production and Team Workflows

Work Tools to explore Familiar tools for this work
Video editing Kdenlive71, Shotcut72 Premiere Pro73, DaVinci Resolve74
Gameplay capture and streaming OBS Studio75 Bandicam76, Camtasia77
Version control and large assets Git78 with Git LFS79 Perforce P480
Version control hosting Forgejo81 GitHub82, GitLab83, Bitbucket84
Automation Forgejo Actions17, Jenkins18 GitHub Actions85, TeamCity86
Project management and issue tracking Forgejo’s issues and project boards81, OpenProject Community6 GitHub Projects87, Jira88, Linear89, Trello90
Documentation and design wikis Forgejo’s wiki81, BookStack91, or your own website or wiki Confluence92, Notion93
Quality assurance and test case management Kiwi TCMS94 TestRail95

Online Services and Supporting Software

Work Tools to explore Familiar tools for this work
Multiplayer and game backends Nakama96, or a backend built for your requirements PlayFab97, Unity Gaming Services98
Websites WordPress99, Astro100, or your own frontend Squarespace101, Webflow102
Custom APIs and data backends A backend built from suitable libraries and frameworks Firebase103
Feature flags and rollout controls Unleash Open Source104, or a configuration service you build LaunchDarkly105
Localisation management Weblate106 Crowdin107, Phrase108
Graphics debugging and profiling RenderDoc109, Tracy110 PIX111, NVIDIA Nsight112
Social media scheduling Postiz113 Buffer114, Hootsuite115
Player support and ticketing Zammad116 Zendesk117, Freshdesk118

Where a row suggests building something yourself, that is a development option rather than a ready-made product. You’ll need to choose the dependencies and take responsibility for the resulting software.

Summary

A game project combines work from several fields. We can use specialist tools for that work and evaluate their dependencies separately. Open source gives us more options to adapt and maintain those tools, with costs and responsibilities that still need planning.

You can begin with one asset workflow, design tool, or automated job in your existing project.

What Next?

Pick one part of your current project that’s causing friction. Ideally, choose something with a clear input and output, so you can try a replacement without changing everything around it.

For example, try editing one asset in Krita, producing one automated build, or exporting a copy of a design document into another tool. Compare the result with what you need, record the awkward bits, and decide whether the change is worth keeping.

Then share what you learn. A reproducible bug report, better documentation, or a small contribution can help the next team with the same problem. If a tool is useful to your business, funding its maintenance is worth considering too.

You can keep exploring my work through my projects119 and GitHub120.

The next useful step is small enough to try: choose one dependency, test another tool against a real task, and find out how much control it gives you over your work.

References

Footnotes

  1. Stormwood, A 2026, Escaping engine lock-in: open source tech stacks, version 0.1.0, presentation slides, Every Game Talk Possible, Sydney, accessed 14 October 2026, https://alexstormwood.com/articles/202610-escapingenginelockin/Escaping%20Engine%20Lock-In_%20Open%20Source%20Tech%20Stacks%20-%20Alex%20Stormwood%20-%20v0.1.0.pdf. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14

  2. Elderkin, B 2026, GDC 2026 State of the Game Industry reveals impact of layoffs, generative AI, and more, GDC, accessed 14 October 2026, https://gdconf.com/article/gdc-2026-state-of-the-game-industry-reveals-impact-of-layoffs-generative-ai-and-more/. ↩

  3. Bromberg, M 2024, A message to our community: Unity is canceling the Runtime Fee, Unity, 12 September, accessed 14 October 2026, https://unity.com/blog/unity-is-canceling-the-runtime-fee. ↩

  4. Tencent 2012, Tencent makes strategic investment in Epic Games, media release, 19 June, accessed 14 October 2026, https://static.www.tencent.com/storage/uploads/2019/11/09/b0963ae0fe5736d1d2b1e7fd2bebb57f.pdf. ↩

  5. Open Source Initiative 2024, The Open Source Definition, accessed 14 October 2026, https://opensource.org/osd. ↩

  6. OpenProject n.d., OpenProject Community edition, accessed 14 October 2026, https://www.openproject.org/community-edition/. ↩ ↩2

  7. Godot Engine n.d.b, License, accessed 14 October 2026, https://godotengine.org/license/. ↩

  8. Blender Foundation n.d.c, License, accessed 14 October 2026, https://www.blender.org/about/license/. ↩

  9. Vite n.d., Vite, accessed 14 October 2026, https://vite.dev/. ↩

  10. Electron n.d., Introduction, Electron documentation, accessed 14 October 2026, https://www.electronjs.org/docs/latest/. ↩

  11. Capacitor n.d., Capacitor documentation, accessed 14 October 2026, https://capacitorjs.com/docs. ↩

  12. Microsoft n.d.c, Visual Studio Code FAQ: licensing, accessed 14 October 2026, https://code.visualstudio.com/docs/supporting/faq#licensing. ↩ ↩2

  13. VSCodium n.d., VSCodium, accessed 14 October 2026, https://vscodium.com/. ↩ ↩2

  14. Godot Engine n.d.c, Showcase, accessed 14 October 2026, https://godotengine.org/showcase/. ↩

  15. Yano, C 2023, On evaluating Godot, 17 October, accessed 14 October 2026, https://caseyyano.com/on-evaluating-godot-b35ea86e8cf4. ↩

  16. Young, T 2026, Announcing the Waylith Engine and update 1.7, Ludeon Studios, Steam, 12 October, accessed 14 October 2026, https://store.steampowered.com/news/app/294100/view/672882362547178633. ↩

  17. Forgejo n.d.b, Forgejo Actions, Forgejo documentation, accessed 14 October 2026, https://forgejo.org/docs/latest/user/actions/. ↩ ↩2

  18. Jenkins n.d., Jenkins, accessed 14 October 2026, https://www.jenkins.io/. ↩ ↩2

  19. All about Mighty Build and Test 2023, online video, YouTube, 18 August, https://www.youtube.com/watch?v=gVcT2nz4V0U. ↩

  20. Mighty Games n.d., Mighty Games, accessed 14 October 2026, https://www.mightygamesgroup.com/. ↩

  21. SPDX n.d., Overview, accessed 14 October 2026, https://spdx.dev/learn/overview/. ↩

  22. Stormwood, A 2025, Helping others cite, reference, or attribute your software, 25 March, accessed 14 October 2026, https://alexstormwood.com/articles/helpingothersciteyoursoftware/. ↩

  23. Godot Engine n.d.a, Godot Engine, accessed 14 October 2026, https://godotengine.org/. ↩

  24. UPBGE n.d., UPBGE, accessed 14 October 2026, https://upbge.org/. ↩

  25. Unity n.d.b, Unity, accessed 14 October 2026, https://unity.com/. ↩

  26. Epic Games n.d., Unreal Engine, accessed 14 October 2026, https://www.unrealengine.com/. ↩

  27. Microsoft n.d.d, Visual Studio Community, accessed 14 October 2026, https://visualstudio.microsoft.com/vs/community/. ↩

  28. Krita n.d., Krita, accessed 14 October 2026, https://krita.org/en/. ↩ ↩2

  29. GIMP n.d., GNU Image Manipulation Program, accessed 14 October 2026, https://www.gimp.org/. ↩

  30. darktable n.d., darktable, accessed 14 October 2026, https://www.darktable.org/. ↩

  31. Adobe n.d.d, Adobe Photoshop, accessed 14 October 2026, https://www.adobe.com/products/photoshop.html. ↩

  32. Procreate n.d., Procreate for iPad, accessed 14 October 2026, https://procreate.com/procreate. ↩

  33. Adobe n.d.c, Adobe Lightroom, accessed 14 October 2026, https://www.adobe.com/products/photoshop-lightroom.html. ↩

  34. Inkscape n.d., Inkscape, accessed 14 October 2026, https://inkscape.org/. ↩

  35. Adobe n.d.b, Adobe Illustrator, accessed 14 October 2026, https://www.adobe.com/products/illustrator.html. ↩

  36. Pixelorama n.d., Pixelorama, accessed 14 October 2026, https://pixelorama.org/. ↩

  37. Aseprite n.d., Aseprite, accessed 14 October 2026, https://www.aseprite.org/. ↩

  38. Penpot n.d., Penpot, accessed 14 October 2026, https://penpot.app/. ↩

  39. Evolus n.d., Pencil Project, accessed 14 October 2026, https://pencil.evolus.vn/. ↩

  40. Figma n.d., Figma, accessed 14 October 2026, https://www.figma.com/. ↩

  41. Sketch n.d., Sketch, accessed 14 October 2026, https://www.sketch.com/. ↩

  42. Balsamiq n.d., Balsamiq, accessed 14 October 2026, https://balsamiq.com/. ↩

  43. Blender Foundation n.d.a, Blender, accessed 14 October 2026, https://www.blender.org/. ↩ ↩2 ↩3 ↩4

  44. Autodesk n.d.a, 3ds Max, accessed 14 October 2026, https://www.autodesk.com/products/3ds-max/overview. ↩

  45. Autodesk n.d.b, Maya, accessed 14 October 2026, https://www.autodesk.com/products/maya/overview/. ↩ ↩2

  46. Maxon n.d., ZBrush, accessed 14 October 2026, https://www.maxon.net/en/zbrush. ↩

  47. ArmorPaint n.d., ArmorPaint, accessed 14 October 2026, https://armorpaint.org/. ↩

  48. Adobe n.d.g, Adobe Substance 3D Painter, accessed 14 October 2026, https://www.adobe.com/products/substance3d/apps/painter.html. ↩

  49. Foundry n.d., Mari, accessed 14 October 2026, https://www.foundry.com/products/mari. ↩

  50. Material Maker n.d., Material Maker, accessed 14 October 2026, https://www.materialmaker.org/. ↩

  51. Adobe n.d.f, Adobe Substance 3D Designer, accessed 14 October 2026, https://www.adobe.com/products/substance3d/apps/designer.html. ↩

  52. Blender Foundation n.d.b, Geometry nodes, Blender manual, accessed 14 October 2026, https://docs.blender.org/manual/en/latest/modeling/geometry_nodes/index.html. ↩

  53. SideFX n.d., Houdini, accessed 14 October 2026, https://www.sidefx.com/products/houdini/. ↩

  54. OpenToonz n.d., OpenToonz, accessed 14 October 2026, https://opentoonz.github.io/e/. ↩

  55. Synfig n.d., Synfig, accessed 14 October 2026, https://www.synfig.org/. ↩

  56. Toon Boom Animation n.d., Harmony, accessed 14 October 2026, https://www.toonboom.com/products/harmony. ↩

  57. TVPaint n.d., TVPaint, accessed 14 October 2026, https://tvpaint.com/en. ↩

  58. Lost Marble n.d., Moho, accessed 14 October 2026, https://moho.lostmarble.com/. ↩

  59. Autodesk n.d.c, MotionBuilder, accessed 14 October 2026, https://www.autodesk.com/products/motionbuilder/overview. ↩

  60. inkle n.d., ink, accessed 14 October 2026, https://www.inklestudios.com/ink/. ↩

  61. Twine n.d., Twine, accessed 14 October 2026, https://twinery.org/. ↩

  62. articy n.d., articy:draft, accessed 14 October 2026, https://www.articy.com/en/. ↩

  63. LMMS n.d., LMMS, accessed 14 October 2026, https://www.lmms.io/. ↩

  64. Ardour n.d., Ardour, accessed 14 October 2026, https://ardour.org/. ↩ ↩2

  65. Image-Line n.d., FL Studio, accessed 14 October 2026, https://www.image-line.com/fl-studio. ↩

  66. Steinberg n.d., Cubase, accessed 14 October 2026, https://www.steinberg.net/cubase/. ↩

  67. Cockos n.d., REAPER, accessed 14 October 2026, https://www.reaper.fm/. ↩ ↩2

  68. Audacity n.d., Audacity, accessed 14 October 2026, https://www.audacityteam.org/. ↩

  69. Adobe n.d.a, Adobe Audition, accessed 14 October 2026, https://www.adobe.com/products/audition.html. ↩

  70. Avid n.d., Pro Tools, accessed 14 October 2026, https://www.avid.com/pro-tools. ↩

  71. Kdenlive n.d., Kdenlive, accessed 14 October 2026, https://kdenlive.org/. ↩

  72. Shotcut n.d., Shotcut, accessed 14 October 2026, https://shotcut.org/. ↩

  73. Adobe n.d.e, Adobe Premiere, accessed 14 October 2026, https://www.adobe.com/products/premiere.html. ↩

  74. Blackmagic Design n.d., DaVinci Resolve, accessed 14 October 2026, https://www.blackmagicdesign.com/products/davinciresolve. ↩

  75. OBS Project n.d., OBS Studio, accessed 14 October 2026, https://obsproject.com/. ↩

  76. Bandicam n.d., Bandicam, accessed 14 October 2026, https://www.bandicam.com/. ↩

  77. TechSmith n.d., Camtasia, accessed 14 October 2026, https://www.techsmith.com/camtasia/. ↩

  78. Git n.d., Git, accessed 14 October 2026, https://git-scm.com/. ↩

  79. Git LFS n.d., Git Large File Storage, accessed 14 October 2026, https://git-lfs.com/. ↩

  80. Perforce n.d., Perforce P4, accessed 14 October 2026, https://www.perforce.com/products/p4. ↩

  81. Forgejo n.d.a, Forgejo, accessed 14 October 2026, https://forgejo.org/. ↩ ↩2 ↩3

  82. GitHub n.d.a, GitHub, accessed 14 October 2026, https://github.com/. ↩

  83. GitLab n.d., GitLab, accessed 14 October 2026, https://about.gitlab.com/. ↩

  84. Atlassian n.d.a, Bitbucket, accessed 14 October 2026, https://bitbucket.org/. ↩

  85. GitHub n.d.b, GitHub Actions, accessed 14 October 2026, https://github.com/features/actions. ↩

  86. JetBrains n.d., TeamCity, accessed 14 October 2026, https://www.jetbrains.com/teamcity/. ↩

  87. GitHub n.d.c, GitHub Issues, accessed 14 October 2026, https://github.com/features/issues. ↩

  88. Atlassian n.d.c, Jira, accessed 14 October 2026, https://www.atlassian.com/software/jira. ↩

  89. Linear n.d., Linear, accessed 14 October 2026, https://linear.app/. ↩

  90. Atlassian n.d.d, Trello, accessed 14 October 2026, https://trello.com/. ↩

  91. BookStack n.d., BookStack, accessed 14 October 2026, https://www.bookstackapp.com/. ↩

  92. Atlassian n.d.b, Confluence, accessed 14 October 2026, https://www.atlassian.com/software/confluence. ↩

  93. Notion n.d., Notion, accessed 14 October 2026, https://www.notion.com/. ↩

  94. Kiwi TCMS n.d., Kiwi TCMS, accessed 14 October 2026, https://kiwitcms.org/. ↩

  95. TestRail n.d., TestRail, accessed 14 October 2026, https://www.testrail.com/. ↩

  96. Heroic Labs n.d., Nakama, accessed 14 October 2026, https://heroiclabs.com/nakama/. ↩

  97. Microsoft n.d.b, PlayFab, accessed 14 October 2026, https://playfab.com/. ↩

  98. Unity n.d.a, Get started with UGS, Unity documentation, accessed 14 October 2026, https://docs.unity.com/en-us/services/getting-started. ↩

  99. WordPress n.d., WordPress, accessed 14 October 2026, https://wordpress.org/. ↩

  100. Astro n.d., Astro, accessed 14 October 2026, https://astro.build/. ↩

  101. Squarespace n.d., Squarespace, accessed 14 October 2026, https://www.squarespace.com/. ↩

  102. Webflow n.d., Webflow, accessed 14 October 2026, https://webflow.com/. ↩

  103. Google n.d., Firebase, accessed 14 October 2026, https://firebase.google.com/. ↩

  104. Unleash n.d., Unleash, source code repository, GitHub, accessed 14 October 2026, https://github.com/Unleash/unleash. ↩

  105. LaunchDarkly n.d., LaunchDarkly, accessed 14 October 2026, https://launchdarkly.com/. ↩

  106. Weblate n.d., Weblate, accessed 14 October 2026, https://weblate.org/. ↩

  107. Crowdin n.d., Crowdin, accessed 14 October 2026, https://crowdin.com/. ↩

  108. Phrase n.d., Phrase, accessed 14 October 2026, https://phrase.com/. ↩

  109. baldurk n.d., RenderDoc, source code repository, GitHub, accessed 14 October 2026, https://github.com/baldurk/renderdoc. ↩

  110. wolfpld n.d., Tracy, source code repository, GitHub, accessed 14 October 2026, https://github.com/wolfpld/tracy. ↩

  111. Microsoft n.d.a, PIX on Windows, accessed 14 October 2026, https://devblogs.microsoft.com/pix/. ↩

  112. NVIDIA n.d., NVIDIA Nsight Graphics, accessed 14 October 2026, https://developer.nvidia.com/nsight-graphics. ↩

  113. gitroomhq n.d., Postiz, source code repository, GitHub, accessed 14 October 2026, https://github.com/gitroomhq/postiz-app. ↩

  114. Buffer n.d., Buffer, accessed 14 October 2026, https://buffer.com/. ↩

  115. Hootsuite n.d., Hootsuite, accessed 14 October 2026, https://www.hootsuite.com/. ↩

  116. Zammad n.d., Zammad Community, accessed 14 October 2026, https://zammad.org/. ↩

  117. Zendesk n.d., Zendesk, accessed 14 October 2026, https://www.zendesk.com/. ↩

  118. Freshworks n.d., Freshdesk, accessed 14 October 2026, https://www.freshworks.com/freshdesk/. ↩

  119. Stormwood, A n.d.b, Projects, accessed 14 October 2026, https://alexstormwood.com/projects/. ↩

  120. Stormwood, A n.d.a, AlexStormwood, GitHub profile, accessed 14 October 2026, https://github.com/AlexStormwood. ↩

Keep reading