Tag Archives: KDE

Introducing Endocode, you are invited!

tl:dr version: New venture Endocode, we are hiring!

Skill and the will to remain in control of one’s own future seem to come in pairs. I consider myself an expert coder with sugar on top, and a darn good manager, too. Working for the man is nothing more than an acceptable means to the end of making ends meet. If you are a knowledge worker and you left average behind a while ago, chances are you feel exactly the same. However, we all need to eat, and that usually means accepting to do paid work. So what is there to do? Well, for one thing, put that gray matter to use and design a company to your liking, that’s it. Challenge accepted, and we are almost done with it. Meet Endocode. Continue reading

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+

I ♥ Free Software (and why)

Today is February 14. Some think of it as flower grocer appreciation day, but most (and for better reasons) celebrate it as the international I ♥ Free Software day. I spend a lot of my time on various Free Software activities, like KDE, FSFE, OIN and netzpolitik.org. I even research it and teach about it. These contributions have become something I regularily do. Every minute I spend as a contributor is thoroughly rewarding. Here is why.

I ♥ Free Software

I ♥ Free Software

I was thinking to begin with how I selflessly work for the common good and all, but the first and foremost reason why I love Free Software is because I am a tinkerer. Not only do I love to code, but I have an urge to understand how things really work. Free Software allows me to to do just that. At the age of 12, I was into electronics. I built power amplifiers. At 14, disco light shows to impress the ladies (it failed to induce the desired effect). Then, Z80 based chess computers. This triggered my interest in software, since the actual chess program used was a binary CMOS image and I had no idea how it worked, and was practically unable to figure it out. Then came a C64, on which I learned programming in 8 bit assembly (the assembler came on a cartridge and did not even support labels for jumps). Later at university I asked the teachers if it would be possible to, instead of handing in throw-away programming assignments, do course work on a Free Software project. Luckily they accepted (quite far-sighted, in 1997), and that is what got me into KDE. I have been there ever since.

So Free Software gives me the opportunity, the freedom to tinker and explore, to really understand how the computers I use work. What makes that infinite times better is that I can share my findings, be it code, or a theory. At the latest since the industrial revolution, we grew accustomed to the idea that to create complex and costly products, companies or governments are needed. These come with a certain level of rigidity and subordination of individual interest. While this is acceptable since it pays the bills and is sometimes necessary to get things done, it requires following some other parties priorities and goals. It distracts from pursuing those challenges that we really care most about. Those would likely be the ones each of us excels most at. We do not invent, create and improve to our full potential when working for others. We do, in Free Software communities (and other collaborative communities of similar kind) – they enable us to flock together on similar interests, and create something – like a Free Software desktop – we are truly and genuinely passionate about. Because of that I enjoy working on KDE, a community that treats all contributors as equals, and is open for everybody to join.

The benefits of Free Software go beyond the individual contributors and the communities they form. The four freedoms laid out as the foundations of Free Software are a fanfare to the ability to exercise one’s free will, to freely collaborate by helping your neighbors, to achieve independence from directions other people have thought up for us. The effects can be seen all around us – when teaching material for schools is developed collaboratively and freely shared, when government data is opened up to improve the transparency of the political process, when the technical foundations of the internet and the operating systems running modern technology become a common good, and in many other places. People start to expect similar freedoms they learned to get used to in software when engaging in society. And more participation is always better.

This is why I love Free Software. It makes the world a better place. If you love Free Software too, follow this simple advice to show your appreciation to those who contribute to it.

Is Open Source democratic?

Aristotle

For Aristotle the underlying principle of democracy is freedom, since only in a democracy the citizens can have a share in freedom.

In his recent post, Glyn Moody asks an important question – “Can Open Source be democratic?” He describes how Free Software emerged as a distributed, bottom-up system of writing code. The central defining aspects of that culture are a uniquely open process not just of programming but also of its organization, and a close relationship between programmers and users. Effectively, users and programmers together were both contributors, they collaborated on the project. Glyn goes on to explain how this community effort changed over time to become more institutionalized, more corporate and more dull – “becoming a ‘Firefox Affiliate’, hardly something that sets the pulse racing.” Ordinary users no longer play an important part in Open Source projects.
Underlying is the assumption that Open Source is democratic, and this assumption needs to be questioned. Open Source communities have been coined to be self-directed, meritocratic,  …, but it is rarely emphasized that they are democratic. Since individuals are investing effort in their favorite projects to contribute to something greater, and democracy is commonly considered to be a greater good as well, it is intriguing to make the jump to thinking of Open Source communities as being democratic. But are they? What is the meaning of democracy in the context of Open Source? What does a democratic community look like?
Some may say that such political concepts cannot easily be transferred to how Open Source communities should function. While it may not be easy, it is still worthwhile – democracies have dealt with similar problems of inclusion and the distribution of power and responsibility. Just like democratic states, communities are volunteer organizations that congregate to build the public goods they desire in the commons. Just like citizens, members of communities have a choice of voice or exit that they make based on the expected influence  they have as citizens. There are enough similarities to justify learning by example.

