From kde-core-devel Tue Nov 02 10:13:59 2010 From: Chani Date: Tue, 02 Nov 2010 10:13:59 +0000 To: kde-core-devel Subject: Re: "Cornelius's grand plan" - Merging KDElibs into Qt Message-Id: <201011021114.00083.chanika () gmail ! com> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=128869278503116 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart8061931.5GGvepMVZ6" --nextPart8061931.5GGvepMVZ6 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable > The monolithic approach and being an extra lib on top of Qt might also > scare some developers. The question is, how much do we sacrifice to get > those developers. Do we break SC and BC again to try to do it "right", > and piss off all the current app developers, who need to port they > lovely project again. And do the same with the users, as there won't be > regression free porting. I'm not against reducing inter-module > dependencies, or making it easy to check out part of a library and > build/install only that, but I'm against doing a full library > restructuring which requires the application developers to port their > application to a new version. Remember, we still did not fully port the > applications to KDE4 technologies! And I bet there are still quite some > Qt3 and KDE3 support module usage in the main kde modules themselves > (eg. korganizer was cleaned up only recently). I don't think this is a fair comparison: breaking BC to reorganize existing= =20 classes and do a bit of cleanup would be nothing like the kde3->kde4 BC bre= ak.=20 it's a whole different scale. entire chunks of kde were rewritten then,=20 libraries changed in huge fundamental ways. kde4->5 would be more like kde2->3... you'd do a search-and-replace to hand= le=20 stuff that moved, compile, maybe catch one or two behaviour changes, and=20 that'd be it. :) > Instead of doing it, we should provide good code examples, good > tutorials and a good tool for developing. Like Qt Creator is for Qt > projects. Be it an extension of Creator, or even better a good KDevelop > (which has the same problems as of now as I said before: it is buggy and > feels unfinished). examples, tutorials, documentation... yes, we always need more of those :) >=20 > And then something that is about fame and recognition: we tried to > build a brand, we try to show that open source is innovative and can > produce cool technologies. I'd not like to see that our work disappears, > by being merged into something (Qt). If it happens we will sadly see > what we have now with webkit and also phonon. Companies have no idea > they are KDE technologies. I have no problem with Qt itself, it is a > very good library and the base of KDE. I'm glad Nokia made it available > under free licenses. I'm glad they are more open than ever. But it is > still a product of a company, it is not the product of a community. Even > if former and current KDE people work there. And this is related to > licensing: do you want to give your code to a company to do whatever > they want with it? To market it as their product? I have no problem if > somebody makes money based on KDE, but I'd like to see that the credit > is also given to KDE. hmm. some people are happy just to have their work used, others want it=20 recognised (or licensed in a particular way).. I'm happy to let nokia sell something with my code in it, but I can underst= and=20 wanting more than just a note in the commit log... also, I think there is value in still having kde-branded libraries. even if= =20 they get closer to qt. if we can get them out there and get people using th= em,=20 and promote them, it's more "look at how awesome kde is" material ;) =2E..of course the flip side of that is, there are still some silly people= =20 who'll avoid them just *because* they see the KDE brand - but that's their= =20 loss. >=20 > So what do we need? I think we need to work on three areas: > - advertize the good things we have in the libraries (marketing > material, tutorials, blog and forum posts also in non-KDE related > websites, even books) > - make sure that people can actually easily use what we advertize > (tutorials, API documentation, development tools) > - bugfix our applications as much as we can, so end users enjoy the > power of our platform +1, all good points. I think we can do those while beginning to plan for=20 modularization too :) >=20 > I know, people cannot be forced to do this or that in an open source > project, and we shouldn't do, still I think the above should be the > goals of the project and the steps that needs to be done in order to > achieve the goals. >=20 > Andras =2D-=20 Chani http://chani.ca --nextPart8061931.5GGvepMVZ6 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) iEYEABECAAYFAkzP5GcACgkQeGbAwpIS3Gx7xACgzaLB+JXKwABh1pwA7DWqDm9P VO8AnjomIBJr2eIovm46WbovoPspg0EA =pz5w -----END PGP SIGNATURE----- --nextPart8061931.5GGvepMVZ6--