KDE was once again the top choice in desktops, beating GNOME for the second survey in a row, although usage of KDE and GNOME are both increasing.

KDevelop and Qt Designer are also a huge hit with developers, with Eclipse being the only development tool that was preferred above them (well, possibly netbeans too, depending on how you look at the data).

But, as I explore in next week's Computerworld column, I was disappointed to see that free beer trumps free speech among developers. I won't go into details, because I shouldn't scoop my own column, but suffice it to say that it all boils down to the same reason Sun chose GNOME, why the available SWT is based on GTK rather than Qt (yes, I know there's an unavailable Qt-SWT), and so on.

Comments

"KDE was once again the top choice in desktops, beating GNOME for the second survey in a row, although usage of KDE and GNOME are both increasing."

Im very glad to hear this. Two desktops, one world. OK there are more than two desktops, but the world domination thing still holds. ;)

"But, as I explore in next week's Computerworld column, I was disappointed to see that free beer trumps free speech among developers."

I wouldn't phrase it as apocalyptically as you have. I would be a little more realistic, but only as realistic as RMS when he came up with the LGPL -- proprietary software is a reality, and any proprietary company (which is 99% of them) considering a OSS platform want to have the choice to build proprietary add-ons.

It all seems very silly when you look at it and consider the amount of proprietary GNOME or KDE apps are miniscule compared to the Free versions. LGPL seems to be more of an emotional comfort to big businesses than a real necessity.

"any proprietary company [...] want to have the choice to build proprietary add-ons."

My only point is that while "we" dont much care for a proprietary company's choice to make closed software, *they* certainly will choose the license that gives them the most "freedom", so the choice of LGPL is pretty obvious.

"They choose a development framework/platform, looking at all facts regarding that framework."

