Qt-contributors-summit-2013-Open-Business-Architecture

This article may require cleanup to meet the Qt Wiki's quality standards. Reason: Auto-imported from ExpressionEngine. Please improve this article if you can. Remove the {{cleanup}} tag and add this page to Updated pages list after it's clean.

Open Business Architecture

What we want to achieve with OBS: Qt in general right now is strong in the horizontal space, but doesn’t offer ready-made solutions in most verticals. Companies want to make money with Qt by selling e.g. modules, parts, services …. Users might be interested in these. QBS is the channel to connect a large number of customers with providers.

Why is Digia interested in developing this? It’s good for Qt, it’s good for the business.

Example: Say if somebody is looking into developing a medical solution. If he finds ready-made components for medicals immediately it might get him to use Qt.

There’s a very solid user base of Qt. More and more people are also Qt Creator. This is a solid baseline, and there’s something like a common environment for the users. Other things that might be used is bugreporting, etc. Also, companies that might be offering only related to Qt development are interested in a channel to reach users.

How does that relate to qt.io? In general qt.io is pretty open, but there might be changes requried, e.g. if one wants to use bugreports.qt.io for purely commercial projects one needs to change the license.

Is this a replacement for the Qt customer page that we used to have? Not exactly. It should be more than that. It’s also not only limited to.

Are there related marketplaces? E.g. Ruby gems, .NET accellerator. Some of them are however not as open as we used to be.

What is the model for the revenue stream? We use that kind of licensing framework in place for the Qt Enterprise edition. However, something like checking of runtimes is hard. Maybe the online payment system of Engine.io can be used, too. The payment system in general would be work like an appstore where the revenue is split between the platform and the developer.

Have you considered the potential negative effects? For example that there are two competing implementations of the same cryptohash algorithm. If it’s an illegal copy that can prevented. Other means of mitigation are policies , selling support …

Who will do the building, testing etc? THe platform, or the provider? Good question, there’s no good answer yet, most likely there are multiple ways offered.

Qt store for ready apps? It should be primarily a developer offering, but maybe in the future that might still help.
Is that a channel for individual subcontractors, too? Or application templates? It’s a hard choice, they tend to degenerate.

The idea should be really stripped down to a manageable part. Reviving e.g. a wiki with a partner page would be a good idea too. However, the value proposition of this would rather be to sell components.

What about integration in app store? There’s no API’s typically for app stores.