some of us have been talking about that in kde for at least a year (probably more, but that's the first conversation i can remember having about it explicitly)... maybe once we're out of the kde4 woods some of us might actually start working on that.
but some of his thougts don't jive with my experience. such as this one about project portland, which is an effort to bring a simple set of desktop-neutral APIs to ISVs (those people who write third party software). in his missive, luis said:
Given two mediocre ISV platforms*, and a finite amount of time and money, why spend that time and money to fix one ISV platform to kick ass** when you can spend the time and money to add a third mediocre ISV platform instead? Yay!
first, this is an effort done in direct response to ISV requests. they want something simple to use now not n years from now. portland is a pragmatic project that most of us realize may well have a limited shelf life. and that's ok.
it's ok because it doesn't take a lot of effort, not compared to the work to "fix one ISV platform to kick ass". not that doing that would fix the issue at hand, which isn't "the platforms are mediocre" but rather "how do we do X" where "X" might be "install an icon on the desktop". now, i'm not trivializing the efforts people have put into portland, but it's pretty telling that the lsb is already looking at it after a very small number of people have put limited amounts of time into to produce something useful already.
did you know that google ships some of these portland tools with their google earth software?
now, creating a right-size solution at low cost that people are needing now may seem like the greatest idea since sliced bread. well, at least like an obvious idea that deserves to be done. but this obvious idea does not come at the expense of making kde's api kick ass (i'll leave comments on gnome's api to those involved with it). we're making kde's api kick ass right now even as portland continues. and note that the driving coding forces behind portland are mostly people who hail from the kde project, so one might expect that if portland was going to cost anyone major API kick-assery slow downs it would be kde. but then one would have a hard time explaining our moving to dbus, adoption of cmake, development of akonadi, solid, phonon, liveui, the k3m and trysil meetings, etc... these are all API level, ass-kicking-potential improvements and only represent a fraction of total activity in this area.
so while i respect the desire to keep an eye out for things that will detract from the long-term sustainability of the free software desktop, ISV and API issues among them, i don't feel portland represents such a risk while delivering real world value to our ISVs.