[Qbs] Future of Qbs

d3fault d3faultdotxbe at gmail.com
Tue Nov 6 17:38:24 CET 2018


Been thinking about the "why" this has deprecation has happened:
-CMake has large user base
-> As a result, CMake has a large corporate user base
--> As a result, a lot of Qt Commercial users use CMake

The Qt Company only asked commercial users their opinion, so the
results are garbage. CMake did not win on technical merit, even Qt
Company employees admit that.

Imagine if, in the early days of Qt, Qt itself was announced as
deprecated simply because more [corporate] users used Gtk/C? Where
would we be today?

Qbs hasn't seen much community contribution because it's
state-of-the-art software that's functional. It's difficult to dive
into and add features to state-of-the-art software simply because as
non-authors of the code we don't have the vision and designs/plans for
the project and where it's going (in the macro sense), let alone
familiarity with the heart of the code base. Maintaining
compilers/flags, fixing bugs, and adding incremental features, though?
That can easily be achieved by the community... indefinitely. There
haven't been community contributions to maintenance/etc of Qbs for one
simple reason: there didn't need to be, Qt Company did it. Community
software progresses forward from independent developers "scratching
their own itch". You scratched our Qbs itch for us, then point out
nobody contributes to Qbs. Why would we when it works fine (not only
fine, but GOOD)?

Qbs adoption never took off because you never defaulted to it, never
took it out of "experimental" state. I was eyeing it for years,
agreeing it was superior, ready and waiting to start using it as soon
as Qt defaulted to it... and it appears many others were doing the
same.

Was Qbs not defaulted to because Qt Company was waiting for more users
to start using it, while the users didn't use it because Qt Company
never defaulted to it? LoL, cyclic dependency <3: You never gave Qbs a
chance.

I think in the long run a community-maintained Qbs could outgrow
CMake, simply because Qbs is designed better (some CMake devs would
change camps). [Incrementally] Copying what CMake does, but
implementing with a better design, still adds value even though it
partially reinvents the wheel. Take for example LibClang and all the
[easily used] functionality it adds on top of GCC. Better design =
more useful... even though Clang had to "reinvent the wheel". And
besides, Qbs is already functioning, should have defaulted to it and
the corporate users would have largely accepted it. Corporate users
are usually the last ones to dive in and adopt EXPERIMENTAL software.
And hell, if I was a corporate user right about now I'd place
significantly less stock in any of Qt Company's "experimental"
software... because it might just up and disappear at a whim.


d3fault

p.s. I don't care if qtbase uses CMake/QMake etc, since I don't
maintain those projects. But for my own projects, I really want[ed] to
use Qbs. The way you organized libs and apps and all that in Qbs was
downright pleasant to navigate.



More information about the Qbs mailing list