From kde-core-devel Wed Jul 30 10:10:13 2003 From: Ralf Nolden Date: Wed, 30 Jul 2003 10:10:13 +0000 To: kde-core-devel Subject: Re: Qt 3.2 requirement X-MARC-Message: https://marc.info/?l=kde-core-devel&m=105955990316688 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--Boundary-02=_Mm5J/QuCm2i6AtR" --Boundary-02=_Mm5J/QuCm2i6AtR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline On Mittwoch, 30. Juli 2003 10:37, Marc Mutz wrote: > [ the important message is in the last four paragraphs ;-) ] > > 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=20 less bugfixes in Qt 3.2.x) until we have a KDE 3.2 feature freeze. This mea= ns=20 that KDE 3.2 in fact is mostly compatible with Qt 3.1 if there are no chang= es=20 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'r= e a=20 developer or a whiner who wants to get easy bucks for solving easy bugs. KD= E=20 is way less complicated than any other piece of software when it comes to=20 requirements. It's applications' codebase like kmail that unfortunately are= =20 the base of those contracts and which itself are very hard to handle. Not to speak about the people who write that program, it's commonly= =20 known that the group of people working on kmail are regarded as a closed=20 circle of people who let hardly leave any room for other people to join in= =20 through their barriers of bureaucracy. > 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 ther= e=20 is, citing Andy Hertzfeld in an interview, "compared to KDE is a very chaot= ic=20 project that leaves enough room for something completely new". It's the jum= p=20 on the "gtk+ is LGPL, we can write commercial stuff without any license fee= s=20 to Trolltech or anyone else" wagon that attracted companies like Sun or HP= =20 after Sun jumped in. Now HP backed off because they realized that it's a=20 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=20 development on the absolute bleeding edge of KDE b) companies/externals that write software for the KDE desktop that isn't p= art=20 of the KDE project but only uses their defined minimal version of KDE/Qt as= =20 their development base, say UnitedLinux with KDE 3.0.3 and Qt 3.0.x. or KDE= =20 3.1 and Qt 3.1. a) is a lot harder than b) but that is the gain that the contractor gets:=20 direct involvement in a free software project. As much as I think that those developments generally help KDE, there is no = way=20 that as a free software programmer I freely give away control over the=20 project in technical aspects so that companies can fulfill their contracts = if=20 they calculated their costs too low (or didn't communicate their barriers a= s=20 valuable enough that the extra effort to work with the decisions of the=20 community as a whole). It's still the project that, despite any commercial= =20 inerest, decides where the train is going in the technical interest of KDE'= s=20 success as a development platform during the HEAD development process. All other attempts IMHO lead to a scenario that can be observed from other= =20 projects and which we intentionally kept KDE free of: jealousy for a job th= at=20 involves being paid to do your voluntary work, the fear that companies deci= de=20 about what free software programmers should do in their spare time and so=20 forth. You have to face that HEAD development is harder to calculate if you don't= =20 include the time that you will need for recompiling newer stuff or kdelibs= =20 over and over to have a deskop that will become the next KDE version where= =20 you have to ensure that the contracted work you're doing will perfectly wor= k=20 with. Calculating for contracts in the case of a) IMHO requires an addition= al=20 25% maximum offset from a contract that targets b). You have to sell that t= o=20 customers who have this extraordinary wish to have the stuff they need=20 included in the next KDE version - or do the additional work for free becau= se=20 you're a free software developer for KDE at the same time who does things i= n=20 his spare time, too. Ralf =2D-=20 We're not a company, we just produce better code at less costs. =2D------------------------------------------------------------------- Ralf Nolden nolden@kde.org The K Desktop Environment The KDevelop Project http://www.kde.org http://www.kdevelop.org --Boundary-02=_Mm5J/QuCm2i6AtR Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA/J5mLu0nKi+w1Ky8RApXVAJ9FJ2//XTNMtNtTd8oZiNqNUi6YMQCfT8Yu VaS1FMwQTi0spqnwLzzZYjo= =M+37 -----END PGP SIGNATURE----- --Boundary-02=_Mm5J/QuCm2i6AtR--