Linked by Thom Holwerda on Sat 23rd Dec 2006 00:48 UTC, submitted by dumbkiwi
KDE This is a response to the article yesterday on the progress of GNOME and KDE. Aaron Seigo, a lead KDE developer, sets out the current state of progress with KDE 4, pointing out that KDE 4 is on track for a release in mid 2007. "Thom points to a quote from me that our goal is to have a 4.0 ready sometime in the first half of next year. That gives us until sometime in June and I'm still thinking we can make it."
Thread beginning with comment 195613
To read all comments associated with this story, please click here.
Long term priorities
by elsewhere on Sat 23rd Dec 2006 06:23 UTC
elsewhere
Member since:
2005-07-13

Here's an old blog post from Aaron (http://aseigo.blogspot.com/2006/02/support-kde4-by-using-kde3.html) to put it in perspective:

but someone on a mailing list pointed out in passing that many of those in the "bleeding edge" crew of people will likely move on to other options during the kde4 devel cycle just because it's going to take a while. we're not talking about an e17 or duke nukem forever type schedule, but it will be longer than our usual "what, it's 9 months already? new release!" standard operating procedure.

i wish this weren't so, but in my gut i can't help but think, "yep, people will move on in search of the latest and greatest something." this has a really negative effect on open source projects, as this fickle attention span can make it rather difficult for us to do longer development cycles (and therefore larger changes). why?

well, user base is everything for large projects. it's what keeps the q/a going, where we get new contributors from, where user support comes from, the pool for regional support at things like tech shows, what packagers use to gauge what packages to give more love to and more ...

in the proprietary world they just lock their users into their platform with file formats, hardware platforms and other nasties so they can take their time if they need to: their users ain't goin' anywhere. we don't do that (because we respect Freedom), and so our users are free to roam.

but when they do roam in larger numbers, that can impact the project. when the project does release that spiffy new version that took a year and a half to complete, it often has to start building the user base back up to where it once was. and no, most projects don't usually have the resource to simultaneously develop two trees indefinitely.


And so is the conundrum with the OSS development model.

Microsoft can take 5+ years to deliver an OS update because, seriously, WTF are you going to do about it? Nothing. Frankly, they can get away with it because, all of the OSX and even desktop linux hype aside, Microsoft owns the desktop and gets to do whatever they want with it.

But in the linux/FLOSS space, things are modular and users have options. Not happy with Red Hat? Look at Suse. Not happy with linux? Look at BSD. Not happy with KDE? Look at Gnome. Etc etc. This freedom and flexibility for the user to choose the tool that works best for them is a wonderful thing, in many ways it's the entire keystone for the FLOSS movement, but it also forces developers into a different position than their proprietary counterparts face.

KDE made a difficult decision in terms of the desktop battle. To virtually drop everything and spend a couple of years reworking the foundation is a brave and bold move at the cost of further development on the current product, knowing full well the risk of attrition from a user base that is accustomed to immediate gratification, is ballsy.

But it was a smart decision because it needed to be done if KDE was going to remain viable long-term, at least in terms of attracting developers and ISV's, and hence users.

A lot of detractors refer to KDE4 as vaporware, but that's unfounded. If you actually follow the trail and look at what KDE4 is going to deliver, there's nothing there that is over-the-top and wildly-optimistic. It's basically a series of frameworks.

Solid is a framework to isolate kde applications from having to interface directly to the hardware layer, and not only leads to stability for linux-based KDE apps but allows for a degree of cross-platform portability. It's not rocket science, but it takes some effort. And it already exists in svn.

Phonon is a framework to allow applications to use a multimedia framework independent of whatever the user selects as their preference. Again, we're not talking about anything pie-in-the-sky, it's common sense. KDE got burned by depending on arts, and isn't willing to take the same risk by depending on an unstable backend like gstreamer. Phonon already exists in svn.

Akonadi is probably more ambitious, but is very cool. It's the reason kdepim has become a corelibrary in addition to kdebase and kdelibs. A lot of the press I've seen focuses just on things like kitchensync and the framework for synching PDA's etc., but the ambition is much greater than that. We're looking at the potential for having a framework for managing datastores of information. It's a significant undertaking, but once again, we're not talking about anything epoch-shattering here. kdepim is in svn, though I'm not sure about the overall state of akonadi.

Tenor was intended to be the conceptual framework for data searching, and there is some promising work with their intergration with nepomuk, an ambitious framework for meta-based searching that is supported by a number of major IT organizations (IBM, HP et al.) as well as the EU. Right now, strigi, which is in very basic development, runs rings around beagle as a file-searching application. In fact, strigi is desktop independent and could even supplant beagle for non-KDE desktops.

And then there's Plasma. Well, Plasma relies on the underlying framework, and a considerable portion of that framework is Qt itself. At the end of the day, much of plasma's eye-candy will be driven by what Qt already provides. But of course, the problem is Plasma is what everybody is looking for, and wants screenshots et al. It's like looking at mockups for new automobiles; the body is relatively simple to design compared to the framework underneath, but in this case they're not going to design the finished body until the framework is done.

Behind all this, there has been a lot of work on defining useability guideliens, coding guidelines, documentaition guidelines etc. This is the un-sexy work that people on the outside don't get to see, or get excited over.

KDE 4 is progressing nicely. If you want to roll up your sleeves, the svn is available, and Suse and Kubuntu have precompiled versions of the svn snapshots available to play with. There is stuff going on, it's just not the sexy stuff that gets headlines. That won't happen until their work is done and users get to enjoy the benefit.

But I guess one of the biggest problems is that there is no single source for updates on kde4-development and it's progression.

For those really interested in watching the process, check out planetkde and dot.kde.org on a regular basis, it's worth it.

Anyways, just wanted to re-assert that KDE 4 is not stalled, and it's not vaporware. It already exists, and it's still evolving, it's just not sexy enough yet for the to drool over yet if all you're looking for is screenshots.

But KDE 4 will rock. Eventually. ;)

Just my 2c...

Reply Score: 5

RE: Long term priorities
by spikeb on Sat 23rd Dec 2006 12:09 in reply to "Long term priorities"
spikeb Member since:
2006-01-18

if they fufill their goals with the release, they will have zero problems whatosever drawing back the userbase.

Reply Parent Score: 2

RE: Long term priorities
by melkor on Sat 23rd Dec 2006 23:57 in reply to "Long term priorities"
melkor Member since:
2006-12-16

Nicely put. KDE 4 will take some time, it's a massive change from earlier KDE versions. The KDE team is thinking ahead, the KDE 4 trunk will probably see KDE through for the next 5-10 years. I hope KDE doesn't lose a lot of users, because imho it's the best desktop environment (overall) that Linux has.

Dave

Reply Parent Score: 2