[Development] Changes to Qt offering

[Konstantin Shegunov]

On Mon, Jan 27, 2020 at 4:36 PM Lars Knoll <lars.knoll at qt.io> wrote:

> One is a change in policy regarding the LTS releases, where the LTS part
> of a release is in the future going to be restricted to commercial
> customers. All bug fixes will (as agreed on the Qt Contributor Summit) go
> into dev first. Backporting bug fixes is something that the Qt Company will
> take care of for these LTS branches. We’ve seen over the past that LTS
> support is something mainly required by large companies, and should
> hopefully help us get some more commercial support for developing Qt
> further.
>

This all sounds like a spanking for the LGPL users, and it really is.
Leaves a really bad aftertaste, especially for those that actively try to
give something back (even if it's a small something) as a "compensation"
for using the LGPL license. I don't think anyone would be against bigger
businesses pitching in more into development (moneywise), but as a
one-man-show the feel is that I've been penalized for not paying the rather
insane license fee.

The third change is that The Qt Company will in the future also offer a
> lower priced product for small businesses. That small business product is
> btw not limited to mobile like the one Digia had some years ago, but covers
> all of Qt for Device Creation.
>

I see a couple of issues here. Firstly, 100k/year *turnover* isn't a small
business, that's a nano-company (i.e. 1-2 devs max) and if they're
providing a device alongside the software that 100k is going to be eaten in
no time. Notice we are not talking profit here, but raw revenue. Whoever
from sales came up with that number, really did a botched up job with it.
On that note, even if we accept that it's applicable, the straightforward
math shows you want to bill 0.5% - 2.5% of the total turnover, so while
this sounds good initially it really isn't that shiny when you crunch the
numbers. That offering is stillborn from my point of view.

Additional question (and a note) here: Is this targeted at embedded/device
developers? Because I don't see how Qt for Device Creation is something
desktop devs need. What we actually would love to see is (more) bugfixing
in the widgets module, but that hasn't been happening that much, nor am I
expecting it to happen; it does seem the major push is to put new features
in, even at the expense of a significant feature creep. (not complaining,
just noting, I get you need to make money and money is where new shiny
things are)
But then that begs the question: What'd be my incentive to pay the license
fee as a desktop dev (any of them, and the standard one is real steep) when
I get very little out of it in return?

The second change is that a Qt Account will be in the future required for
> binary packages. Source code will continue to be available as currently.
> This will simplify distribution and integration with the Marketplace. In
> addition, we want open source users to contribute to Qt or the Qt
> ecosystem. Doing so is only possible with a valid Qt Account (Jira, code
> review and the forums all require a Qt Account).


That's not that big of a deal most of the time, even if somewhat
inconveniencing. The justification though, it's totally bogus. You want
people to register, fine, but don't invent the reasoning for it to sound
better. Also having an account does not lead to contributing, it's simply a
non sequitur. We have tons of people that register to the forums to post
questions, but that doesn't mean they do or want to contribute to the
source. Also the whole spirit of the new offering feels as "we want *to
make* opensource users to contribute". The whole tone and impression is not
"we want to encourage you", but rather "we want to force you", and I have
to say that approach has never ever really worked well, historically.
There's a reason the anecdote goes as: "Putting a 10 foot wall just opens
the market for 12 foot ladders".


> None of these changes should affect how Qt is being developed. There won’t
> be any changes to Open Governance or the open development model.
>

That's not really true. Neither in the technical sense, nor otherwise.
There are technical problems, as for example pointed out by Peppe, that
need to be addressed, and then there's the argument that changing the
pattern of usage is always going to change the pattern of development. You
can't artificially separate the two and make that claim lightheartedly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20200128/112e0fae/attachment-0001.html>