KDE has been going strong for more than 20 years: it was no surprise their development practices were so fluid.
Even so, there were a few surprising things in our analysis. You can find the full report at our Github repo: https://github.com/jibby0/commarch-krita
Running Git by a Bus v2 showed that two main contributors hold a majority of codebase knowledge. This is certainly better than one, and both of them have been around a while (10-15 years).
All in all, not terrible. Should the both of them fall off the face of the earth, hopefully the other 40% could manage.
Patch submission process
The process for creating and submitting a patch was documented, but I couldn’t find any information on who exactly could approve them. I think anyone with the “dev” status can, which you achieve after 3 patches.
Still, not having a public, formal process, isn’t the greatest. Or maybe I just can’t find it.
Callaway Coefficient of Fail
The only places Krita failed in this test were project size and build tools. Krita is (understandably) huge: it relies heavily on Qt, and has plenty of features, such as supporting both bitmap and vector images. It makes sense that the repo would be large, compressed or uncompressed. I believe this is a factor that should be either removed entirely, or at least updated to modern standards.
Krita uses CMake: it lost points for not using GNU Make. However, CMake works a lot better with C++ projects, and writing configs is much less of a pain than writing Makefiles. Since it’s open source and a popular standard, I see no problem with using an alternative build tool.
Other than that.. great!
There were only a few outstanding issues with Krita’s development process, and none of them seemed detrimental. I’ve thought about contributing to the KDE project: mostly their desktop environment, as I use it daily. The modularity is wonderful, and I would love to see it improve.
Since nearly all KDE projects follow a similar development flow, it’s definitely pushed me in a positive direction.