[Kde-bindings] Qyoto for companies

[Phil Thompson]

On Tuesday 25 September 2007, Richard Dale wrote:
> On Tuesday 25 September 2007, Phil Thompson wrote:
> > 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/thre
> > > >ad .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".
>
> They can use Qyoto for internal developments as the GPL only applies if
> they distribute the software. If it works well then we can expand to offer
> a commercial license, but to me that comes with expectations of 'commercial
> quality' that we don't currently have the manpower or funding to deliver
> on.

It depends on the price you charge...

> > > 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).
>
> I don't think Trolltech would be keen on that now. I asked about whether it
> would be ok to change the QtJava bindings license from GPL to LGPL so that
> commercial license holders could use it, and Trolltech said they wouldn't
> be happy with that, although a dual GPL/commercial license would be fine.

Legally they can't stop you so long as you choose a license that they have 
allowed as a GPL exception. Politically it's another matter of course. You 
need to understand the reasons for their response - was it the clash with 
Jambi, so they might not have the same objections to Qyoto?

One solution would be to dual license but charge nothing for the commercial 
version (for a year or so). Your first commercial users will be companies 
that are already using commercial Qt so you want to make it easy for them to 
(unofficially) try out Qyoto.

> > 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.
>
> Caleb Tennis's company paid for porting QtRuby to Windows and that was
> really welcome. But nobody else has stepped up to the plate and offered
> ongoing funding - so I wonder how many companies there are out there who
> would be interested in a commercial version of QtRuby. There has been less
> interest in terms of similar Qyoto funding offers so far (ie none).

I think you are overstating the need for funding. With PyQt the funding was 
important because it changed my perspective - the money itself was a minor 
consideration.

> > 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).
>
> Yes, I agree. I really don't think we have attracted enough contributors,
> and it is only Arno and myself pretty much most of the time (and not much
> from me recently). So pretending it is a viable option for commercial
> development before we've put in the work to make it really rock solid might
> be counter-productive. I'm very impressed with how you've managed to turn
> PyQt into a business.

It's up to you to break the chicken-and-egg cycle. You already have at least 
twice as many developers as PyQt has ever had (that's slightly 
tongue-in-cheek in case Detlev, Torsten or DavidB are reading) . What you 
don't have is any community (a mailing list, people who help newbies, port 
examples, write books, test obscure corner cases). You need to build that 
community.

> > > 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).
>
> Yes, this is why I was a bit frustrated when I heard that Knut hadn't
> managed to produce the live CD with C++, Python and Ruby bindings and Qt
> educational materials aimed at students that he was talking about at the
> Dublin aKademy. I have certainly helped many people learn QtRuby
> programming who didn't know C++.

If you want something done, do it yourself - but make sure you prioritise.

> -- Richard

Phil