Benefits of co-existing open source & commercial software development

Authors: Tuukka Turunen (Digia), Mirko Boehm (KDE e.V.)

[This article was initially published at embedded.com. It is part of the "Companies are Community" series.]

In the world of software development the many debates about the benefits of open source versus commercial software continue, with developers, software manufacturers, users and purchasers all putting forward differing opinions and, sometimes, protecting vested interests.

However, as with most things in life, the argument is not black or white but has many shades of grey. Different models and arrangements mean that open source software may be available without license cost or as part of a larger commercial framework offering with a separate licensing scheme.

But the two approaches are not mutually exclusive – in many cases not only can commercial and open source offerings comfortably co-exist, but they actually strengthen both the product offering and the community to which the system designer can turn for support.

Growth of Open Source

Since its inception and promotion under the banner of the ‘free software movement’ in the 1980s the use of open source software (the more corporate-friendly term by which it became known in the 1990s) has grown rapidly.

Typically covered by licensing arrangements that permit the inspection, modification, improvement and distribution of the source code, open source software (OSS) can now be found in applications ranging from industrial machines to medical equipment and from consumer electronics to defense systems.

Among the various benefits stated for using OSS are cost (it is typically available for free), flexibility of deployment and lack of reliance on a single vendor.

Counter points from the proprietary community also focus on cost (one argument being that the need for organizations to invest in technical expertise and/or long-term technical support mean that deploying an OSS is rarely free).

Without a commercial development and support effort, an organization might end up maintaining the whole OSS product itself, which could be more expensive than a proprietary approach in the long term. Lack of documentation and copyright and trademark protection risks of using open software are also regularly raised.

However, for most of the exponents of OSS, by far the largest advantage is the support of (often passionate) communities whose aim is to work together to continually improve the quality, performance, reliability and flexibility of their chosen product.

These communities not only work as technical consultants for the software, they also provide code contributions, are vocal ambassadors for the brand and educate valuable young talent to create the product and new technology in general.

Our experience is that commercial companies and open source developers can form highly beneficial, symbiotic relationships that enable users to have the best of both worlds, provided that both sides are committed to a long term relationship, and are open about their goals.

Companies can be contributors to open source software projects, just like volunteers, but their contributions are usually of a different kind. The contributions needed by the projects can generally be categorized into time, money and expertise.

It is easier for companies to contribute financially, and to contribute expertise of a different kind than volunteers. The more complementary these contributions are to those of the volunteers, the more the OSS product benefits from this kind of cooperation.

No discussion of this type would be complete without at least a brief mention of the various software licensing options available to developers.

True open source software, for example, is generally governed by a general public license (GPL) in which the source code and modifications must be shared with the ultimate user. The software can be sold but is usually available without a license fee. Support (if needed) is purchased separately and software deployment is royalty-free.

Canonical, for example, operates a business of this type supporting the Ubuntu GNU/Linux distribution. A commercial software license on the other hand typically incurs a fee and there is no obligation to share source code. As a result it allows users to develop proprietary applications and charge for runtime licenses. Commercial licenses also almost always come with some level of support.

There is also a third license category known as LGPL (lesser general public license). This is similar to the GPL license in that the source code for the software and all its derivatives cannot be hidden from the public but with a subtle distinction that the software can be used to create proprietary applications.

Commercial Organizations in the OSS ecosystem

By contributing effort and money to an otherwise collaboratively developed product, companies in a way define their own role in open source communities. They do this by assuming a position as an integral member of the community around the product, and by the tasks they choose to work on.

Depending on how committed a company’s engagement in the community is in the long term, important roles of commercial contributors can be as follows.

First, companies keep a focus on business matters, which effectively means keeping the user in mind. The involvement of companies in open source communities usually leads to a more polished product with a more heavily tested user experience.

Secondly, companies can provide more stability and continuity of the product development process. By assigning to and keeping teams on the product, fluctuation of volunteer contributors is balanced out, and a higher volume of effort can be processed.

The downside of this is that companies usually require more formal organization. That may clash with the self-assignment habits of non-commercial contributors, so companies need to be careful to avoid effects of crowding out.

Thirdly, intrinsically motivated volunteer open source contributors naturally select the tasks they work on based on different interests than companies, and usually do not attend to routine tasks that may offer high utility for users – for example by fixing annoying bugs. Companies are able to assign quality teams to products that stay on this activity, complementing the volunteer contributors in the community.

