Announcement

Collapse
No announcement yet.

New Qt Releases Might Now Be Restricted To Paying Customers For 12 Months

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • DeepDayze
    replied
    Originally posted by angrypie View Post
    Lulz, they're backpedaling: https://www.qt.io/blog/qt-and-open-source
    Not much there of substance though...there should be a fuller response.

    Leave a comment:


  • bug77
    replied
    Originally posted by Volta View Post

    There's also a possibility it's a hostile action toward Open Source, but one would have to check their finances to figure out. However, their move seems very stupid.
    Well, it's not a "move" at this point. Just what some KDE guy says was discussed at some point. The brief statement Qt Company sent, seems to indicate there's no action plan. So far, at least.
    I'm not too worried right now, I know there's no shortage of crappy idea that come up in project I work on. Most of them short-lived.

    Leave a comment:


  • angrypie
    replied
    Lulz, they're backpedaling: https://www.qt.io/blog/qt-and-open-source

    Leave a comment:


  • oiaohm
    replied
    Originally posted by CommunityMember View Post
    As previously quoted, at least some members of the KDE project itself has stated they do *not* have the resources to fork and sustain Qt moving forward with their current resources (last I looked the lines of code in Qt is around 60% of the Linux kernel, and while lines of code is not a measurement of complexity, it is suggestive). Now, perhaps, with your talents they could do so, so please do let the KDE project know you are able to do that fork and make it a success, for that will give them some alternative paths forward rather than just hand wringing.
    The reality here you are ignoring the history. In recent years there has not been the need for the companies that support KDE to put developers into extending/maintaining Qt. KDE use to have a lot of Qt extension libraries.



    Also you are missing something critical. For lines of code the biggest developer of Qt is not "The Qt Company" it is in KDAB. In fact KDAB does have the resources to be able to pick up the complete Qt code base. KDAB is still a funding member of KDE.

    Now lets say KDAB decided due to "The Qt Company" actions they decide to fork it so KDE can develop and that they can go after the "The Qt Company" client base.

    Sorry "The Qt Company" location is not as good as it first seams. KDE does have the resources to fork Qt in it sponsors if "The Qt Company" is going to be jerk and cause problems time to be talking to KDAB in detail about very aggressive and profitable plan for KDAB that will come at the cost of "The Qt Company".

    Leave a comment:


  • jo-erlend
    replied
    Originally posted by Volta View Post

    But less commits from Open Source means more funds needed to pay for development. Let's say volunteer commits were 1/20 of all, so it's 1/20 the Qt company will have to pay now or they will loose some of the development performance.
    Yes, but that is assuming that losing money on the market collapse is voluntary, which it isn't.

    Leave a comment:


  • Volta
    replied
    Originally posted by jo-erlend View Post

    Do you not see the inherent contradiction in that statement? If the death of the Qt Company means the death of Qt as a viable Open Source toolkit, that simply means that the volunteers aren't enough, meaning they aren't making it harder on themselves – as long as it actually works and they can make it more lucrative to pay for Qt.
    But less commits from Open Source means more funds needed to pay for development. Let's say volunteer commits were 1/20 of all, so it's 1/20 the Qt company will have to pay now or they will loose some of the development performance.

    Leave a comment:


  • oleid
    replied
    Originally posted by bvbfan View Post

    The fixes will be as are now, 6.0.1, 6.0.2, that's mean it cannot hide, when the code is released you cannot hide it again, it's clear now? They don't mean
    6.0.1 - 12 months delay
    6.0.2 - 12 months delay
    ....
    6.1 - 5 years later
    That's not make any sense to do it, no one is interesting to do that.
    They cannot hide 6.0.0, but they could hide 6.0.1 as that is not released yet. Please note, there won't be 12 months between 6.0.0 and 6.0.1. Just how long it took to release the minor update.

    Leave a comment:


  • jo-erlend
    replied
    Originally posted by Volta View Post

    But the Qt company made everything harder for themselves. They can now forget about voluntary commits. I don't know the numbers, but I believe it was quite meaningful (from KDE?). However, it looks like the Qt company will die soon probably Qt is finished as a viable Open Source toolkit.
    Do you not see the inherent contradiction in that statement? If the death of the Qt Company means the death of Qt as a viable Open Source toolkit, that simply means that the volunteers aren't enough, meaning they aren't making it harder on themselves – as long as it actually works and they can make it more lucrative to pay for Qt.

    Leave a comment:


  • bvbfan
    replied
    The worst thing that they can do is, release the code and never updated it. I also don't think they wanna do that.

    Leave a comment:


  • bvbfan
    replied
    Originally posted by oleid View Post

    It depends on who is doing the fixes. If the fixes were part of 6.0,then they would be released with 6.0.
    would they be delayed as well? Would they be released at all?
    The fixes will be as are now, 6.0.1, 6.0.2, that's mean it cannot hide, when the code is released you cannot hide it again, it's clear now? They don't mean
    6.0.1 - 12 months delay
    6.0.2 - 12 months delay
    ....
    6.1 - 5 years later
    That's not make any sense to do it, no one is interesting to do that.

    Leave a comment:

Working...
X