The next version of KDE4 will run natively on Mac OS X and Windows XP and Vista. This means that it is a very attractive platform for software development. No other cross-platform toolkit looks as good as Qt and has an equally appealing API.
Linux and Mac OS X are steadily gaining popularity. I know from experience what a delight it is to administrate a large park of Linux computers, desktop and server. There is a tremendous software choice that can easily be updated and managed and kept in check. Departments or whole companies that can get away from windows, do so more and more. And in the wake of the successful iPod, Macs are reappearing on the workfloor. This means, that the market for cross-platform tools is growing again. And this is where the KDE development environment is a very credible proposition.
The foundation of KDE is a professional toolkit, Qt, that is used for many enterprise applications already. Once a software development company has bought a Qt license for releasing software under a non-GPL license, KDE is a free added bonus. This is the path many companies will take and KDE endorses this option by releasing the KDE source code under the LGPL license.
If a company is confident enough to use the GPL license for their software, they can use Qt without paying a license fee. In the community, this is a controversial issue. Some hold that companies will not want to pay a license for Qt or are afraid to develop with the GPL. However, companies that want to sell shrink-wrapped software work on a scale where the cost of the Qt license is not an issue. This leaves companies that develop special solutions for a relatively small number of seats.
These companies should have no problems with releasing their code under the GPL. It is a sign of confidence and quality to do so. By releasing code under the GPL you are saying that your code can live up to the scrutiny of the user. You are proud of your code and you are not afraid to show it. And there is no reason to be afraid of the competition taking the code and running with it. Because if they do, they must also release under the GPL. Moreover, the cost of taking over a project with a limited deployment scale is much larger than the risk of someone copying your business. The value of special software is in the service, not in the code. And if your customer decides to switch to another company because they are not happy with your service, then the competitor will not want to touch that code either. Releasing code under the GPL is sign of confidence and quality.
KDE4 will be a big step towards an enterprise software business based on free software. The software on the big servers is there already, the desktop is next.
Comments
If the world were only so neatly organized...
However, companies that want to sell shrink-wrapped software work on a scale where the cost of the Qt license is not an issue.
We say that a lot, but it's simply wrong. It assumes that software companies develop software by sitting down, considering all possible solutions, doing a cost-benefit analysis (in consultation with their software engineers), choosing a strategy and then acting on it.
In practice that's so rare that I'd say it's statistically insignificant.
From what I've seen are three basic ways that technologies are selected:
Submarinie projects. A developer develops something that he's not been asked to and picks whatever tools he wants. If it becomes something they think they think they can impress their bosses with, they show it to them. If the boss is impressed it often becomes a project. The technologies are rarely changed after that point and their appropriateness is a factor of the original developer's experience.
Dictated from above. Sometimes this means buzzword compatibility; sometimes it means that there's an experienced developer leading the team that has the ability to choose which technologies will be used. The choices rest on the person calling the shot's knowledge of the field, their ability to justify to their managers associated costs and, well, luck.
Corporate apathy. "We need $15000 to buy this software." "Uhm, ok." Sometimes, especially in big companies, it really is that easy. Until it takes nine months for the lawyers to approve the contract.
I've worked for small, medium sized and huge companies and I've seen variations on those themes (including choosing Qt, which in niche areas all three companies that I've worked for have) over and over again. I have, on rare occasions, seen things closely studied and decisions made, but that's very much the exception to the rule.
All three above scenarios play into Qt selection. In the first case, the developer usually has to chose if they want to ignore Qt's licensing conditions and hope that if the project is cool enough that they'll be able to persuade their bosses to purchase licenses. If not, that may be grounds for scrapping the developer's pet project and they have to decide if it's worth risking it. In the second, well, we see that a lot in Qt-oriented companies, i.e. KDAB. It doesn't matter what you like or don't like. If you work for KDAB you're going to be using Qt. And that's probably a good thing. In the last, I saw that in action for Qt and other technologies, but the approval process almost killed development because of the waiting time.
The other thing that seems to often not be considered is that Qt isn't always used pervasively. Sometimes it's used for only a small or sub-project. In that case, where there may only be one or a few Qt licenses it also has an odd effect on development dynamics (and like all of the situations above, I've seen this personally) because it means that only x number of developers can touch that piece of code. I've had to rewrite patches from coworkers because they weren't allowed to touch the Qt stuff because I had a license and they didn't.
And a comment on GPL-ing things -- it's often not possible in commercial development, for completely non-idealogical reasons. I've worked now for two proprietary software companies, and in both cases, significant portions of our stack were non-GPL-compatible components. (For instance, at my current job, the gratis, but proprietary, VST interface from Steinberg.) I've in fact got OSS projects where I avoid Qt for the same reason (where linking to a specific, gratis, proprietary lib is critical).
I love Qt. Seriously. After working more and more with other abstraction layers and system APIs I realize how powerful it really is and I believe that Trolltech's prices, in cost-benefit terms, are fair. But to pretend that paying for licenses is a non-issue mostly ignores the way that technologies are selected in the first place. In a market with competition that tends to be gratis, adding significant cost and red tape can be a significant deterrent to a technology's adoption. I think keeping that in mind is key to any promotion strategy.
(Hmm, maybe I'll repost this in my blog.)
By Scott Wheeler at Wed, 08/01/2007 - 01:55
addressing the different cases
We say that a lot, but it's simply wrong.
The scenarios you sketch are certainly very familiar. Yet I do not think they invalidate the point I was making. Surely, licensing can be a mess. For both commercial licensing and for licensing under the GPL you need to somehow keep track of what the licenses of your software stack are. If you have software that cannot be relicensed you have no choice but to buy a Qt license if you want to use the KDE4 libraries. And if you have bought a license for a certain number of seats, those seats will have to use the license. These restrictions apply to most commercial packages. Still, if you are using Qt, you get the KDE stack as a free bonus: all KDE libraries are available to you at no extra cost even if your application is closed source.
In your first case, the serendipitous project, the decision has to be made: buy the license or release as free software. This decision falls along the same line as the question for which reason you release such a project. Either it is a good PR move -- you want to give added value to a hardware project or get attention for a service like e.g. Magnatune -- or you want to make hay from a brilliant idea that you want to protect. In the last case, it does not matter if the idea is in the dependencies of the small project or not. The idea is somewhere in the code and to keep it closed is valuable to you. This value will allow you buy the Qt license if you do not have it yet. If your brilliant idea or set of ideas are not worth such a purchase, it must be pretty trivial and you might as well relicense or reimplement.
In the second case, buying Qt should be no problem. The person dictating the decision has already decided to use Qt and must have taken it into account in budgeting. Or he must have decided to release the work as free software. I argued that the latter is a very good idea for many projects. The value is often in the service you provide and not in the code. And emphasizing that and providing the service as GPL code is a sign of quality.
And also in the last, wonderfully telling case, buying a nice license is no problem. Apathy and too much funding is a strange, yet not uncommon scenario. This was highlighted by an item in the dutch news yesterday. It said, software budgets are increasing but service is not. In such an environment, customers will become more critical and asking for the GPL not be unheard of.
The problem with the seats can be a drag. It is a problem that is often not considered in the free software world where code is available at no cost. But like I said, this is no different from most commercial development platforms like for example MS Visual Studio and Borland.
By Jos van den Oever at Wed, 08/01/2007 - 06:46
In your first case, the
In your first case, the serendipitous project, the decision has to be made: buy the license or release as free software.
Well, but that leaves out the most common option -- drop the project. Which is always what a developer fears when they're working on something like this.
This value will allow you buy the Qt license if you do not have it yet. If your brilliant idea or set of ideas are not worth such a purchase, it must be pretty trivial [...]
Again, this is correct, but it's leaving out the psychological / political bits of the decision making process. It doesn't rest on value, but the case you're able to make for that value. You might have managers that say, "Why not?" but the need for several thousand bucks of licensing costs might tip the scales the other way. And more importantly, the developer, when making the original choice of what to develop with may fear that critical point, even knowing that Qt is the best choice.
In the second case, buying Qt should be no problem. The person dictating the decision has already decided to use Qt and must have taken it into account in budgeting.
That's right. Usually this is the one that I think we see for Qt adoption (though, admittedly in the rare case that the person making the decision has some experience with Qt). Often the person dictating this has enough influence to convince his managers (if they exist) that Qt is worth it.
But like I said, this is no different from most commercial development platforms like for example MS Visual Studio and Borland.
Maybe conceptually, but (a) both of those examples have freeware versions and (b) are an order of magnitude cheaper. I don't think it's really such a stretch of the imagination to envision no problem buying all of our VS (standard edition) licenses for EUR 6644 (30 licenses), but picking up the same number of Qt licenses (two platform, desktop edition) for EUR 110000 takes a lot more convincing.
By Scott Wheeler at Wed, 08/01/2007 - 12:21
qt pricing
Granted, Qt pricing is steep. I just checked it on the website and it really is expensive. Buying a Qt license is not something you do lightheartedly. Especially not, if you plan to buy upgrades every year. I cannot judge how excellent the support is, but if it is anything like #qt and #kde-devel then it is very good.
Your 30 seat example is a bit of a stretch. I'd imagine you'd get a bulk discount for such a number of licenses.
By Jos van den Oever at Wed, 08/01/2007 - 17:03
A company that respects
A company that respects itself will pay the license fee for every program they're using. I wouldn't wanna work in a place where I have cracked software.
---
Mary-Anne Davis, outsourced affiliate.
By maryadavis at Fri, 06/06/2008 - 10:47