The KDE team has released the first beta of KDE 4.2, slated for release coming January. Quite a lot of new features have been added, as well as lots of bug fixes and performance improvements. This release also makes a lot of strides to feature parity with KDE 3.x, by adding those small little features that KDE 3.x users are barely aware of, but which were missed in KDE 4.0/4.1, such as taskbar grouping, multiple rows in the taskbar, panel auto-hiding, a traditional icon desktop through 'full-screen' foderview, and so on.

One of the reasons why kde is so much faster targetting new grounds than Gnome, they got it right from the beginning.

Whoa, there! Aren't you overlooking the topic at hand? Namely that KDE4 is taking so freaking long to become usable? What is it? Three years? One year after its highly premature 4.0 release? It may *target* new grounds quickly. But it certainly has not *reached* those grounds at all quickly. And that is a verifiable, empirical fact.

"One of the reasons why kde is so much faster targetting new grounds than Gnome, they got it right from the beginning.

Whoa, there! Aren't you overlooking the topic at hand? Namely that KDE4 is taking so freaking long to become usable? What is it? Three years? One year after its highly premature 4.0 release? It may *target* new grounds quickly. But it certainly has not *reached* those grounds at all quickly. And that is a verifiable, empirical fact. "

That seems to be grossly unfair.

KDE4 will have three standard releases before its first year is up, which is way faster than at any time before.

"This is a pretty common tenet in the Open Source world and where commercial developers often go wrong. If you are an ex-commercial developer then you want desperately to reach a "1.0" stage or a "near functional", "mostly baked" stage before going live. You wouldn't want to release something piece meal, would you? After all -- that's the way it's done.

Actually no. In the Open Source world, that's not how it's done. The best Open Source projects tend to start small, release early, release often (RERO) -- even if it's only a little bit of functional (but useful) code. "

Early and frequent releases are a critical part of the Linux development model. Most developers (including me) used to believe this was bad policy for larger than trivial projects, because early versions are almost by definition buggy versions and you don't want to wear out the patience of your users.

This belief reinforced the general commitment to a cathedral-building style of development. If the overriding objective was for users to see as few bugs as possible, why then you'd only release a version every six months (or less often), and work like a dog on debugging between releases. The Emacs C core was developed this way. The Lisp library, in effect, was not - because there were active Lisp archives outside the FSF's control, where you could go to find new and development code versions independently of Emacs's release cycle.

...

But by a year later, as Linux became widely visible, it was clear that something different and much healthier was going on there. Linus's open development policy was the very opposite of cathedral-building. Linux's Internet archives were burgeoning, multiple distributions were being floated. And all of this was driven by an unheard-of frequency of core system releases.

Linus was treating his users as co-developers in the most effective possible way:

7. Release early. Release often. And listen to your customers.

If you are going to write opinion about open source projects, it perhaps wouldn't hurt you to read "The Cathedral and the Bazaar" and perhaps find out something about open source development practices.

I guess it is safe to assume, that steve grasps the concepts behind the cathedral and the bazaar.

What we are still discussing is, whether a project

a.) is allowd to formulate a set of (probably non-traditional) milestones
b.) optionally change/adapt/reformulate this milestones during development
c.) communicate the (final) requirements, feature matrices, etc. resulting from these milestones
d.) release the software when they *think* they have reached the required level of completeness and
e.) slap a label like "4.0" on the resulting code / product / whatever.

KDE 4.0 was communicated to "eat your children". KDE 4.1 was released backgrounded by "early adopters can now start to switch to it for everyday work". I don't think that we should mandate all (FOSS) projects have to agree on the same criteria for major releases.

EDIT: Just in case this was not clear from my comment:
I think the KDE devs did the right thing to get the thing out of the door early. And I have dealed with too many .0 releases in the past to have any illusions left about "if its .0, it is gold".

we have been over this before, but I think kde 4.0 is a great example of how the origional catb ideas were only half complete, and the other half came with the agile movement a few years later.

open source says shipping everything in a perpetually broken state is ok, so long as you do it alot. this leads to stuff like kde 4 being released while it was still in heavy development, or pulseaudio getting picked up by every distro even though even the author had no confidence in the readyness of the code.

Agile says do quick iterative release cycles, where every release focuses on the small, manageable piece of functionality that will provide the most benefit to the users. Every iteration evaluate what comes next, and stay flexible in future requirements based on what the users say after they actually start using the software.

My personal favorite process is an agile process called SCRUM, which goes further by saying that current standards of code quality are completely unacceptable for an engineering discipline. For us to say that something is done it has to have a full suite of automated unit tests and integration tests, have been signed off on by a tester who manually runs through a suite of scenario tests and regression tests. Near the end of the iteration (or "sprint" as we call it in scrum) we test the deployment and upgrade tests, and do performance profiling/optimization. Only then is something considered "done", and shipped to the clients.

If it were my team putting out KDE, 4.0 would have been considered an epic failure (as would the .0s of leopard and vista). Releasing half baked code early to developers early is a good idea, which is why MSDN and ADC exist for windows and apple developers to get their stuff working on before it ships. Releasing half baked code to users is inexcusable. The rest of the programming world has moved forward in the last 11 years. Release early, release often may have been innovative thinking back then, but if that is where it ends that is what we call "cowboy coding" nowadays.

"Namely that KDE4 is taking so freaking long to become usable? What is it? Three years?"

It's been less than a year since the first release, Plasma itself started taking real shape maybe 6 months before that, with the time leading up to that being spent working on the Qt4 porting, kdelibs organization and merging things like Solid and Phonon.

your negativity and purposeful positioning of things in the oddest ways just to be harsh is really disturbing.

you were a huge critic, i know, and maybe it's a little galling to watch things actually come together. i mean, now you're bitching about how long it's taking? yeesh.

and yeah, go look the Plasma changelog for the last four months and then maybe consider backing off from the chest pounding just a little bit.