CopperSpice is a good thing. If you follow the Qt mailing list, there are good debates on the approaches and it's pushing Qt ahead in good ways (like Verdigris itself). The Qt team was unwilling to question many of the assumptions that are built into Qt (like moc) and now the existence of CopperSpice pushes them to reconsider.

> I never understood the rationale behind CopperSpice, especially not why they felt the need to fork the entire codebase instead of trying to work within the boundaries of Qt itself.

They actually go into this in the introduction of their CppCon '15 talk:

"CppCon 2015: Barbara Geller & Ansel Sermersheim “CopperSpice: A Pure C++ GUI Library"" https://m.youtube.com/watch?v=LIiwBNvTllk

I don't quite get it either - they appear afraid of the contributer agreement - but I don't get it. So what if a contribution ends up in a closed source product; it's not like they could revoke the rights to code already published; the worst that could happen is that the community would have to fork if/when the at project discontinued the free licenced part (see open solaris).

It seems they wren't happy with the bootstrapping process which involved a lot of ifdefs either.

They claim to have cleaned up a lot of the code base by not involving moc.

I'm going to go ahead and guess that the only way the CopperSpice executable is 115mb is by doing a static linking with no dead code removal of all of QT, vs. dynamic linking for QT and Verdigris.

Not sure if that's a requirement of CopperSpice or what, but I'm not sure we are comparing apples to apples in this case.

Qt/KDE seems targeting polyglots onto Quick JSON/QML+ECMAscript/WebAssembly heavily influenced by http://merproject.org/ , whereas CopperSpice seems to be continuing from Qt's past Widgets/native C++. Verdigris is at best an isolated small step for those unwilling to head toward Qt's monotonous direction. IMHO Qt's big enough that competing CopperSpice fork will only be beneficial.