Qt 3.2 requirement

[Ralf Nolden]

On Mittwoch, 30. Juli 2003 10:37, Marc Mutz wrote:
> [ the important message is in the last four paragraphs ;-) ]
> <snip>

> Nope. I'm not advocating that KDE 3.2 should be compatible with Qt 3.1.
> I'm advocating that the Qt 3.2 requirement only gets kicked in place
> once the feature freeze is in place.
That means you're advocating to avoid using Qt 3.2 (which implicitely leads to 
less bugfixes in Qt 3.2.x) until we have a KDE 3.2 feature freeze. This means 
that KDE 3.2 in fact is mostly compatible with Qt 3.1 if there are no changes 
in CVS that make Qt 3.2 a requirement in the last minute.

Sorry, but this is bureaucracy bloat :-)


> Since I think KDE's path to success will primarily lie in the
> applications and commercial Free Software projects such as Safari,
> Aegypten and Kroupware, and _not_ in further improvements of the
> (already mature) framework, I conclude for myself and anyone that is
> willing to follow this line of reasoning, that it's about time the
> focus shifted from making development easy for "us" (the framework
> developers) to making it easy for the application developers.

My opinion is though that I appreciate all those projects that either you're a 
developer or a whiner who wants to get easy bucks for solving easy bugs. KDE 
is way less complicated than any other piece of software when it comes to 
requirements. It's applications' codebase like kmail that unfortunately are 
the base of those contracts and which itself are very hard to handle.
<rant> Not to speak about the people who write that program, it's commonly 
known that the group of people working on kmail are regarded as a closed 
circle of people who let hardly leave any room for other people to join in 
through their barriers of bureaucracy. </rant>

> There must be a reason that Gnome, though commonly (and from Gnome
> people!) refererred to as the poorer framework and awkward to work
> with, has attracted far more commercial companies and has the better
> portfolio of not-so-standard application solutions (where's the gnucash
> equivalent on kde?). The reason may very well be that their libraries
> are developed more or less independantly (which benefits KDE as well -
> see libxml, libxslt).
The reason that GNOME is "successful for commercial companies" is that there 
is, citing Andy Hertzfeld in an interview, "compared to KDE is a very chaotic 
project that leaves enough room for something completely new". It's the jump 
on the "gtk+ is LGPL, we can write commercial stuff without any license fees 
to Trolltech or anyone else" wagon that attracted companies like Sun or HP 
after Sun jumped in. Now HP backed off because they realized that it's a 
barrel without a bottom - at least that's my impression.

> It's time that KDE recognizes that it has become mature, that the wild
> escapades of it's youth (KDE 1->KDE 2 rewrite) are more or less over
> and that it's now time to get a decent living (stable interfaces), give
> birth to children (innovative apps) that thrive through the great
> foundation (kdelibs) laid by their parents. Something like that.

There's two scenarios to differentiate:

a) companies/externals who want to or need to be involved in the core 
development on the absolute bleeding edge of KDE

b) companies/externals that write software for the KDE desktop that isn't part 
of the KDE project but only uses their defined minimal version of KDE/Qt as 
their development base, say UnitedLinux with KDE 3.0.3 and Qt 3.0.x. or KDE 
3.1 and Qt 3.1.

a) is a lot harder than b) but that is the gain that the contractor gets: 
direct involvement in a free software project.

As much as I think that those developments generally help KDE, there is no way 
that as a free software programmer I freely give away control over the 
project in technical aspects so that companies can fulfill their contracts if 
they calculated their costs too low (or didn't communicate their barriers as 
valuable enough that the extra effort to work with the decisions of the 
community as a whole). It's still the project that, despite any commercial 
inerest, decides where the train is going in the technical interest of KDE's 
success as a development platform during the HEAD development process.

All other attempts IMHO lead to a scenario that can be observed from other 
projects and which we intentionally kept KDE free of: jealousy for a job that 
involves being paid to do your voluntary work, the fear that companies decide 
about what free software programmers should do in their spare time and so 
forth.

You have to face that HEAD development is harder to calculate if you don't 
include the time that you will need for recompiling newer stuff or kdelibs 
over and over to have a deskop that will become the next KDE version where 
you have to ensure that the contracted work you're doing will perfectly work 
with. Calculating for contracts in the case of a) IMHO requires an additional 
25% maximum offset from a contract that targets b). You have to sell that to 
customers who have this extraordinary wish to have the stuff they need 
included in the next KDE version - or do the additional work for free because 
you're a free software developer for KDE at the same time who does things in 
his spare time, too.

Ralf

-- 
We're not a company, we just produce better code at less costs.
--------------------------------------------------------------------
Ralf Nolden
nolden at kde.org

The K Desktop Environment       The KDevelop Project
http://www.kde.org              http://www.kdevelop.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030730/8dc444bc/attachment.sig>