All in all, the role of companies in open source communities is a beneficial one, provided there is positive cooperation between volunteer and commercial groups.

Commercial and OSS working together

A good illustration of how the availability of software in both commercial and open source versions can benefit the overall community comes in the form of Qt, a framework that brings together a modular C++ class library and developer tools.

Qt is widely used for developing cross-platform applications that require a graphical user interface (GUI) as well as for non-GUI programs such as command line tools and consoles for servers. The Qt framework, which includes intuitive APIs for C++ and CSS/JavaScript-like programming, a Qt Creator IDE and a variety of tools and toolchains, allows developers to write an application once, yet deploy it across multiple hardware and operating system platforms.

In 2012 Digia acquired the full software technologies and Qt business from Nokia. The original Qt platform was produced by Norwegian company Trolltech and then, in 2008, it was acquired by Nokia. The Qt commercial licensing and professional service operations were sold to Digia in 2011, the same year that the Qt Project community came into being. The Qt Project ensures that development of Qt is governed as a true open source project, in which both individual developers and developers from Digia work to advance Qt.

Of course the obvious question is why, when Qt is available for free, would a developer want to consider paying for a commercial license? Clearly the choice will depend to some extent on the target application, but there are a number of reasons for choosing the commercial alternative as in the end it may actually be the one that saves cost for the company using Qt.

The LGPL license, for example, carries some restrictions regarding the ability for users to re-link libraries and other restrictions that may impose architectural requirements that add deployment and upkeep cost for organizations.

The commercial Qt license also protects valuable IP by supporting the development of fully proprietary software, at the same time as offering a high level of standard support within the license fee.

Furthermore, due to restrictions in beginning development with an open source-licensed version and then transitioning to a commercial version it can often pay to purchase a commercial license at the start of a development project.

The developer then has the flexibility to decide licensing (commercial or open source) of the finished product at the time of distribution. To do this they simply create an application that dynamically links to the Qt libraries and then, at distribution, decide whether to link to the commercially licensed or the open sourced-licensed Qt libraries.

Commercial & OSS strengthen each other

Irrespective of the license chosen both individual developers and system designers and the overall community can derive significant benefit from the presence of the commercial offering and vice versa.

Take, for example, the issue of software bugs, a perennial challenge for a constantly evolving software product. Qt has hundreds of employees working on identifying existing or potential bugs and then creating fixes and patches that resolve those problems.

These individuals aren’t necessarily more skilled than their fellow developers in the Qt community, but they are people who are employed for their Qt expertise, who devote almost all of their time to testing and using the platform, and who are paid by the results they achieve. Yet the fixes and patches they develop are available, for free, to the Qt Project to use.

Throughout the Qt community there are hundreds of thousands of users and thousands of active contributors using the latest Qt versions in their configurations to build their applications. These individuals help improve Qt quality by reporting the problems they find. Many contribute fixes that enrich the Qt Project. With open governance, many new features find their way directly to Qt from open source communities and businesses.

Then there is the critical issue of support. Users of open source versions of a product have to pay extra for support during development and/or product lifetime. A company, such as Digia, that derives revenue from and invests in supporting commercial license customers can make available a similar level of service via consultancy to companies that have chosen to pursue the open source path. The aim is to ensure that customers are successful, regardless of the license they choose.

Conclusion

It is clear from the example of Qt that where commercial and open source software options successfully co-exist, the overall community can reap significant benefits, in terms of both platform evolution and access to support that will speed and simplify application development.

And, for an organization offering commercial licenses, being an active member of a community makes sound business sense – not only through the ‘built-in’ audience for its products and services but also through shared experiences and contributions from fellow members that ultimately enhance the products and services it offers its commercial customers.

Tuukka Turunen is director of R&D at Digia Qt, and Mirko Boehm is Economic Advisor and Past President of the KDE e.V free software community.


Google+

3 responses to “Benefits of co-existing open source & commercial software development

  1. I get your point, but don’t reinforce this false dichotomy. Free Software isn’t non-commercial necessarily, as you pointed out
    see http://www.gnu.org/philosophy/words-to-avoid.html

    • Agreed, thanks. In this case, we just did not make it clear that this was about the development process, not the ownership of the code. I updated the title. This issue warrants another article though.

  2. See Valve’s recent use of GitHub to track issues with Steam for Linux and their code contributions to SDL2 used for porting their games.

    nb, I am a community volunteer for the project

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s