[Kde-bindings] Qyoto for companies

[Phil Thompson]

On Monday 24 September 2007, Richard Dale wrote:
> On Saturday 22 September 2007, Arno Rehn wrote:
> > Hi,
> >
> > It seems like Qyoto and Kimono are getting more and more attention:
> > http://lists.ximian.com/pipermail/mono-devel-list/2007-September/thread.h
> >tm l#24947
>
> A very interesting read - it looks like Qyoto works pretty well on Windows.
>
> > If they really want to use Qyoto in a company, we should consider some
> > dual licensing, like PyQt. Furthermore we'd need to test some builds on
> > MS Windows. That should run pretty out-of-the-box, though.
>
> Yes, I agree Qyoto would probably work very well on Microsoft Windows and
> Mac OS X compared with other 'cross platform toolkits'. But someone needs
> to pay us (ie Arno and myself) to make that happen. I can't see any point
> in giving away a commercial license for Qyoto for nothing in return.

There's a huge difference between "nothing in return now" and "nothing in 
return ever".

> There 
> are relatively few people involved in the development of Smoke, PerlQt,
> QtRuby and Qyoto, and they are all reasonable people and so I think we
> could negotiate a dual license scheme for Qyoto with them.

Maybe if I relate my experiences with PyQt...

PyQt was first released (as PyKDE) in 1998. There have been releases about 
every 3 months ever since. The license was a permissive license (basically 
BSD style).

When Qt for Windows was released I was approached by a company to port PyQt to 
Windows. They provided the tools, I provided the time. This was my first real 
clue that companies were already using PyQt (with their commercial Linux/Unix 
Qt licenses). I decided to try and sell PyQt. This was made slightly easier 
at the time because I wanted to set up a company for other reasons as well so 
it wasn't such a big step just for PyQt.

It made sense to closely follow the Trolltech business model - so PyQt became 
dual licensed GPL and commercial. Companies were quite happy to switch to 
being commercial customers as they already had commercial Qt licenses and the 
additional cost of PyQt wasn't significant. The (pleasant) surprise was how 
many of them there were. The rest, as they say, is history.

The absolute key to this was the initial period when PyQt was free and had the 
permissive license, but with the disciplines expected by customers (timely 
bug fixes, backwards compatibility, stable releases, regular releases, 
versioned releases). During that time PyQt established a reputation for 
quality and gave the impression that it was going to continue to be actively 
developed for a long time - the sorts of things that companies need to feel 
comfortable about before committing themselves.

For a commercial Qyoto to be successful it *has* to establish a similar 
reputation *before* you start to ask people to pay for it. Doing so can be 
expensive - but only in terms of the time required of the people involved 
(but if you're not prepared to work hard then you don't deserve the rewards).

> At this years aKademy I gave my opinion to Knut Yyrvin about what I thought
> of Trolltech's relationships with Qt bindings developers. I said that we
> really aren't on their radar and they are doing nothing whatsoever. With
> partners like that, it is very hard to justify going into business based on
> developing commercial Qt bindings.

My experience has been that, in general, the techies don't like PyQt because 
they don't like Python - C++ is wonderful so why would anybody want to use 
anything else.

The marketing/sales people, on the other hand, like PyQt because it allows 
them to sell Qt into companies that wouldn't otherwise be interested. Note 
that this is a particular strength of Python - there are whole industries 
that have standardised on Python as an application development language. I 
would imagine that Qyoto would be in a similar position (though for different 
reasons).

Phil