Krita: A GPL-3.0 Digital Painting Stack Built for Professional Artwork, Not for Developers

The Problem Krita Solves and Who It Serves

Krita is a free, open source digital painting application built on KDE and Qt frameworks. It targets artists who need to create professional work from start to finish, not just sketch or edit photos. The README names comic book artists, illustrators, concept artists, matte and texture painters, and the digital VFX industry as the intended users. For engineers, the key takeaway is that Krita is a user-facing product, not a library or a framework. The codebase is C++ and the project is hosted on KDE's own infrastructure, with GitHub serving only as a mirror. That distinction matters: if you plan to file issues or submit patches, you must use invent.kde.org, not the GitHub mirror. The project's scope is broad, covering everything from canvas input to file export, which is why it is a large, complex codebase rather than a simple utility.

Architecture and Data Flow: What the Repository Shows

The repository layout is not described in detail in the README, but the project's identity as a Qt/KDE application gives a clear architectural baseline. Krita uses the KDE frameworks for window management, settings, and plugin infrastructure, and Qt for the core event loop and rendering. The data flow in a painting application typically runs from input devices through a canvas abstraction, into a document model, and then to a rendering engine that composites layers. The README does not specify the internal modules, but it links to the API documentation at api.kde.org, which would show the class hierarchy. One concrete architectural signal is the CI setup: the README includes a table with three branches (master, stable, and release), each with its own pipeline. That implies a branching strategy where master accepts features, stable is for bug fixes, and release is for tagged versions. The project also maintains nightly builds for both unstable master and the stable 5.2 branch, which tells you that the codebase is continuously integrated and packaged.

Getting It Running: Nightly Builds and CI Artifacts

The README does not give a single command to build Krita from source. Instead, it points to the online building documentation at docs.krita.org/en/untranslatable_pages/building_krita.html. What it does provide is a set of CI artifact paths for nightly builds. For unstable builds, you download from https://cdn.kde.org/ci-builds/graphics/krita/master/. For stable nightly builds, the path is https://cdn.kde.org/ci-builds/graphics/krita/krita-5.2/. These are prebuilt binaries, so you can run Krita without compiling. For developers, the README explains how to get a Linux build with debug symbols: go to the Jobs section on invent.kde.org, find the latest linux-debug-weekly job, and download the AppImage from the artifacts. Similarly, there are ASAN builds for both Linux and Windows. For Linux, you download an AppImage and set the environment variable ASAN_OPTIONS=new_delete_type_mismatch=0:detect_leaks=0 before running it. For Windows, you download a zip, extract it, set the same variable, and then run krita.com from the bin directory. The Windows instructions stress that you must cd into the bin directory, otherwise ASAN cannot locate llvm-symbolizer.exe and backtraces will lack symbols. That is a specific, actionable detail.

The AI Moratorium: A Hard Constraint on Contribution

The most unusual piece of information in the README is the AI moratorium. The Krita developer community has decided to ban the use of AI tools to assist development until October 2026. The stated reasons are threefold: backlash from users and supporters, the absence of a KDE-wide policy that could conflict, and the belief that AI development itself might change. This is a concrete policy that affects any contributor. If you are an engineer who relies on AI code completion or generation, you cannot use those tools when working on Krita. The moratorium is not a suggestion; the README says 'the use of AI when working on Krita is not allowed.' This has practical implications for patch review, because any contribution suspected of being AI-generated could be rejected. It also means the project's development workflow is deliberately conservative. For a professional artist evaluating Krita as a tool, this policy is irrelevant, but for a developer considering contributing, it is a boundary you must respect.

Limitations and Wrong Tool Cases

Krita is not the right tool if you need a lightweight image editor or a quick screenshot annotator. Its focus is on professional painting, which means a heavy dependency on Qt and KDE libraries, and a larger memory footprint than simpler tools. The README does not list system requirements, but the availability of ASAN builds suggests the codebase is complex enough to warrant memory debugging. Another limitation is the documentation gap: the README gives no build instructions, no dependencies list, and no configuration keys. You must go to an external site to learn how to compile, and the CI table explicitly notes that nightly builds are not covered, so the status indicators may be misleading. The project also has a freeze status system, but the README only shows that master currently allows features and strings, which means there is no feature freeze in place. That is a positive for active development but a risk for stability if you are tracking master. If you need a stable, long-term support release, you should use the 5.2 branch, not master.

Alternatives: MyPaint and GIMP

The obvious alternative to Krita is MyPaint, which is also an open source painting application but with a much smaller codebase and a focus on a single canvas and brush engine. MyPaint is written in C and Python, and it does not have the full layer-based compositing or animation features that Krita offers. The difference in approach is that MyPaint is minimalist, while Krita is an end-to-end solution. Another alternative is GIMP, which is more of a general image editor than a painting tool. GIMP's architecture is plugin-based and its user interface is geared toward photo manipulation, not natural media painting. If you are an engineer evaluating which to adopt for a project, the choice depends on whether you need Krita's specialized brush engines and color management, or whether a simpler tool would suffice. The README does not mention these competitors, but the project's own description makes the distinction clear: Krita is for creating art from scratch, not for editing existing images.

Maintenance and License Cost

Krita is licensed under GPL-3.0 as a whole, with individual files possibly having different but compatible licenses. That means if you integrate Krita's code into a proprietary product, you must comply with the GPL's copyleft terms. For an engineer, this is a significant consideration: you cannot use Krita's source in a closed-source application without releasing your own code under a compatible license. The README does not provide a contributor license agreement, so copyright stays with individual authors. Maintenance cost is high because the project is large and depends on KDE libraries, which have their own release cycles. The CI setup with master, stable, and release branches indicates a structured maintenance process, but the README notes that nightly builds are not covered by the CI status table, so you cannot rely on that table for nightly health. The project also has an active bug tracker at bugs.kde.org, which is the place to report issues, but the README does not give a response time or SLA. If you plan to use Krita as a dependency, be prepared for a steep learning curve and a heavy build environment.

Editorial conclusion

Adopt Krita if you are a digital artist or a developer contributing to a mature, GPL-3.0 painting tool with an active KDE community. Do not adopt it if you need a lightweight editor or want to use AI tools in your workflow: the project has a moratorium on AI-assisted development until October 2026. Before contributing, verify the current freeze status on the master branch and read the building documentation at docs.krita.org, because the README gives no build commands and the CI table omits nightly coverage. The project's real value is its end-to-end art pipeline, not a developer-friendly API.

Official sources

1. Official documentation
2. Official README
3. Project repository