On being a contributor

Democracy means “rule of the people”, and postulates, amongst other things, for each individual to be equal before the law and to have a vote in the political process and election of the government. This immediately boils down to the central Yin-Yang question of who is a citizen and who is not. Are users considered integral parts (citizens) of the Open Source communities, or outsiders who provide feedback? And should they be the equals of developers?  While today we seem to think that equality comes standard, it is in fact a dynamic concept, its meaning changes with culture. Think about the Voting Rights Act of 1965 that finally abolished voter’s discrimination by race in the US, or the fact that women will gain the right to vote in Saudi Arabia in the year 2015. This is what Glyn observes – users changed from being integral elements of the community to playing an only marginal role, akin to not having a vote.
Eligibility and acceptance are what discerns citizens from barbarians and slaves. Eligibility answers the question of which individuals can potentially become citizens. Acceptance is the requirements an eligible individual has to fulfill to gain citizenship. For example, a foreigner living in a country may be eligible for citizenship, but to be accepted needs to pay taxes for a number of years. When the same questions are applied to Open Source communities,  they translate to “Who is a contributor and could thus become a citizen of our community? How does somebody  join the project?” and second, “What does a newcomer have to do to be considered a contributor, a part of the community?” (does that sound like “How do I become a committer”? – exactly). In Open Source communities usually all individuals are eligible to join, but to be accepted and integrated, they need to contribute to the code.
So for users to become integral parts of Open Source communities again, users that engage with an Open Source project need to be equal contributors amongst peers, to be eligible. This is far from standard, and not the mind-set of most contributors I know. Most communities I work with value direct contributions to the project source code higher than feedback from users. They (unconsciously?) consider users outsiders and refer them to talk to the issue tracker, a proven way to make sure they never come back again with more feedback. So firstly, users need to be considered eligible to become community members, and second their efforts (feedback, for example) need to qualify them for acceptance as ordinary contributors.

On Open Governance

But not all communities are created equal. When evaluating how democratic a community is, we need to look at their reason to exist. Not all Open Source projects are created by developers and users together, and the distribution of power and responsibility usually follows this outset goal or doctrine. If a project that is founded by developers and users  grows organically into an openly governed community (like KDE), it is likened to a democracy. A project that is founded by a company (think Mozilla or Qt) and maybe allows external contributors in along as they accept the decrees^wCLA of the king^wowner company aches more towards an aristocracy. Not all contributors are equals, and the ruling government cannot be replaced.
There has been a long debate over what the most central trait of a democracy is. Opinions differ, but there is one question – can the citizens, on a regular basis, re-elect or replace the ruling government in a structured process, without the need for a revolution? With this argument in mind, it becomes apparent that not all Open Source communities are democratic. KDE is to an extend, with a weak government and regular elections where every active member has exactly one vote. Think about electing a new government for Android, and the difference becomes apparent. Of the Open Source projects Glyn mentioned in his post, few can be considered democratic by this standard.
Back to the question on how to reduce the distance between users and developers and how to build communities that thrive on collaboration. Users, like any contributor, will consider the effect their investment of time into the project will have. If the utility they gain from contributing outweighs the cost of the effort to contribute, they will join the community and help with the project. The utility is directly related to the openness of the community governance; it will be less if the contributor’s influence is only on mundane details, and greater if she has the chance to become the next president of KDE e.V. This emphasizes the importance of Open Governance for the longevity and community spirit of Open Source projects. Only with both the Open Source way and Open Governance, the user experiences the freedom to create that convinces her to join the project. Democracy in communities is Open Source combined with Open Governance.

Conclusions

From the status of being a contributor – a citizen – follows the right and duty to take part in the community’s affairs. Open Source can be democratic if it treats all the community members equally. Three requirements for considering an Open Source community democratic have been developed in the discussion above:

  • To be democratic requires not to discriminate amongst contributors (users and developers). Users are contributors. They need to be encouraged to join the community, to give feedback and to otherwise help improve the project.
  • Democracy in communities means Open Source combined with Open Governance. The availability of the source code under a Free Software license is not sufficient for an Open Source community to be democratic. Without equality, without the contributors controlling the project as equals, it may be Open Source, but it is not democratic.
  • Governance is open if the contributors are equals and the community elects its own representation. Defining Open Governance as the situation where the contributors are in control of their project on all levels, democracy in an Open Source project can only be achieved when all contributors have equal say on all matters of the project.

Whether or not contributors fully are equals amongst peers can only be decided by actions, not by words. The ethical question whether or not democracy is desirable for an Open Source project has been avoided in this article. In my personal opinion, Glyn is absolutely right: For Open Source to continue being successful, direct and indirect contributors need to get back to working together. With the widening appeal of Open Source software, naturally developers will become more experienced and professional, and the average user will turn to be less technical and computer savvy. This trend will likely continue with the growing user base of Open Source. And because it is inevitable, Open Source projects should instead prepare to liaise more with users and generally get good at integrating users and coders in the community.

@mirkoboehm • Mirko on LinkedIn • @AgileWorkers

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.