Yes they certainly do. Although the LGPL will certainly be a useful (certainly where it is not feasible to pay for development in a minority of cases), and in some cases, a necessary license (getting GPL'd and proprietary software to work together) it is not something that people are going to look exclusively at.

Besides, the LGPL solves nothing. It certainly allows developers and proprietary software businesses to develop software for free, in a monetary sense, but the end-user/business/organisation is still lumped with the license that the proprietary developers choose for their software. When you look at it like this the intended use that some people have in mind for the LGPL just does not make any sense at all.

I do think, however, that the brand new version of kdevelop (3.0) can make waves. It is significantly improved over the previous versions of kdevelop. Language independence is an extremely important key aspect in which kdevelop is a lot mature than Eclipse.

SWT is still larger than Swing though, in all cases where Swing is already installed (which is the majority.) If SWT were distributed with Java (which would actually be a bloody good idea), it would be a different story.

There's nothing that stops a GPL application using SWT, but as far as I know the license of free Qt conflicts with the license of SWT, so SWT can't use free Qt as the peer toolkit. So it's not CPL preventing it, it's QPL.

This study or a similar one comes out every year and I still don't know what it's based on. Are these professional "Linux developers" or just anyone who heard about the survey and decided to hold forth?

I can see why developers are not satisfied with current debuggers. Most of them use gdb, which is incredibly powerful, but can be extremely unintuative at times. The alternatives thus far have been ddd and insight (which both have archaic interfaces), and kdbg (which does have as much flexibility as ddd and insight)

However, the brand new version of kdbg (1.9.x) is a lot better. I hope to see both it and kdevelop's internal debugger improve. I want kdbg to use kate for example.

Other KDE tools are top notch however. Qt Designer and Kdevelop is an elegent top-down solution for software development, and valgrind with kcachegrind is competitive with $3,000 offerings from Rational (er... IBM)

but if your using gdb you _are_ a unix programmer. GDB is actually pretty simple to use _if_ you read the documentation. Anyone who isnt capabable of that certainly isnt capable of producing good software.

1. Step through code by hitting a single function key.
2. See the current line of code in context within the source module.
3. Print out variables by clicking on them.
4. Watch a list of variables.

We have a shop full of unix programmers woring on AIX. They use dbx because it's there, but they don't like it. I personally am okay with dbx, and when I code on Linux (we're in the process of porting from AIX to Linux), I find gdb to be comparable, but even less intuitive.

Believe it or not, one of the reasons we want to switch from AIX to Linux is to get access to more up-to-date programming tools like kdbg. Kdbg may not be as powerful as gdb, but our programmers are itching for something like it. I hear it's possible to get kdbg up on an AIX box, but I don't trust it to work reliably in that environment (and our dev machine is too low-end to run X apps well anyway). I did bring up ddd on that box, and found it less useable than dbx. One of our programmers swears by IBM's idebug.

I do wish that kdbg would give you some way to get at the gdb command line. Or better yet, provide some kind of macro facility to allow you to click on a variable and pass it to a function. I make a lot of use of the dbx 'call' command (I assume gdb has something similar). For example, we have a binary 'record' format that can't be understood by simply dumping out the data. I've provided a library function to print it, which is linked into all apps. I then set up an alias command in .dbxinit to allow you to call that function to print out these records within the debugger. It's really handy. Some of these functions are even interactive (prompting the user for input). Very powerful.

While I'm venting my wishlist, it'd be really nice for kdevelop to be able to work from existing makefiles instead of insisting you use their automake (or whatever) support. We've got tons of these already set up (and I believe we may even be incompatible with automake - have our own config.h for platform dependencies). I wouldn't expect kdevelop to be able to generate the makefiles, but it'd be nice if it'd let you edit source files, rerun make and debug...

Well, you _can_ import custom projects into KDevelop 3.0 and work on a non-automake basis. It does not yet provide all of the functionality their automake manager does but it is reported to work after all.
Moreover, this probably will change with upcoming versions as a a rewrite of this part is on schedule not far from now.

Sco has no case. On the German market I am free from SCO but I think it would be very fruitful to call for a criminal investigation into the SCO group in other parts of the world. A criminal charge has to be filed against SCO as it is probably fraud. One year ago I thought SCO might have a case but the sort of media campaign made this very unlikely to me. A state attorney is an independent source that can determine whether SCo's license policy is fraud. We just have to report the offence to the police and the judicial body will care about the criminal charge. This shall be done in states where SCO sells it doubtful licenses on the market. So perhaps this may be a way to hold someone at SCO responsible.

A copyright infringement is a simple task in business and is usually silently resolved, no big deal. But the kind of communication of SCO and the baseless accusations were infringing upon almost every single business rule. In Germany(tarent vs. SCO) they were prohibited because of competition law. Accusations without proof are dirty business and have to be stopped.

As a developer (not on Linux however; at an ISV that writes custom payroll solutions, on overwhelmingly Windows-based targets), I think that nearly all things in terms of needed development platforms on Linux platforms are already *there* (cross platform development tools such as Eclipse and world class component APIs such as kparts are extremely important).

What is holding a massive amount of VARs and ISVs from Linux development isn't the lack of tools, but rather potential users. I think this is slowly changing, thanks to the positive contributions of OSS projects like KDE.

You are right on one level that if there were more users then vendors would write software.
However I would be releasing KDE utility software today regardless of the market size if there was a cross-platform tool at a reasonable price. Kylix looked like this, but it seems to have gone into limbo.
Even if there was an easy to use KDE only tool at a price that is appropriate for the free utilities that we supply to support our products, we would write them because we could.

Delphi Professional is $1000 for a complete and very productive programming environment.
Qt is ~$4000 just for a toolkit if you want cross-platform. Given that we have 0 KDE customers (all our paying Linux customers are embedded, and do thier own thing), this is just far too expensive for my market niche.
SAP or BMW mightn't blink at QT's price, and a company writing a custom payroll won't either, but for the small vendors its very steep to get tools which are not up to Windows standard for ease of use, productivity and completeness.
Note that only 5% of our website vistors (who are very technical) are using Linux desktops. This applies particularly to hardware vendors (like us)for whom the software is all cost, and no income.
A look at the windows world wll show you that a lot of its strength comes from the small shareware vendors and the like. It is impossible for them to write for KDE (except using BlackAdder).

A reasonable price QT license is urgently needed for KDE.
I suggest that someone in KDE tries to negotiate a $200-$500 professional version of KDevelop with a QT license, like what TheKompany have done for BlackAdder. This might bring some cash in for development too.

Otherwise shareware, specialist, hardware and small ISV's will continue to go with GTK,wxWindows, and Java as 95% are doing at present.
KDE will be the desktop, but none of the apps will be native.

You might ask: Who cares if commercial vendors ignore KDE, we'll just write it ourselves. However a close look will show you that most KDE applications are small and uncomplicated. There are very few deep and complicated KDE apps that work. MP3 players and IM apps are icing, not the cake.
Matlab, Gimp, Abiword, Scilab, Dataexplorer and others are GTK or Motif or Java or anything but KDE.

I think this is approaching the nub of the issue .... The long term question is, will KDE or Gnome become the predominant desktop.

The arguments about the license costs of Qt are largely irrelevant. Its free if you are non-commercial and if you are a company then it's small compared to all your other costs, especially when you factor in programmer costs vis-a-vis productivity (I believe that this both for "developed" countries like the UK, US, Australia, Japan and "developing" countries like India, those in South America) (please, no quibbles here, you get the idea...). Currently the "desktop battle" is in a state of flux, hence the majority if ISVs going Qt.

But, the crunch question is not what the ISVs prefer, it is what platforms they are going to have to write to. If Gnome is favoured by the major distributions then the ISVs will write apps on Gnome/GTK and not KDE/Qt, whether they like it or not. With SUN's "java" desktop and RedHat both favouring Gnome, ditto "UserLinux" (if it gets anywhere) and with SuSE and Ximian now owned by Novell, I think that there is a real chance that KDE will get marginalised. And, having written both Qt/KDE and GTK code, even allowing for the fact that I'm much less experienced with the latter, I see that as a real shame, because Qt/KDE is just *so* superior.

My gut feel is that TT should seriously look at changing the license for Qt, at least under X11, either to grossly reduce the license cost or even LGPL it. My fear is that if Gnome/GTK is ascedant then at a commercial level they will be squeezed out of the desktop market, in which they will loose that part of the income stream anyway. And, since most people will start GUI programming in a "desktop" environment, if they start with Gnome/Gtk then later on, as they move up the IT ladder, there is a danger that Qt will be squeezed in other areas.

"Otherwise shareware, specialist, hardware and small ISV's will continue to go with GTK,wxWindows, and Java as 95% are doing at present. KDE will be the desktop, but none of the apps will be native."

I thought you said there wasn't a market for Linux desktops? If there isn't the need for large companies, there certainly isn't the need for small ISVs and shareware developers. The vast majority of desktop applications developed are for Windows, maybe a few for Macs, and no one uses GTK, wxWindows (wxWidgets) or even Java here.

"If Gnome is favoured by the major distributions then the ISVs will write apps on Gnome/GTK and not KDE/Qt, whether they like it or not. With SUN's "java" desktop and RedHat both favouring Gnome, ditto "UserLinux" (if it gets anywhere) and with SuSE and Ximian now owned by Novell,"

Every major distribution ships KDE, and where there is a total focus on one desktop, those distributions exclusively use KDE. You will not find any distribution that exclusively ships Gnome. The JDS does, but it isn't popular, despite the hype (nor does Sun have a direction for it), and Ximian Desktop at the moment is an orphan. Red Hat's desktop strategy has been a failure, which is why they pulled it. Red Hat still ships KDE, and they have a hybrid Blue Curve desktop.

"I think that there is a real chance that KDE will get marginalised."

Sorry, but people have been making these comments for years and the situation has not changed. There always seems to be a 'real chance'.

"But, the crunch question is not what the ISVs prefer, it is what platforms they are going to have to write to."

At the moment Linux desktops are just not on ISVs' radar. Most are probably not familiar with Linux desktops beyond having heard of them. People who are not realistic about this will doom desktop Linux to failure.

"My gut feel is that TT should seriously look at changing the license for Qt, at least under X11, either to grossly reduce the license cost or even LGPL it. My fear is that if Gnome/GTK is ascedant then at a commercial level they will be squeezed out of the desktop market, in which they will loose that part of the income stream anyway. And, since most people will start GUI programming in a "desktop" environment, if they start with Gnome/Gtk then later on, as they move up the IT ladder, there is a danger that Qt will be squeezed in other areas."

I see a lot of these comments, but people forget one thing when they make them. > 95% of the world does not use Linux desktops, either KDE or Gnome. The business world is as close to 100% desktop Microsoft as you can get, so I laugh at people who talk about corporate Linux desktops and 'corporate focus'. Certain people want to talk about business desktops - there it is. If GTK and the Gnome programming technologies are inferior (certainly to Windows) then no ISV will ever contemplate using them, because they will use the extensive and good development tools available for Windows first and foremost. If there is a first-rate cross-platform alternative, like Qt, then they *might*.

We also inevitably get the VHS vs Betamax comments, where KDE is superior (admitted by practically everyone) on the Betamax side, and Gnome is VHS. I'm sorry, but Windows is VHS and everyone else is Betamax, and this happened a long time ago. If a Linux desktop is not on a par, or better, than Windows no one will touch it.

It all just shows the lack of realism that many people have concerning the future of desktop Linux and free desktops in general I'm afraid.

My prediction is that not too far in the future you will get the "goddies" for GTK/Gnome in proprietary extensions to libglib, libgtk, and libgnome and not in the LGPL-base. Why would a member of the gnome foundation give an advatage to its hated competitors?

ATK already is such an extension, although LGPL at the moment, copyrighted by Sun MS. In the Qt universe you just dont have this problem (remember X/Motif?).

Another note about a LGPL Qt. IT ALREADY EXISTS! just look in the WebCore code written by Apple (in the kwq subdir). Everyone is free to implement Qt. Its not patented like .Net, and its open source. So its not like TT is the ultimate power in the Qt universe.

"My prediction is that not too far in the future you will get the "goddies" for GTK/Gnome in proprietary extensions to libglib, libgtk, and libgnome and not in the LGPL-base. Why would a member of the gnome foundation give an advatage to its hated competitors?"

> We also inevitably get the VHS vs Betamax comments, where KDE is superior (admitted by practically everyone) on the Betamax side, and Gnome is VHS. I'm sorry, but Windows is VHS and everyone else is Betamax, and this happened a long time ago. If a Linux desktop is not on a par, or better, than Windows no one will touch it.

> It all just shows the lack of realism that many people have concerning the future of desktop Linux and free desktops in general I'm afraid.

The thing is, if you compare technologies, GNOME is VHS, and Windows is Betamax. With the exception of some things (GTK+'s layout engine, for example, Mono, potentially) GNOME is a pretty traditional platform. Even when the technologies exist (Bonobo, GNOME-VFS), very few applications actually use them. At a technical level, KDE is really the only one that matches up to Windows. You've got KParts to replace COM/OLE, you've got DCOP-scripting to replace Windows Scripting Host, you've got the broad, integrated KDE API to replace the messy but very featureful Win32 API, and you've got things like KIO that really have no comparison on Windows.

As for the Betamax vs VHS thing being a long time ago --- choosing inferior technologies is a historical curse of the computer industry. Its not just a single isolated case, but happens continually. Consider PC hardware vs Mac hardware. Windows 95 vs MacOS. D3D vs OpenGL. Go back further in time and consider the failure of NeWS, Smalltalk, Lisp, etc. I'm not saying that superior technologies never win, I'm just saying that, historically, the odds are not comforting. Now, KDE is different in a way, because KDE is open source and thus not subject to the same market considerations as these commercial products, but it's still something to be wary of. After all, those who don't understand history are doomed to repeat it, right?

"My gut feel is that TT should seriously look at changing the license for Qt, at least under X11, either to grossly reduce the license cost or even LGPL it."

When will this stupid licensing bitch go away? I am of the firm belief that no matter what Trolltech does, Qt will always be the evil toolkit. Consider its licensing history. The KDE Free Qt Foundation wasn't good enough. The Q Public license wasn't good enough. Qt being released under the GPL wasn't good enough until Trolltech got forgiveness from everyone it wronged. Upon discovery that Trolltech didn't wrong anyone, the argument suddenly turns upon the GPL itself. Then there were the occasional non-license evidence that Qt was evil incarnate: it uses C++, uses a metacompiler, didn't use the STL, etc.

That's a good question. I saw a value of $4000 but I seem to recall $1500. At any rate whether it's single or multiple platform there's still breaks for volume licensing and funny thing, it's still selling. BTW .NET developer network is $4000 per year last I checked. I think in the US you can safely estimate $50K-$60K for software engineers. I'm sure it varies but the bottom line is that it's expensive to have a room full of them. Those costs dont' reflect probably 30%-40% additional payroll expenses and other overhead in the cost of doing business. Development cycles are at least 18 months and usually longer. So the bottom line is if that if you have a market and the toolkit saves you 1% or more in your time it's worth it. Period.

> This applies particularly to hardware vendors (like us)for whom the software is all cost, and no income.

I'm asking this without knowing at all what you do, and if it would apply, just to ask. What prevents you from GPL'ing your stuff? Obviously the value isn't in the software.

The reason I ask is simply this: why should I count on a binary from someone that may very well not work a year from now on my boxes? Especially with the desktop, things are changing very fast. QT4 is on the horizon, which means binary incompatible. This is a reality, some say a feature, of FOSS development.

I think the RAD category of software was partly motivated by the thought that one could finish your project with the possibility of the vendor still being in business.

I looked at Delphi. I have used it on Windows, and it is an impressive product. The problem was that the users would have to essentially maintain a parallel universe to run the software. With no possibility of anything except at the will and mercy of Borland. Obviously I wasn't the only one who thought the same way, since Borland has essentially orphaned it.

If I want a secure, long lasting environment, I have two choices. Microsoft, or a FOSS project that has been around for a while, with an active community and a few well established commercial participants.

As for the price for a QT license, that is up to them. If they are losing market due to the high price, I suspect they'll drop it. Unfortunately, around here you have around 250 or so active developers who have contributed far more value to the project than $4000, so they may very well not have sympathy for those who are willing to ride the train, but unwilling to pay the ticket price. Think libre, not gratis.

Orphanned delphi? Come on now. There is a very strong and active community around delphi, and borland continues to see this, and continues to release this top notch IDE. They have just released version 8 which integrates with all of microsofts newfangled .net garbage because there was developer demand. I agree that it is unfortunate that Kylix seems to have gone by the way side, but lack of demand seems to be the main reason. It was technologically a good product. Desktop linux is just not as popular in the sectors where delphi is most prominent. Although, if you look at the delphi component market, you will see that many many of the independent providers have done the work to ensure their products work both with delphi and kylix.

As far as 'maintaining a parallel universe to run the product', that is also an absurd comment. As a delphi developer for the last 6 years, and building large complex applications database applications that integrate with postgresql and oracle, I can tell you that delphi applications can run on a bare bones installation of any version of windows with the appropriate database drivers (in my case ADO). Can you say the same for kde or qt apps? Can I take a qt app built with kde 3.x, and run it on ANY version of kde? Most certainly not.

I respect your comments Derek, but in this case I think you have unfortunatley spoken prior to having appropriate knowledge. Looking at delphi does not consitute knowing anything about it.

I meant kylix. I tried delphi and liked it. I didn't like kylix, it didn't fit well into my linux system.

Kylix is the linux version of delphi. I'm not quite sure of the differences, since it's been a while. Borland's foray into the linux marketplace will probably end up being an object lesson on how not to do it. Unfortunately.

I think the lack of a good migration path from VCL to CLX was the main reason.
Or why would Borland not be able to release their own IDE as a native application but had to use winelib?

> It was technologically a good product

I think it isn't.
If you look at programmers questions in newsgroups and webforums, developing with Kylix seems to be more difficult than Delphi programmers expected.
Additonally CLX is designed around 1980's technology, for something like rotating text one has to access the underlying Qt API or on Windows fall back to hacks like loading a vertical font.

> Can I take a qt app built with kde 3.x, and run it on ANY version of kde? Most certainly not.

Sure, Kylix apps wouldn't work on recent KDE if it weren't possible, as Kylix uses Qt2 and current KDE installations use Qt3

Delphi and Kylix-Pascal came together for the one price. Thats exactly what I wanted.

I don't think that Borland on Linux is dead, to me they appear to have shifted all resources to .NET so they don't let the wife walk out, while fiddling with a mistress. The offical word was that there won't be any Kylix releases this year. But who knows what they will go with when the return to Linux, probably they don't

Those reasons are absolutely bogus and make no sense. The license one does though. This is why it is crucial for KDE to continue its efforts to integrate GTK into the environment.

Besides, haven't you noticed Sun aren't interested in GNOME technologies in the *least*. This is why their system is called Java Desktop System. They want their developers to use Java not inferior stuff like GTK. The fact that the native system is in fact GNOME is a dirty little secret but GNOME is just acting as a shell.

JDS being based on GNOME is certainly not a dirty little secret. Sun have been more than willing to give credit where credit is due - moreso than some of the other GNOME contributing companies, in fact - in all of their press and announcements. It is called the "Java Desktop System" for Sun branding purposes, not for any sneaky way of hiding the fact that it's based on GNOME.

You're not being objective about this. Clearly Sun is pushing this as Java. If they wanted a "branded" GNOME they could have called it Sun Desktop System not something deliberately misleading and false like JDS.

It is clear that the focus here is Java. GNOME is acting as nothing but a shell for the Java platform.