personally i divide the software we release as "kde" (e.g. "kde 3.5") into three groups in my head: development framework, workspace, applications. the workspace is stuff like kdesktop, kicker, kwin, kcontrol, konqueror. applications include kcalc, juk, kooka, kalzium, etc. these are not official definitions, they are just how i personally organize the chaos.
looking back at kde2 and kde3 and how our application set grew, i've been wondering if the process could be improved. right now we require that the application has wide appeal (it can't be niche), must use KDE libs, has to be reasonably feature complete, needs to be maintained and can't have legal or security problems. that's actually a fairly low bar and it doesn't really touch on a number of important issues.
obviously, documentation and HIG compliance need to be added to this. but it's more than just that. whenever we add an app to the official kde application bundle (we so need a name for that), we end up stifling third party projects in that same category. we also allow someone to march in with a 1.0 version of an application and put it into svn without it being proven first.
this didn't matter so much when the majority of people who wrote kde software worked within the main kde project and when there were a limited number of kde software projects out there. but that's not the case anymore. today we have a huge community of developers, we have kde extra gear and we have kde-apps.org.
imagine if we had picked a cd burning app for inclusion in kde back when there were four (or more?) kde cd authoring apps in development. would we have picked k3b? would k3b have become as popular? would we have picked one of the other apps that later became unmaintained?
on the flip side, we have apps that went into kde right away. some of them got me really excited as they brought capabilities to kde. but some of them didn't really take off much and remain problematic to this day. now i wish that we'd let them sit out in kde extra gear for a while and see how it went: were they maintained? did competition arise? what did the users pick?
after a while it becomes obvious which apps to bundle: kopete and superkaramba are two examples of this process. k3b, digikam and amarok are probably ready for this now as well.
perhaps with kde4 instead of saying to people "if you're willing to maintain it, commit it!" we ought to instead start our apps out in kde extra gear and migrate the best of the best into our app bundles.
this may end up changing how our release and development cycles look when it comes to applications, however. our app bundles may become snapshots of the last stable release of many apps, while they continue to be developed on their own (and perhaps faster) development cycle. or perhaps we make it easier for apps to branch for a release and continue development. both kopete and kontact have done this in the past.
it's interesting that most distributions already include apps outside of our app bundles (e.g. k3b) as a standard part of their kde offering. so why have app bundles at all? to help guide and direct users, developers and vendors as to what can and should work well together. it's a service of selection we offer to downstream users, and it helps our documenters, translators and developers know what pieces of software to prioritize their efforts towards.
now, obviously, some apps are "must haves" and we can't wait for a longer trial period (particularly elements of the workspace), but for most applications this should work out well.
the goal should be to have high quality, well maintained applications shipped with kde and those are metrics that take a couple of releases to assess, IMHO.
Subscribe to:
Post Comments (Atom)
15 comments:
Just a thought....
Divide the apps into the three categories Development-Core-Applications. Then make it so you get the Core when you get KDE. And then later you can install development. And then when people want more apps they can install them from the Applications section via a tool like gethotnewstuff.
Just a thought....
I (also) think we shouldn't have 3 apps for the same task in KDE4 packages. If the user wants to he's able to download them, but they shouldn't all be in the packages. Especially apps like K3b and amaroK which heavn't got any competition on the hole Unix and Linux market should be made standard, but everything else should be optional.
It is not so easy to be reasonable in these matters. I understand kuickshow is on its way out. I am going to miss it terribly, it does precisely what I want when I look at my pictures. I remember when kpm was dropped. In the end it became a special mode for kde's system guard. I think this is a good solution, and I hope kuickshow will stay at least as a special mode for one of the other viewer programs. I still am using kpm to get a view of what processes are running in spite of the program not really existing any more
I really think that all the major apps should be released separately from KDE. In the end, distributions will include the good ones anyway, so what difference does it make?
Like you said, some included apps don't work out (*cough* noatun *cough*) and reflect badly on KDE.
Also, with the long drive to KDE 4, apps that are released concurrently with KDE will have a hard time releasing bugfixes and small new features in that time. They either need to make separate releases or not give the users anything for a year.
I think amarok is the poster child for how well a separate release schedule works.
KDE itself should only ship with some smaller components and "viewer" type apps. So a text editor, konqueror, an image viewer, a simple video player (like codeine), and a PDF/GS viewer.
Of course distributions would probably bundle some other applications by default, but it would make the whole thing much more flexible.
I must say, that I overall don't like this kind of development policy. It lacks of common vision. It's more like evolution, random incremental improvements.
When I download KDE I expect the package that has a common vision and a group of people who keep watching to give me something unified, tied together and nice to work in.
Look at Microsoft's Dev tools, or, even better, at Apple's Mac OS X.
Imagine how it would looks like if every app would have it's own maintainer and every app would be developed independly. The OS would look like a piece of software that was suddenly took together and bundled into package. That's (more or less) how KDE 3.x looks like. I feel way too well, on every single step, that I'm using separate app - Kicker, separate app - Kcontrol, separate app - Kmenu, separate app - KClock and so on, and so on.
I think that you should strongly consider taking at least two of those three groups (workspace for sure, and at least part of most important apps) should be considered as "KDE Look&Feel part" and Imho you should create a group that would be made of maintainers of those apps and some people from KDE. The group would decide about KDE 4.x Look&Feel and branches of those apps that are created for KDE release should contain a lot of code that ties them together to remove that feeling I wrote about. I should feel that I'm playing with OS, on the same level as I'm playing with a website, not TABLE, TROW, FORM INPUT and IMG tags. I see a website, it's one, common UI that makes me playing with one big app - OS. And I shouldn't be able to tell you if KMenu is a part of Kicker app or not. I should not find SuperKaramba separate app, I should see that it's a window and feature set of my OS.
This would require probably some changes for "for KDE branches" of those apps like for example the loading of such "piece of OS" should not be signalized by cursor jumping, but some small icon in kicker similar to how browser tells you that it loads some part of web page now. This would make me easly see that when I'm launching external app,it's external app, when I'm launching piece of OS, it's a piece of OS.
And once more, it would make easier creating the thing that Djst pointed out:
http://djst.org/blog/2005/12/22/animated-desktop-for-the-sake-of-usability/
That every part of OS should come to my screen in some animation process, with some "reason".
I like the idea of kde extrager as a kind of breeding place.
It should be open in two directions: on the one hand for applications which want to get the foot in the door of kde, to give them the chance to show how good they are.
In the other direction it should be open for proven apps to drop the fixed release rhythm when it's necessary. One example in this case is kopete: with the new jabber extensions released some days and with the announcement of others following int he next year it would be terrible if kopete would stay tied to the kde rhythm. In this case it really needs its own because there will be heavy development, a lot of changes, and it wouldn't really work if they have to wait too long until kde releases the next version.
So, bundle in kde main everything together what we (=users) need, what is well proven and maintained, and what has no to fast or to havy development. The rest goes into kde extragear if it's promising enough, and has to show there if it should merge into kde main, if it should be dropped, or if probably kde extragear is just the right place for it.
Just my 2 cents
liquidat
"I really think that all the major apps should be released separately from KDE. In the end, distributions will include the good ones anyway, so what difference does it make?"
Instead of simply relying on distributors, KDE should present an unified base. If we start to think "what difference does it makes, distros will take care of it anyway?", we will be diluting KDE and it's brand.
I have seen this line of thinking before. Like, when I took part in discussion regarding the number of apps that ships with KDE. I advocated trimming the number down and consolidating, and the replies I got were basically "it doesn't matter how many and what kind of apps ship with KDE, since it's the job of the distro to sort out the jewels from the crud". Needless to say, I disagree with that. I don't want KDE to be a random collection of apps (or not having any apps at all), I want KDE to be a cohesive collection of kick-ass applications. Of course the distros could tweak what they ship with KDE, but it does matter what KDE presents to the distros as well. And there are those who use the vanilla-KDE as offered by kde.org.
KDE should strive for top-notch quality, instead of relying on third-parties to clean up their work
I think KDE needs to publish a list of applications that are "Part of this complete desktop". Amarok and Juk are great programs, no distribution should be allowed to claim they include KDE unless both are installed as a part of KDE. However there are many who do not one or both, so they shouldn't be bundled in such a way that you have to install them.
The burdon should be on the packagers. However we should guide the packager. When no CD burning application was high quality we should not have listed any. As soon as k3b became powerful and stable, no distribution should be allowed to claim KDE unless k3b is installed be default (but still optional so that those who don't want it can get rid or it)
The "part of this complete desktop" list is likely to include programs that most people wouldn't use, but a small minority will find useful. There may also be programs that system administrators do not want users to use. Because each is a separate application they are easily left out, while still allowing the rest of KDE.
We want users who install KDE to by default get every program they could possibly need, but only if KDE has a good program to fit that need.
Personally, I'd ask for a bit more than using KDE libraries, but a proper use of KDE framework. In particular, some standard KDE apps (like Kopete) doesn't use kioslaves.
Don't worry, I don't propose dropping Kopete at all, but asking such kind of KDE features to be present in an app in order to qualify.
First off I agree with you entirely, some of KDE's best apps now live in extragear. So something really should be done. This message is just a matter of logistics. :)
My fear is that lets say amaroK 2.0 and KDE 4.0 are released the same day (not unlikely). 2.0 is bundled in the multimedia package.
Well, we have new releases every 2 weeks for a 2-3 months following a new stable release. So two months later when amaroK is on 2.0.4, KDE is still just thinking about putting together 4.0.1 packages and meanwhile the 4.0.0 packages with amaroK 2.0.0 are still being downloaded and installed. Or worse some distro that would normally just download and package the newest amaroK decides to package kdemultimedia instead, with its older (relatively buggy, less-featureful) amaroK 2.0.0.
So for this to work, I suppose someone could repackage kdemultimedia every ~two weeks.
First off, something a little off topic:
Aaron, there's no question that you're a brilliant guy and an excellent programmer. But why, oh why do you never capitalize at the beginning of sentences? It's a positively maddening habit. You have these sophisticated sentences but paired with the grammar of a script kiddie. It makes your blog unnessisarily difficult to read. It'd be all right if it was an occasional thing, but it's been happening everytime I've read your blog and on every single sentence. Please, won't you think of the children and use that shift key mother nature gave you?
Ahem. Now onto the situation at hand... in all honestly, I don't think KDE should package any applications at all. KDE really should be the windowing infrastructure and that's all. Even including the KHTML kpart is stretching it in my opinon.
As you say, there's no real way to predict what applications will end up winners and which will end up losers. Since KDE doesn't produce distrobutions anyway, why bother with trying to be one? Having recommended applications is fine, but don't package them all together. Alternatively, every application could be in its own seperate package. Then people would be able to pick and choose exactly what they want.
There are two things that irk me about KDE and this overzealous packaging is one of them. It's not a major problem, but it still irritates me a lot. I can't imagine I'm alone in that.
I disagree with the above Anonymous poster on two issues. First, I just cannot comprehend how you are unable to read Aaron's blogs. Capitalisation is not a grammar issue, and it is not unnecessarily difficult at all to read. Additionally, I find his grammar to be quite readable. (I can only presume when you said grammar, you meant grammar, so the above likely does not apply)
Secondly, I think that it is really irritating to download hundreds of megs of data to install KDE and have over duplication of efforts by having multiple applications that ultimately perform teh same functions. While at the same time, I would also hate to have the Microsoft Windows model whereby I download a large set of packages only to find that I still need to go out and fetch applications.
I feel that http://www.kde-apps.org has become a fundamental repository for applications that we as users may use to our benefit such that it wouldn't contribute to unnecessary bloat of KDE. Additionally, this would make it easier for distros to customise; some distros rip everything apart once they get new version so that installing things becomes more manageable for the users (or at least I'm sure that's the hope).
I'd have to admit that the one thing that has really gotten on my nerves of late is my jealous of Windows. If I want a new version of my instant manager I go to their website, download it and install it. I'm not a very good developer and so what really causes my jealousy is that I find it to be difficult to download from the right place, compile it, resolve dependencies, etc..if it were added to my Window Manager I would probably be more frustrated.
This is an example; pretty much what I'm saying is that I don't want to learn how to use SVN but as a user, I definately want the new tricks the Kopete developers are using but I don't feel that I should have to wait until the next release of KDE. Maybe that's unwarranted and I am asking too much.
I like where you are going with this.
In order for KDE to grow in the long term, and for new individual projects to flourish, the monolithic development model needs to be reworked.
As mentioned by a poster above, when a project is added to early in it's development it seems to lose steam. Noatun was quickly superseded by Juk which was quickly superseded by Amarok.
I agree that KDE 4.0 should have 2 tiers: Core and Applications PLUS a development tree that can include any project that meet minimum criteria. This neatly sidesteps adding apps to the core too "early" in their development, only to see them atrophy soon after becoming "official" kde project apps.
I feel that in addition to the criteria you mentioned (ie: make HIG compliance mandatory)I suggest that an app has to have active development for at least 6 months and have a strong userbase. The exception to this could be when a standout app that is needed to fill out KDE's featureset comes along. Superkaramba was such a strong fork of Karamba and because it made widgets a reality on KDE,it became obvious to include it. Amarok, even though it's younger than Juk has a unique feature set and has become for me the Killer Linux App.. not only is it better than every other Linux "jukebox", it's better than every other WindowsXP and MacOSX "jukebox".. Stand out apps like this should be joined to KDE core early.
Also, without actually integrating new projects into KDE immediately, KDE-apps.org should be given higher visibility from the core project including for example "get more software for your KDE desktop" links that link to KDE-apps or something like that.
On a side note, installed KDE 3.5 the otherday and it is supergreat. Thanks for the great work! Keep it up!
oh, I just realized you guys fixed the "comments on blogger dissapear when you preview bug." I have been going straight to posting without preview for the longest time. Good job and KUDOS to the Konqi team!
Speaking of which, Browsing is a good example of an area that should have one supported solution. The epiphany/Galeon fork resulted in most Distros just choosing Firefox instead and has really damaged Gnome's Official browsers.
Konqueror on the other hand, with its heavy KIO integration (which I love) is a true jack of all trades manager that can act like Finder or like Windows Explorer or like Safari or like IE. It is underrated. Best of all, since Opera builds on QT, Konqueror does have a "KDE compatible" commercial competitor.
The current situation with KDE3 is not sane. There are way too many bundled apps.
There should be the core desktop (pretty much everything needed on say debian to install the kdebase package).
An essentials bundle (image/text etc viewer, text editor, simple video, sound playback) Stuff people expect from a minimum functioning desktop. An application should not be included if there is a KDE component or application that can do the same job more simply.
Finally a Best of Breed bundle which contains applications that just about everybody is going to want with their desktop.
Even so these should not be bundles in the KDE 3 sense. but more in the Debian metapackage sense... IE it should be easy to obtain source packages of each app independantly (wouldn't it be nice if we could realistically do the same with binaries) - kde-apps.org would be an ideal starting point for something like this.
Post a Comment