I had to follow up to this, because it is an excellent example of why Linux desktop developers shouldn't ever concern themselves with the so-called "corporate desktop." I have spent my entire career working in large corporate environments, for both consumer and IT industries. In that time, I have never seen anyone intentionally transition (for the sake of argument) 100,000 users from something they understood to something new without extremely compelling reasons. 
<br><br>    Without going into much discussion of ROIT, the basic case is that a transiting of your entire "interface" for doing business (i.e. moving to a Linux desktop) requires a _lot_ of additional work. This includes retraining of all of the affected users and their support staff (bye-bye MSCEs ;), re-documenting, re-designing work flow, adding interoperability with archaic software, intense security requirements, ports of custom software, replacements for special Windows software, and the ability to "blame some external vendor" to list a few. You will also have a number of people who can't, or won't, transition at all for various reasons. These people usually play golf with the CFO, and they will get special exemptions from moving over. This will result in trying to support a dual environment, until the "rest of the world" catches up and makes everything interoperate with x-desktop technology on Linux. If you can get past all that, then you face the real problem. Corporations, when dealing with internal end users, are not interested in "good software" (by the standards of most people on this list), they are interested in "simple tools". While there are cases where both can be one and the same, there are many more where it means "bare bones" or crippled. 
<br><br>    As some of the Linux flagship corporations get past the server penetration point, you will begin to see people trying to make some kind of "corporate desktop". When you do, you will recognise it, because someone pulling the purse strings will have asked them to reduce the functionality to the bare minimum to do the job and/or placed some crazy requirement of compatibility with x-technology. 
<br><br>    While it can be bantered that it has been done by x enterprise, or so-and-so seriously considered it -- I have another idea, lets design a desktop *for Linux*. Lets use the best tools we available on the platform, and target the people who are actually using Linux today (
i.e. not these "someday maybe" corporate folks). Once we get that knocked out of the ballpark, then we can worry about other things.<br><br>Greg<br>-<br><br><br><div><span class="gmail_quote">On 12/29/05, <b class="gmail_sendername">
Stefan Teleman</b> <<a href="mailto:steleman@nyc.rr.com">steleman@nyc.rr.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Thursday 29 December 2005 05:41, Andras Mantia wrote:<br>> > Not really. Can't be used by anyone outside Qt/KDE.<br>><br>> I don't get it. Is it meant to be used outside at all? (Yes, somehow via<br>> Rudy in the future).
<br><br>i am the CTO of Big Corporation, Inc. i want to standardize my company's<br>desktop to KDE. 10000 desktops in all. i have some very complex internally<br>developed applications which are the money-makers in my company. KDE is very
<br>nice, i love it, that's why i choose it, but it does not make me any money<br>for my business, my business makes money selling green widgets.<br><br>i have to rewrite our internal applications and integrate them into KDE, which
<br>i am perfectly wiling to do, since KDE will be our brand new shiny standard<br>desktop.<br><br>my company's middleware infrastructure is standardized on CORBA. our internal<br>applications must be integrated into KDE, therefore i must have a way of
<br>bridging KDE and CORBA. i am the customer, and this is a make or break<br>feature requirement, because our internal applications receive real time<br>async notifications from our worldwide sites, and these notifications may
<br>take some further action at the receiver's end, depending on what they are.<br>we currently achieve this with CORBA callbacks.<br><br>how do i integrate KDE into our standardized CORBA environment ? if the answer<br>is that i have to spend money developing CORBA bindings to DCOP or DBUS, then
<br>i'm sorry but i will forego KDE and look at other alternatives which have<br>CORBA support, or at least have a way of easily integrating CORBA bindings.<br>my company does not make money developing open source software. we make money
<br>selling green widgets.<br><br>i was personally involved in a discussion like this, about KDE, 2 years ago.<br>the only thing i have changed is the green widgets part (this company does<br>not make money selling green widgets, but something else). the outcome was
<br>that this company looked somewhere else.<br><br>good luck to me trying to bring up KDE again next year. they won't even pay<br>attention.<br><br>--Stefan<br><br>--<br>Stefan Teleman          'Nobody Expects the Spanish Inquisition'
<br><a href="mailto:steleman@nyc.rr.com">steleman@nyc.rr.com</a>                          -Monty Python<br></blockquote></div><br>