"Cornelius's grand plan" - Merging KDElibs into Qt

[Chani]

> 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 
classes and do a bit of cleanup would be nothing like the kde3->kde4 BC break. 
it's a whole different scale. entire chunks of kde were rewritten then, 
libraries changed in huge fundamental ways.

kde4->5 would be more like kde2->3... you'd do a search-and-replace to handle 
stuff that moved, compile, maybe catch one or two behaviour changes, and 
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 :)

> 
>  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 
recognised (or licensed in a particular way)..
I'm happy to let nokia sell something with my code in it, but I can understand 
wanting more than just a note in the commit log...

also, I think there is value in still having kde-branded libraries. even if 
they get closer to qt. if we can get them out there and get people using them, 
and promote them, it's more "look at how awesome kde is" material ;)

...of course the flip side of that is, there are still some silly people 
who'll avoid them just *because* they see the KDE brand - but that's their 
loss.

> 
> 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 
modularization too :)

> 
> 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.
> 
> Andras

-- 
Chani
http://chani.ca
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20101102/c5cded4f/attachment.sig>