JPz'log Coin Coin and Plop da Plop

The limits of opensource for small shops

There is no definite business model for opensource software. That's a topic I had the chance to discuss with many people in the past such as my friend Alexis. Clearly, each software is its own case, and what works well for one project is probably not a very good recipe for another one.

Among the factors that you have to consider, we have:

• who you are (big corporation, small shop, individual developer, ...)
• the size of your "market"
• what you expect people to do with your software (is that an application? framework? library?)
• do you make that for pure fun? for taking control of a significant market share?
• do you want to monetize your work?

That's clearly not easy, and stuff may be moving rapidly from the birth of your project to the point where you hit success.

One striking example that I recently found is Nokia launching the PySide project, whose goal is to provide Qt bindings for Python.

For many years, there was a (relatively) small company called then Trollech, based in Norway, that was editing the excellent Qt framework, a cross-platform C++ GUI toolkit of excellence. It even moved into a full-blown C++ framework for cross-platform development, abstracting the disparities between operating systems (threading, I/O, networking and so on).

Trolltech was making a living by dual-licensing Qt:

• under the GPLv2 for opensource development (e.g., the nice KDE environment)

, and

• under a commercial license for proprietary software.

Qt was a typical example of a business model based around the evilness of the GPL: the opensource license helped the framework gain momentum while the nasty GPL forced non-opensource developers into buying a commercial license and support bundle.

Another company called Riverbank had developed PyQT,a binding for the Python language, resulting in a powerful combination of a solid dynamic language and a first-class GUI toolkit.

The company behind PyQT was not developing it for philantropic reasons: they opted for the very same dual-licensing scheme too, thus deriving revenues from their work on PyQT.

Meanwhile Nokia acquired Trolltech, meaning that Qt would now be owned and developed by a big corporation rather than a small/mid-sized shop. Nokia does not depend on the Qt commercial licensing revenues, and decided that it was more important to grow the Qt market share than anything else. The outcome is that while there is still a commercial support for Qt, it is now licensed under the GPL, the commercial license and the LGPL.

As someone who is more inclined toward permissive licenses, I appreciate this move, as now anybody can use Qt in a project under any license, simply because the LGPL is not boring you as long as you do not modify Qt itself.

In the meantime, Riverbank is still releasing PyQT under the GPL and its own commercial license, as otherwise they can reasonably expect a drop in their revenues (i.e., "apart from paid support, why would you bother paying for their commercial license if it's under the LGPL?"). One may argue that paid support is often more lucrative than licensing revenues, but it again depends on what you are developing: PyQT is the kind of opensource code that does not really require paid support. Just think that it targets good developers than have no problems digging into Python code (plus, PyQT is already mature and solid).

The Python + Qt combination is highly valued and praised by developers, and Nokia decided that they would need a LGPL Python binding in their bid to grow the Qt marketshares. Given that Riverbank cannot afford to release PyQT under the LGPL, Nokia launched their own bindings. Even better, they made the bindings compatible at the API level.

The following excerpt from their FAQ is eloquent:

What about PyQt?

Nokia’s initial research into Python bindings for Qt involved speaking with Riverbank Computing, the makers of PyQt. We had several discussions with them to see if it was possible to use PyQt to achieve our goals. Unfortunately, a common agreement could not be found , so in the end we decided to proceed with PySide.

We will however maintain API compatibility with PyQt (you can use the same method names but can’t inter-operate with PyQt), at least for the initial release. To import PySide you have to use “import PySide” instead of “import PyQt4″.

As you see, this is clearly a limit of opensource for small shops like Riverbank. What a company like Nokia can afford to consent, a small shop like this cannot unless they find another business model. In this specific case, I however don't see any other way to monetize their hard work...

On a personal note, I have ambivalent feelings towards such a story. I am quite happy to finally see a LGPL Python binding for Qt, as even when I develop opensource software, I do not appreciate to be bound by the terms of the GPL. However, I feel the pain for the Riverbank guys who made a terrific job but did not have much chances to find an alternative business model. Time will tell wether PySide gains some mindshare or not, but I honestly think that they have a great chance of doing so.

Given that this is a very complex topic, I would be very interested in hearing from you through comments on this post!

Related posts:

1. Puritan opensource license
2. Thoughts on F/OSS (3/10): main business models
3. Google Adsense: a disruptive open source projects booster
4. Thoughts on F/OSS (1/10): quick facts
5. Thoughts on F/OSS (2/10): why making F/OSS?