FLOSS Business and Innovation Models Recommendations Based on Effects of Volunteer Contributions. Magnus Sulland

Transcription

1 FLOSS Business and Innovation Models Recommendations Based on Effects of Volunteer Contributions Magnus Sulland Specialization Project Supervisor: Reidar Conradi, IDI Submission date: December 2009 TDT4520 Program and Information Systems Semester: Autumn 2009

2 This page is intentionally left blank.

3 Problem Description Community driven information creation and software development have been made possible by the introduction of easy connectivity using Internet, information sharing tools like Wikipedia and philosophies like Open Source and Free Software. New rules and regulations has been made to govern products developed using this type of approaches, and resulted in licenses like Creative Commons (CC), GNU General Public License (GPL) and Berkeley Software Distribution (BSD). This project will look at prerequisites and consequences of contributions originating from volunteer driven development, giving recommendations concerning business and innovation models by focusing on how volunteers contributions affect different parameters of software development through free/libre/open source software (FLOSS). Focus will be put upon the following parameters: Quality Globalization Intellectual property rights Cost/benefit Assignment given: Autumn 2009 Supervisor: Reidar Conradi, IDI

4 This page is intentionally left blank.

5 Preface This project was written during autumn of 2009 at the Norwegian University of Science and Technology, resulting from the specialization project. I would like to take the opportunity to thank my supervisor at NTNU, Reidar Conradi for valuable insight and guidance during the writing of this project. I would also like to thank David Sommerseth for valuable insight on Open Source, seen from a contributor s standpoint. I also want to thank him for contributing inside knowledge about the eurephia project. December 16, Trondheim Magnus Sulland i

6 This page is intentionally left blank. ii

7 Contents 1. Introduction Background and Motivation Problem Definition Scope Report Structure Background Information Community Roles Commercializing of the FLOSS Community Licensing Models Business and Innovation Models State of the Art Dual Licensing Model R&D Sharing Model Research Research Questions Research Contributions Research Approach Limitations Results Usage of Policies and Guidelines Commit Rights to the Repository Intellectual Property Rights iii

8 6. Discussion Code Responsibility Code Quality Conclusion and Further Work Further Work Definitions Bibliography 9-25 List of Appendixes Appendix A: Policies and Guidelines...29 Appendix B: Illustrated Contribution Models...30 iv

9 List of Figures Figure 1: "The Virtuous Cycle", figure from Qt Development Frameworks Figure 3: Integration Manager Workflow, figure from whygitisbetterthanx.com Figure 2: Qt contribution model, figure from Qt Development Frameworks List of Tables Table 1: Top 5 licenses (OSI approved) in use at SourceForge.net ( ) Table 2: GNU General Public License chart Table 3: BSD License / New BSD License chart Table 4: Apache License v2.0 chart Table 5: MIT License (X11 license) chart Table 6: Projects used v

10 Abbreviations FLOSS Free/Libre Open Source Software, combining both Free Software and Open Source. CC Creative Commons, copyright license create by Creative Commons. GPL GNU General Public License, copyright license create by Free Software Foundation. BSD BSD, copyright license create by the University of California. OSI Open Source Initiative 1. FSF Free Software Foundation 2. IDI Department of Computer and Information Science at NTNU. NTNU The Norwegian University of Science and Technology. OSS Open Source Software. 1 Open Source Initiative, 2 Free Software Foundation, vi

11 1. Introduction 1.1 Background and Motivation In a world steadily evolving and taking more notice to community work there is some new challenges and possibilities opening up. Selecting the most efficient and correct FLOSS innovation and business models may have great potential. A popular example of benefits from the open community is the Linux kernel, calculated to cost approximately 1.4 billion USD, estimated person-years, (McPherson, Proffitt, & Hale-Evans, 2008) to develop and used by a variety of companies building their own solutions on top. This just one of the popular products involving the work of volunteers, and now days a stream of commercial companies are opening up their code, reaching out to the knowledgebase of the communities (Gartner, Inc., 2008). Companies are also incorporating development methods and best practices from the community, one example being a growing use of software forges used to get research projects advertised in-house and later developed into products while relaying on people volunteering (Riehle, et al., 2009). These are all trends displaying the importance of FLOSS communities and the volunteers they consists of. Utilizing and eventually making profit from development done in communities, sometimes in conjunction with your competitors, have created the need for business and innovation models that take into account the loss of fee based distribution. It can be redistributed and modified by anyone. Innovative methods of using your product, instantly shared across borders, developed by volunteers scratching a personal itch can add values a company may not understand or be ready to embrace and develop further. 1.2 Problem Definition Increasing use of FLOSS and expected continuous growth of adaption (Gartner, Inc., 2008) puts demands on the innovation and business models and the decisions they where built upon. Development undertaken by a global collaboration of competing companies, in conjunction with volunteers, all sharing their discoveries for other to reuse, study, modify and redistribute (Free Software Foundation, Inc., 2009) does affect the current closed source models, shifting focus into new challenges. This report is aimed at creating recommendations for business and innovation models that mainly focuses on quality, globalization, intellectual property rights and cost-benefit. The following research questions where used: 1. What consequences on quality may result from including contributions by volunteers and is it controllable by predefined conditions? 2. How do global contributions from volunteers affect compliance with intellectual property rights, what preconditions must be present to keep in compliance? 1-1

12 1.3 Scope The scope of this report is recommendations concerning business and innovations models seen from a software development perspective. Narrowed down to focus on consequences and requirements volunteer work put on the following parameters: Software quality Globalization Cost/benefit Intellectual property rights Definition of a Volunteer This report defines a volunteer contributor in FLOSS projects to be a person contributing on free will, without immediate commercial interests, or receiving immediate economical compensation for the work executed. 1.4 Report Structure Outlining the remaining of this report is the following chapters, listed from first to last. Chapter 2: Background Information Separated into four parts this chapter describes the roles used in the community along with describing the community itself. A brief introduction to business and innovation models, and a part describing, in short, the currently most popular licensing models, combined with a description of the two main views, Free Software and Open Source. Chapter 3: State of the Art Describing two major business and innovations models that are currently in use, through the FLOSS projects: Qt and WebKit. The two models explained herein are Dual licensing model and the Research and development sharing model. Chapter 4: Research Describing the research questions used in this report, and the contributions resulting from those questions, including limitations and the research method used. Chapter 5: Results An overview of the results gathered from looking at how four different projects handle contributions committed by volunteers, governing code quality and intellectual property rights compliance. Chapter 6: Discussion This chapter describes and discusses the findings from chapter five, looking at conditions that are important and how they are affected and can be controlled. Chapter 7: Conclusion Summarizing and presenting the conclusion of this report, along with a summary of contributions, ending with a chapter containing thoughts for further work on this topic. 1-2

13 2. Background Information This chapter gives a short overview over the different roles a volunteer may take in a community and the contributions that follows. An introduction to commercializing of the community and how companies form their own projects follows. The different licensing models currently most in use are presented, along with a description of the two sides Free Software and Open Source. Introducing business and innovation models at the end and how they interlink. 2.1 Community Roles Based on volunteer commitments, FLOSS communities are dynamically organized allowing people to join and leave at any time. The different roles contributors step into can be assigned based on their contributions, active developers with great knowledge to the project promoted into core members as an example. Interest and skill are also role defining, along with sudden changes to a project. Sudden changes to the inner roles in a project can have devastating effects, leaving a gap needing to be filled in order for the project to succeed. The hierarchy contains the following roles (Ye & Kishida, 2003): Project Leader: The person being responsible for overseeing the direction of a project. In many cases used as the spokesman and public face for a project, a role often resulting from having been the original initiator. Influence and decisions rights ranging from small, to always having the final word. Core Member: Group of decision makers forming an inner circle, may incorporate the role of project leader forming a council. Consisting of people that have made a considerable contribution to the community and showed great knowledge. Active Developer: Regularly contributing developers. Making contributions governed by guidelines and rules created by the community. Getting commit rights to the repository of a project often requires getting a recommendation from someone already actively involved. Peripheral Developer: Developers not active over a longer time. Occasionally contribution or very few contributions, volunteers wanting to contribute in this form are required in some projects to submit patches to an active developer for review. Bug Fixer: Uncovering and submitting patches to fix bugs found in parts of the code. In projects using public bug tracking, Bug Fixers also patch bugs reported by a Bug Reporter. Bug Reporter: Person finding and reporting bugs in a system, not extending to patching. Differentiating from closed source reports may include direct references to code. Representing a important feature of FLOSS describes by Eric S. Raymond, calling it Linus Law: given enough eyeballs, all bugs are shallow (Raymond, 2001) Reader: Actively using the project source code to learn from it. Passive User: Using the system in a way not differentiating it from closed source. Extending the user base and reputation of a project thereby contribution without actively taking action. 2-3

14 2.2 Commercializing of the FLOSS Community Evolving from the early days in academic institutions into a cornerstone in a growing amount of commercial software the community itself is changing. While there are a wide amount of smaller projects controlled and developed using volunteers, the question Is Commercialization Killing Open Source? (Hinkle, 2007) has been asked. Looking at the growth of company usage (Gartner, Inc., 2008) a direction away from volunteer driven community work over to a company controlled community can be used as a business model in it self, as displayed by Google in their Android project (Gohring & Perez, 2009). Many of the widely known FLOSS projects, having reached considerable size, already use this commercialized community approach, a recently emerging project being developed named WebKit 3 being an example of this. Originating from the volunteer driven project KHTML, later forked by Apple in 2002 turning into a project where multiple companies share development cost. Sharing the cost and effort of developing WebKit, each of the companies includes this code into their own in-house created products, being a very popular foundation for mobile phone browsers amongst others. 2.3 Licensing Models Is it Free or Open In the open source community there are mainly two philosophies on freedom and sharing present today. There is Free Software Foundation (FSF), from 1985, founded by Richard Stallman and the Open Source Initiative (OSI), from 1998, founded by Bruce Perens and Eric S. Raymond. FSF representing the Free (Free Software Foundation, Inc., 2009) as described using the Four essential freedoms, demanding that anyone have the freedom to run, study, redistribute and modify the code (copyleft). Focusing on sharing of the code it self (Open Source Initiative, 2009), OSI represents Open, described in The Open Source Definition. Often viewed to be more business friendly in their approach to sharing, credited with helping trigger Netscape s code release, and thereby the creation of Mozilla in 1998 (Mozilla Foundation). Initiated in 2001, the usage of a combination of them named FLOSS, free/libre/open source software (Berlecon Research GmbH, University of Maastricht,, 2002), where created. A combination made possible by the similarity between FSF and OSI. FLOSS is the term that will be used in the rest of this report describing the open/free community sharing. Copyleft Using copyright as basis, copyleft creates fewer rights for the author while extending the rights of the user. Adding the demand that all derived works and modifications should be shared under the same freedoms that originally where attached. Hindering users of the code to distribute modifications without contribution back to the original developers and their community. Copy central Originating from university traditions, creating licenses such as the BSD-license and MIT license, copy central is non-restrictive giving full freedom to the code. Enabling 3 WebKit, 2-4

15 it to be included into a variety of other licenses, not requiring modifications to be distributed back thereby enabling inclusion into closed source products. Copyright Giving the author of code complete ownership of that particular representation, not extending to ownership of the idea it self. Copyright itself can be extended, an action often required by commercial communities in order to enable dual licensing, and the ability to change/update license FLOSS Licenses To govern the future rights to the source code a wide diversity of generic and special purpose licenses have been constructed. Approved by FSF and OSI the most well known generic license being GPL. Besides the generally approved licenses, a special purpose license is not uncommon, like the Apache licenses created initially for the Apache project. While not recommended by FSF, creating a special license adds flexibility to the project while resulting in more complexity in the community, specially surrounding code created and used across projects. Multiple active licenses are a common way to overcome some of these problems, making code available under different licenses at the same time is also a key in some business models enabling closed source products. Deriving/combining work from different licensing models is controlled by the compatibility specified within a license. This may restrict the code and information volunteers can contribute to projects, and is thereby an important aspect in decisions surrounding projects licensing model. Because of the popularity gained by the GPL license it is common to find information about GPL compatibility 4. A vast diversity of predefined licenses can be found, seventy-seven OSI approved licenses in use at SourceForge.net alone. Not all of them widely used, the GPL-family currently standing out as the most popular. License name Number of projects GNU General Public License (GPL) GNU Library or Lesser General Public License (LGPL) BSD License / 2-clause BSD license Apache License V MIT License 4479 Table 1: Top 5 licenses (OSI approved) in use at SourceForge.net ( ) GNU General Public License (GPL/LGPL/GPLv3) 5 Consist of a set of ground rules tailor made to different situations by creating a foundation for the following, all based on copyleft: GNU Lesser General Public License (LGPL) GNU General Public License version 2 (GPLv2) GNU General Public License version 3 (GPLv3) GNU Affero General Public License (AGPL) 4 Various Licenses and Comments about Them, 5 GNU Project, licenses, 2-5

16 GNU Free Documentation License (FDL) Written by FSF the licenses gives future and current users of the code great freedom while demanding that all derived work and future versions should preserve this freedom. Widely acknowledged as the most popular license (Wheeler, 2009), and it is often possible to convert code into this license, but not out of it. Regarded at impossible to incorporate into closed source software since all derived work must be published using a GPL license, LGPL opening up possibilities to link against closed source software without distributing needing to relicense. Property Decision Grants patent license Yes Closed source includable No / Yes (Dynamically linking with LGPL) Derived works must be redistributed Yes GPL-compatibility Yes Table 2: GNU General Public License chart BSD License/New BSD License 6 First used in the Berkeley Software Distribution (BSD), the BSD license is a liberal license stating few restrictions, called copy central. It requires credit to be given where credit is due by including the original copyright notice, and that the developer is not legally liable for any parts of the code. The original version made obsolete by the new BSD license, lacking the unpopular advertisement requirement. Besides those restrictions you may freely include the work in closed source projects, without redistribution of changes. Regarded as easy to incorporate into closed source development based on the absence of demands to redistribute any derived code or modifications done. Property Decision Grants patent license No Closed source includable Yes Derived works must be redistributed No GPL-compatibility No / Yes (New BSD License) Table 3: BSD License / New BSD License chart Apache License Version Originally a project specific license, version 2.0 now offers both GPL compatibility and reusability in non-apache projects. Used mostly in the different projects administrated by the Apache Foundation or directly related projects. Property Grants patent license Closed source includable Derived works must be redistributed Decision Yes No Yes 6 BSD license definition, 7 Apache Software Foundation, 2-6

17 GPL-compatibility No / Yes (v2.0) Table 4: Apache License v2.0 chart MIT License (X11 license) 8 Created by Massachusetts Institute of Technology (MIT) and first used in the X Window System this license closely relate to BSD, sharing the same short and simple type of definition, being copy central. Property Decision Grants patent license No Closed source includable Yes Derived works must be redistributed No GPL-compatibility Yes Table 5: MIT License (X11 license) chart 2.4 Business and Innovation Models Business Models A business model is used to describe how a company will create revenue by distancing their product from the competition and give the customer higher value. Developing a wellformulated business model gives a company a competitive edge by having a overview of what the correct pricing politics for their product are, knowing the costumer value that it creates, the revenue source and the cost structure that surrounds it. Business models are tools enabling different companies to be compared by investors and venture capital, describing the market segments it is present in, the available human resources and the sustainability of a company. All combined to predict the return of investment. In the most basic sense, a business model is the method of doing business by which a company can sustain itself that is, generate revenue. (Rappa, 2009) A business model consists of answers to the following components (Tucci & Afuah, 2003): Profit site What is the competitive pressure exerted by competitors, customers and other products? Customer value How does a company differentiate itself from the competitors giving extra value to their product? What is the potential of contributions from volunteers to make something distinctive, can it help solve new customer problems? Scope Type of customers targeted, other businesses or end users, in combination with the geographical locations the company offers its value to. 8 The MIT License, 2-7

18 Pricing The companies pricing strategy for the product, in what way does volunteers have an effect on this strategy? Revenue source Where does the revenue and profit originate from, what part of the ecosystem surrounding the product yields profit? Connected activities What activities must the company engage in to support the proposed customer value? Implementation How does the company build its organizational structure, organizing its internal systems and motivate employees in order to implement the decisions? Capabilities To underpin the customer value offered what kind of capabilities are needed, tangible, intangible and human (Grant, 2008). Does the company already have resources in place that can create extra customer value? Sustainability What strategies to be used in order to keep its competitive advantages? Cost structure What is the relationship between production cost and revenue generated from the product? FLOSS is not a business model in it self, since they do not specifying any means of generating revenue, and are rather a foundation for a wide range of models using a common development model. The revenue is most often generated from fee based services surrounding the product it self, the main models defined as (Daffara, 2009): Open Core, Product specialists, Platform providers, Selection/consulting companies, Aggregate support providers, Legal certification and consulting, Training and documentation, R&D cost sharing and last Indirect revenues. Defined in the same report, dual licensing is the only main business model enabling the combination of FLOSS and maintaining the code direct sales value (Välimäki, 2003) Innovation Models Closely related to the business model used, innovation models are focused on developing ideas into commercially viable products, products that may change the business model itself. The ideas are not necessarily groundbreaking new technology or major breakthroughs; innovation may just as well be incremental steps (Tidd, 2006). In the book Democratizing Innovation (Hippel, Democratizing Innovation, 2005), innovations is described to undergo democratization, moving from the manufacturercenteric to the user-centric model. The user-centric model focusing on user-driven development and user-created modifications, where the users themselves are trend leaders, creating solutions that focuses on their specific needs and interest. Minimizing the development each user must undertake, knowledge and solutions are often shared. Manufacturer-centric places the user just consuming while the manufacturer innovate. 2-8

19 Thereby creating the products that give highest revenue, innovating based on the larges consumer group. The Private-Collective Innovation Model (Hippel & Krogh, Open Source Software and the Private-Collective Innovation Model: Issues for Organization Science, 2002) describes the combination of private and collective model for inducing innovation. Private innovation model is based on rewarding the author ownership and protection from competitors by intellectual property law and secrecy, in essence not sharing knowledge with the community. In contrast to the collective innovation where the innovation is given to the public and rewards thereby are something different, a gift society suggested by Eric S. Raymond giving peer recognition in return. 2-9

20 3. State of the Art This chapter gives a short overview of some currently used business and innovations models that are built upon taking advantage of volunteer work. First part describing the steps leading to Qt Development Frameworks 9 opening up their repository and its effect on their strategies. Followed by a description of WebKit and how companies share code and development, while maintaining their difference outwards. 3.1 Dual Licensing Model Definition The Dual licensing model is based on adding a proprietary license to a project at the same time as it uses one or more FLOSS licenses. Enabling the owners of the project to do fee based distribution, often to closed source development companies, while being active in the FLOSS community gathering contributions and creating reputation Qt Development Frameworks Released May 20, 1995 (Blanchette & Summerfield, 2006) from a Norwegian startup company called Quasar Technologies, now owned by Nokia and renamed to Qt Development Frameworks, the Qt 0.9 framework where licensed using a business strategy of multiple licenses. Using a business model where the customer value was a free crossplatform GUI toolkit that was easier to use than the competitors. Utilizing the dual licensing model (Välimäki, 2003) their revenue source where the proprietary version, that allowed companies to create closed source software, while also having a competitive pricing. Their product where shortly after, in 1998, the basis of a Free Software Linux desktop environment, created by Matthias Ettrich, name KDE. KDE being community driven an developed by volunteers under a GPL license, while Qt licensed under its own more closed licenses (Troll Tech AS) was not without complications and sparked a lot of criticism in the FLOSS community. With the release of Qt 2, the license where changed to the FLOSS approved Qt Public License (QPL) making it less conflictive with the FLOSS community. In order to secure their position with the FLOSS community their created the KDE Free Qt Foundation in 1998 to ensure a Qt release under BSD type license if Trolltech stopped development (Troll Tech; The KDE Project, 1998). Word-of-mouth recommendations, in conjunction with the notoriety received from successful free software projects, are important to Trolltech. (Chance, 2005) describes the importance of volunteers, supported by Qt Development Frameworks, extending to also include financial support to FLOSS projects. This support to the community where shown in 2001 releasing Qt 3 using GPL, instead of their own QPL, creating a wide excitement in the FLOSS community (Reichard, 2000). Developers of GPL software could now also use the framework in their own projects, leading to possible sales of the proprietary license to the companies where they where employed. 9 Qt Development Frameworks,

21 In Qt 4, the GPLv3 license where now covering all platforms supported by Qt, adding LGPLv2.1 support in version 4.5. The additional LGPL licenses extended their business model (Nokia) by including partially closed source applications, due to the ability in LGPL to be dynamically linked with non-gpl code. Another part of the business model has included fee-based support for the proprietary version, adding revenue source and customer value they now extended this option to the LGPL version. This more permissive licensing will further lower the barrier for adoption of Qt and KDE technologies. The KDE team welcomes opening up the development process and is looking forward to further improved collaboration between KDE and Qt Software. -- Sebastian Kügler, KDE e.v. Board Member. (Nokia, 2009) Changing the license towards and eventually into GPL did not affect Qt Development Frameworks distribution of Qt itself, due to the stringent restrictions surrounding their repository and cumbersome commit process. A milestone were marked releasing the repository (Nokia, 2009), including opening up their development model and their roadmap. The connection to the community and commercial users displayed using "The Virtuous Cycle" 10 Figure 1: "The Virtuous Cycle", figure from Qt Development Frameworks 10 According to Knut Yrvin Community Manager for Open Source these are some of the results they hope to accomplish from the repository release: Volunteers helping to port Qt to previously unsupported platforms. Help finding and committing bug fixes. Opening up for functionality created outside of Qt Development Frameworks. Keeping control over the quality of the code submitted, and keeping it consistent, contributions must comply with the QtContributionGuidelines 11. A set of principles, code 10 Figure from presentation by Knut Yrvin, Nokia QT Seminar, 11 QtContributionGuidelines,

22 style and conventions that must be respected in order to be accepted into code review, done by Qt Development Frameworks, and later into the official repository. Before final acceptance a search is done looking for code violating intellectual property rights. Since GPL-licensed code is not possible to merge into other licenses, the contributor needs to extend the copyright to include Nokia. 3.2 R&D Sharing Model Definition The Research and development sharing model is based on companies, including volunteers, sharing the cost to develop and sustain a product. This increases development speed at the same time that it puts lower demands on the amount people each company must assign to it : WebKit Forked from the projects KHTML 12 and KJS 13, both a part of the FLOSS project KDE, Apple created the WebKit project in The decision where based on a thorough review of multiple FLOSS projects (Melton, 2003), marking their entrance into web browsers with Safari. Entering a rapid evolving, very competitive environment eight years after Microsoft s first release (IE 1 release in 1995). The product fee being none, it added extra customer value to their operating system, and where used to create advantage focusing on the speed it delivered to the customer experience. Apples decision was initially appreciated by the community, hoping to get more contributions, later resulting in tension based on Apples reluctance to share and the methods under which contributions where made (CNET News, 2005). The cost-benefit extracted where amongst other the ability to delivering a web browser after little over a year of development, and using code without a fee attached to it. Retooling their relationship with the community (Ars Technica, 2007), access to the WebKit repository and bug tracker where release in 2005 and WebKit itself dual licensed using Apache v2 and LGPL. From there on, WebKit has evolved into its own community driven project, development and research spread amongst volunteers and companies and interchanging code with KDE. Companies active in the community create customer value in the non-common tasks that differentiate them, exemplified by WebKit recently finding its way into Qt, the GUI framework KDE is based on, as a browser widget. We value real-world web compatibility, standards compliance, stability, performance, security, portability, usability, and relative ease of understanding and modifying the code (hackability). -- WebKit Project Goals (WebKit) Keeping control over the quality of the code submitted, and keeping it consistent, contributions must comply with a predefined Commit and Review Policy. Guidelines put in place to ensure a consistent codebase, lowering the threshold for others to bug fixes and contribute new code. Before final acceptance there is also a review process done by community elected developers, having committed considerable project contributions. 12 KHTML, 13 KJS,

23 4. Research This chapter consists of the research questions put forward by this report, the methods used to acquire information needed to answer those questions and the research contributions that resulted from the report. Limitations used, and the decisions they are based on are explained in the part Limitations at the end. 4.1 Research Questions The problem description, referring to the previously stated problem description: This report will look at prerequisites and consequences of contributions originating from volunteer driven development, giving recommendations on business and innovation models by focusing on how volunteers contributions affect different parameters of software development through FLOSS. Based on the four parameters in focus: quality, globalization, intellectual property rights and cost-benefit. Quality and intellectual property rights where selected to be the main focus, while globalization and cost-benefit where downgraded. A decision based on the timeframe of this report. From the problem description and two main parameters to be used the following research questions where extracted: 1. What consequences on quality may result from including contributions by volunteers and is it controllable by predefined conditions? Wider usage of FLOSS, integrated into ever more demanding situations where product quality is essential, demands wide focus on quality throughout the community. Spanning from small-scale companies like Paynet, former Norwegian payment service provider, to large-scale usage at NYSE 14 their reputation and business is built upon the quality of their services. Preemptive work is important to reach high quality consisting of amongst other: maintainability, testability and reusability. Thereby the business and innovation models used in companies developing through the use of FLOSS must reflect the communities efforts to maintain control and quality. 2. How do global contributions from volunteers affect compliance with intellectual property rights, what preconditions must be present to keep in compliance? The increasing use and dependency on FLOSS components (Gartner, Inc., 2008) in combination with projects growing into the markets previously controlled by others have the potential to result in a more stringent view on compliance with intellectual property rights. By example the Microsoft s against Linux case, Microsoft claiming that the Linux kernel infringes on their patens (Parloff, 2007), requiring substantial royalties from the users if the case is won. Also illustrated in the much-disputed SCO against IBM case. While the cases themselves may not be lost, or the economical impact being low, the uncertainty 14 NYSE Euronext Chooses Red Hat Solutions for Flexibility and Reliable, Fast-Paced Performance,

24 surrounding them may harm the reputation, and thereby discourage potential customers from using FLOSS components, and FLOSS suppliers. In small projects without a company or a foundation taking responsibility for violations, a violation could have devastating effects on the companies building their software upon the components, even extending to their customers. "It's a tinderbox. Patent law's going to be the terrain on which a big piece of the war's going to be fought. Waterloo is here some where." --Eben Moglen, Executive director, Software Freedom Law Center (Parloff, 2007) 4.2 Research Contributions Based on the two research questions and the problem description in this report, the following to research contributions where created: 1. A set of recommendations concerning business models surrounding software development including contributions from volunteers. 2. A set of recommendations concerning innovation models surrounding software development including contributions from volunteers. Defining a solid base to build and run a company is important, the contributions from this report being business and innovations models that may help building revenue taking advantage of the voluntary work done in the communities in a safe manner. 4.3 Research Approach Controllable predefined conditions to be used in a proactive way, both to govern quality and intellectual property rights compliance, spans a wide range of options. In order to collect some of the solutions used today, a brief look inside four different FLOSS projects have been made. Focusing on code-related commit strategies, policies and guidelines put in place by the community. The following types of project ownership where included: company, nonprofit organization, small community and personal. The reliance each project have on volunteers where considered in the selection, opting for three volunteer driven projects and one company controlled. This report relies heavily on information found in the literature researched, information that is interwoven with the discussion taking part in chapter Limitations The small amount of projects included in the overview of practices used to control contributions originating from volunteers, prevents this from resulting in statistical valid arguments. The idea of the overview is not to give statistical data, rather to give a list of possible actions that are used. A limit where also set based on the resources and time that was available, and strongly influenced by a lack of prior knowledge on the subject. Other limitations in this report are the limited business and innovation education that the author holds, and the scope of those two professions, amongst other the importance of real life experience practicing them. These limitations have resulted in a focus on recommendations concerning existing models, not the creation of new innovative practices. 4-14

25 Unfortunately the author have not been an active contributor to FLOSS projects, thereby a lack of direct experience is seen as a limitation to the depth of knowledge. 4-15

26 5. Results This chapter describes the different findings that where done on how projects define and control voluntary contributions in order to maintain code quality and ensure compliance with intellectual property rights. The first part explains the findings of policies and guidelines that where used, followed by the findings about how repository rights are granted and intellectual property rights handled. 5.1 Usage of Policies and Guidelines Communities are by nature open to contributions from its members, the level of contributions however differ in size, quality, difficulty and importance. Managing these contributions in a way that ensures consistency in the project, thereby making it possible to easily merge and develop on code committed by different developers, needs the help of guidelines and policies to guide focus to elements of importance. This approach does not differ from closed source in-house development, where the employees must comply with predefined rules. Getting an overview of some of these guidelines and policy options used in FLOSS projects, four different projects where selected spanning from large frameworks to a project extending functionality. These are the projects that where looked at: Name Ownership Description License used Qt Company Cross-platform GUI and application framework. GPL, LGPL, Proprietary KDE Non-profit organization Cross-platform desktop environment, based on Qt, mostly consisting of volunteers (KDE Quality Team ). Adium 15 Small community Instant messaging client running on Mac OS X, enabling the use of multiple protocols. Eurephia 16 Personal ownership OpenVPN plug-in adding support for authentication using username and password in combination with SSL certificates. Table 6: Projects used LGPL, BSD, MIT, X11, GPLv2, GPLv3 GPLv2 GPLv2 Each of the projects above, except for the smallest one eurephia, was found to have at least one guideline covering the code. The decision taken in eurephia where based on it still being a small project, and in case of it evolving into multiple contributors a set of guidelines would be needed. In numbers the amount of guidelines and policies stated where: 15 The Adium project, 16 The eurephia project,

27 Eurephia (0) No guidelines or policies stated at the moment. Adium (1) One guide that control coding style, describing naming conventions, formatting and preferred language solutions. Qt (2) Two guidelines where found, both covering coding conventions and code design. KDE (15) Fifteen policies and guidelines where found surrounding this project, covering commit rules, different code styles in use, licensing requirements and compatibility requirements. The small amount of guidelines and policies in Adium and Qt were not expected, while it was reassuring to see the work KDE had put into their guidelines and policies. 5.2 Commit Rights to the Repository Each project manages it source code through an official repository, the central storage area where other developers and users download the most recent version. Code that is accepted into this is to be used either for further development or implementation by users, and the actions taken to ensure the quality herein is important. Combining this with keeping everything open for volunteers is a challenge, not restricting access to a degree that repels skilled developers from submitting quality code. At the same time restricting access enough to hinder malicious code and sub-quality modifications to be adopted. All the four projects gives read access to their repositories, to all developers and users, creating the ability to view and getting acquainted with coding styles and the projects knowhow. KDE was the only project where developers could get read-write access immediately. Qt A three-step process based on the workings of git. The review process starting with a merge request, telling the reviews that new code is present. Followed by a code review and quality check, then a scan for intellectual property violations. If the submitted work passes it is accepted into the project repository (Nokia, 2009). Volunteers are not granted direct write access to the repository, an option that is only available for Qt employees. KDE This project enables everyone to get direct read-write access to the repository by registering for an account. To govern quality of the contributions a set of policies and guidelines are available, it is amongst other the developer him/herself that must organize a review of the code, before uploading (KDE e.v.). Discouraging developers from doing sub-quality work, by example breaking the code, it creating and maintaining a reputation in the community. Adium Contributing to this project is based on two approaches, patch delivery that are reviewed and the ability to earn your rights to direct access after delivering a certain amount of approved patches displaying your knowledge about the project. Enabling 5-17

28 contributions from skilled volunteers to be directly merged (The Adium Team, 2009). Eurephia Contributing to this project is at the moment only possible by patches posted on the eurephia-devel mailing list. If the project contribution reaches a large amount, the reviewing will be split amongst a small group of developers that accept and included in the repository, access to all volunteers will thereby not be granted only selected volunteers can gain that privilege. 5.3 Intellectual Property Rights All projects uses licenses that grant the rights to use intellectual property owned by the contributor and included in the contributions. None of the licenses are able to protect the users in case of volunteers contributing code with false claim on ownership to included intellectual property rights (American Bar Association, 2006). From the data available, only Qt describes precautions used to handle intellectual property rights, and no information was found regarding memberships in organizations like Open Invention Network 17. Qt, being dual licensed and sold using a proprietary, requires the developer to extend the copyright to include the project owners and thereby giving them the same rights. It was found that Qt only did this after a code scan had been completed by their legal department (Nokia), minimizing the possibility for taking responsibility for any patent violations. The KDE project does give the contributor the ability to sign an optional Fiduciary Licensing Agreement 18, transferring copyright. 17 Open Invention Network, 18 Fiduciary Licensing Agreement,

29 6. Discussion This chapter includes the discussion about the two research questions stated, building the foundation for concluding later in this report. 6.1 Code Responsibility Taking advantage of the distributed development models that FLOSS enables, and thereby including code not developed in-house, has some obligations connected with it. In-house development is under normal circumstances a controlled process, the company having trust in the employees playing by the rules. This includes not copying code from their competitors and using the legal department when there is a question about ownership. FLOSS projects, especially projects that contain voluntary work, may not have been created using the same non-copying processes that the company uses itself. Thereby adding new challenges. Projects created by a single person, and including only contributions made by that person, might easily be audited before use. These projects are possibly of a smaller size, and directed against solving a limited problem, eurephia is an example of that. The country the development has taken place in is also possible to trace, an important step due to the different copyright and patent laws that is present, some countries by example not allowing copyright to be extended only rights given to extended use (Linux.com, 2007). Lacking guides and policies in those small projects is not a problem if the developer is still active and/or possible to reach for questions and thereby providing information. If the projects are inactive, or the developer has lost interest and abandoned it, a company could still develop the code further and thereby make use of it. The problem then being that any information on the code origins is lost, making it impossible to know if the code is copied or a patent followed while implementing it. Requiring more work to be undertaken, or possibly abandoning that project and start looking for another. Projects including contributions done by multiple volunteers add difficulties establishing where every piece of code originates. If the repository has public read access a thorough audit of the commit logs could help establish an overview, more difficulty arises if the distribution is based on a single archive file containing all files. Traces to each developer are then lost making it impossible to trace the origins. Larger projects, especially those including ownership or contributions made by companies, may include contributions that are based on patents given away to the community. IBM and RedHat is examples of companies that register patents on their code, then making them available royalty-free through organizations like The Open Invention Network. These are special organizations put in place to govern patent rights in such a way that is will not harm FLOSS developers and code. The owner of projects may also take responsibility for code accepted by volunteers; the Apache project an example of such projects, lowering the risk both on contributing and on usage. 6-19

30 The ease of possibly violating a patent can be illustrated by the following case: if (caps_lock_on) { beep(0.5); printf("your caps lock is on.\n"); } --from New IBM patent may encumber simple utility, (Miller, 2004). The problem auditing larger projects, and thereby creating certainty about it intellectual property compliance, is one of the reasons some developers only use FLOSS delivered from projects organized the same way as Qt, where the code is mostly created in-house and the voluntary work included is thoroughly reviewed not only for code compliancy. Projects like that also have financial backing from a company should any problems emerge in the future. A thorough audit on the project before any other actions are taken is an absolute requirement, minimizing the possibility to be held accountable for violations. 6.2 Code Quality From the four projects used in this report, the common guidelines put in place by three of them surrounded coding styles used and how a contributor should develop in order to comply. The last projects, being the smallest one of them, controlled by one person and thereby a lack of coding guidelines not affecting the projects to a large extent. Having code standards describing, by example a basic naming standard, common mistakes, how comments should be used and what they must describe in a function, is an important part of building project quality through maintaining consistency in the code. Community projects are by nature open to volunteers with different background knowledge and at different skill levels, thereby requirements seen obvious to one group of developers may be new knowledge to another group. In development done one a global scale, simple things like what languages to use in code comments need to be decided up front and later enforced throughout the project. Keeping everyone at the same level of understanding may not improve the overall quality, but it makes is easier to review later on. Consistency is not only important for the project itself, making it easier for new volunteers to contribute; it is also an important factor when other projects or companies want to do integration with their own work. Reviewing unstructured projects, where coding standards have large variations, can make the process to costly, giving a cost-benefit making it more viable undertaking completely new development or searching for other projects to use. Keeping a consistent code base is also an important base for other code quality metrics covering amongst other testability, maintainability, security and understandability. It is hard to test code that does not follow any rules and work in mostly the same way throughout, and if the code has not undergone testing it is dangerous to deem it secure. Very small projects, consisting of one person with very few contributors, may get the overall quality based on the skill level of that person. Reviewing the code in such projects will also need to include the reputation and other work contributed in order to get a complete picture. Linus Law: given enough eyeballs, all bugs are shallow (Raymond, 2001) The effect of multiple people debugging code and reviewing the ideas used in a project is also lost if it is on a to small scale. Thereby small projects should maybe only be used where they 6-20

31 are found to be of exceptional quality, or is the only way to solve a very specific problem. The medium and large scale project being opposite, having great potential for higher quality tanks to a view range of people looking at the same code. This extensive reviewing also makes the code more secure, simply by being review by many people, and possibly used by many more. Other factors that affect the quality when accepting voluntary contributions are the difficulty of a project, internally based on the type of problems it solves. Some projects are more exposed for highly skilled people simply by having difficult problems to be solved, and interesting knowledge to be learned. Thereby skilled people attract more of the same kind, making the project better quality, based on everyone striving to show-off. This could be controlled by not using volunteer work to solve all the easy problems a company needs to develop, rather giving the community difficult tasks to accomplish. Resulting in a demand for highly skilled employees to review the project. 6-21

32 7. Conclusion and Further Work This chapter contains the conclusion for this report, based on the discussion from chapter 6. It also includes thoughts collected during writing, described in short at the end. Opening up the development to include work done by volunteers, adds new opportunities and problems to the process. Done right, it is possible to save large amounts of development, enabling the company to get its product faster to the market while maintaining the customer value or even increasing it. Done wrong the effect can be devastating both for the company, its customers and the volunteers themselves. The communities have some tools in place to try and control the quality of its project, unfortunately they mainly focus on what developers are interested in and have experience creating, namely source code. Intellectual property rights and how to be confident that the project is not in violation are mainly left to the users and companies, including the work in their own projects, to decide. Business models A solid profit site, where the advantages of the company stretch beyond the parts where volunteers are contributing, is of high importance. Volunteers do not have obligations to the projects where they are involved, leaving the possibility that they contribute to many projects simultaneously or may possibly abandon the project without notice one day. Competitors may also take advantage of the same projects and the same volunteers, removing any advantages that have resulted from including that particular projects seen by it self. Any innovative and groundbreaking business model may be copied; it is more difficult and time-consuming to copy a company s reputation in the community, and its interaction with volunteers that contribute. It is thereby important to give customer value not only the company s customers, but also the volunteers building relationship. The model created needs to take into account the difference in quality, of both each contributions separately, but also the difference in total project quality. And that the quality may rapidly change, along with the policies and guidelines that cover it. Having connected activities and capabilities that can handle and correct such effects is essential to create sustainability. Innovation models A companies innovation models needs to take into account that volunteers are a part of the team, resulting in the restrictions on using closed innovation models and including the public in as much innovation as early as possible. Volunteer driven project is continuously innovating and evolving. Any innovation model chosen, in order to give maximum effect, must be able to include those innovations and preferably making them even more valuable. Today programs like Spotify have made volunteers and the public into its own innovation lab giving the opportunity to create new features and extending the program to fit the users needs. Using innovation labs open to the public, organizing feedback options and giving vast information may lead to the creation of new community projects based on volunteer driven work, that the company later on can include into it own product. Creating a circle of 7-22

33 community and company innovations all finding its way into the same product, or creating entirely new products, and seen upon as having equal value to the end-user. Letting volunteers interact with the innovation models have one large problem, user can only innovate around ideas they have, a company wanting to create ground breaking new customer value needs to think of ideas to create innovations nobody knew they needed before seeing it. 7.1 Further Work While developing this report and gathering knowledge, different ideas for future work have arisen. The most prominent idea being a medium size experiment using different models, and comparing how they react to real life occurrences building upon some of the considerations done in this report. Such an experiment would require cooperation between professions but may also create valuable observations, and maybe extended to evaluate interactions to situations yet to emerge. Another interesting case is to look more in detail at the dual licensing model, and how a model that is based on charging a fee on the code itself, code that could be voluntarily given to a project, can affect the volunteer role. Could volunteers receive economical benefits? A small notice at the end from the author, is a suggestion for further work to include directly, not just on the side in the manner done herein, people actively contributing to a community. Their experience and knowledge deserving and in many cases requires active participation. 7-23

34 8. Definitions Open Source Free Software Qt Fork Repository Community Software licensed under a license approved by the Open Source Initiative, focusing on having the source code available for people to study. Less focus on freedom than in Free Software. Software licensed under a license approved by the Free Software Foundation, focusing on freedom to use, share, study and modify the source code. Cross-platform development framework, owned by Nokia. Initiating a competing project based on source code from the original. Code storage location. Collection of volunteers contribution to reach the same goal. 8-24

35 9. Bibliography [ 1 ] American Bar Association. (2006, 7-August). Intellectual Property Law - An Overview of Open Source Software Licenses. Retrieved 2009 йил 15-December from American Bar Association - Defending Liberty, Pursuing Justice: [ 2 ] Ars Technica. (2007, 12-June). Ars at WWDC: Interview with Lars Knoll, creator of KHTML. Retrieved 2009 йил 12-December from Ars Technica: [ 3 ] Berlecon Research GmbH, University of Maastricht,. (2002). Free/Libre and Open Source Software: Survey and Study. International Institute of Infonomics, University of Maastricht and Berlecon Research GmbH, EU. [ 4 ] Blanchette, J., & Summerfield, M. (2006). A Brief History of Qt. In J. Blanchette, & M. Summerfield, C++ GUI Programming with Qt 4 (pp. xiii - xiv). Prentice Hall. [ 5 ] Carlson, C. R., & Wilmot, W. W. (2006). Innovation: The Five Disciplines for Creating What Customers Want. New York: Crown Publishing Group. [ 6 ] Chance, T. (2005, 18-October). Linux.com :: Trolltech: A case study in open source business. Retrieved 2009 йил 11-December from Linux.com The source for Linux information: [ 7 ] CNET News. (2005, 12-May). Open-source divorce for Apple's Safari? - CNET News. Retrieved 2009 йил 12-December from Technology News - CNET News: [ 8 ] Daffara, C. (2009). The Small/Medium Enterprise guide to Open Source Software. The FLOSSMetrics EU project. [ 9 ] DiBona, C., Ockman, S., & Stone, M. (1999). Open Sources: Voices of the Open Source Revolution. Sebastopol: O'Reilly & Associates, Inc. [ 10 ] Feller, J., & Fitzgerald, B. (2002). Understanding Open Source Software Development. London: Person Education Limited. [ 11 ] Free Software Foundation, Inc. (2009, 27-October). The Free Software Definition. Retrieved 2009 йил 11-November from The GNU Operating System: [ 12 ] Gartner, Inc. (2008, 31-January). Gartner Highlights Key Predictions for IT Organisations and Users in 2008 and Beyond. Retrieved 2009 йил 3-December from Gartner Technology Business Research Insight: [ 13 ] Gohring, N., & Perez, J. C. (2009, 11-June). Google strives to balance commercial, community with Android The Industry Standard. Retrieved 2009 йил 7-December from The Industry Standard:

36 [ 14 ] Grant, R. M. (2008). Analyzing Resources and Capabilities. In R. M. Grant, Contemporary Strategy Analysis (Vol. 6, pp ). Blackwell Publishing Ltd. [ 15 ] Hinkle, M. R. (2007, 4-May). Editorial Welcome to Opensville Open Source Magazine. Retrieved 2009 йил 7-December from Open Source Magazine: [ 16 ] Hippel, E. v. (2005). Democratizing Innovation. London: The MIT Press. [ 17 ] Hippel, E. v., & Krogh, G. v. (2002). Open Source Software and the Private-Collective Innovation Model: Issues for Organization Science. Organization Science. [ 18 ] KDE e.v. (n.d.). Contribute/Get a SVN Account - KDE TechBase. Retrieved 2009 йил 15- December from KDE TechBase: [ 19 ] KDE. (n.d.). History: The Qt Issue. Retrieved 2009 йил 5-December from KDE - be free: [ 20 ] KDE Quality Team. (n.d.). KDE Quality Team - KDE and Free Software General Policies. Retrieved 2009 йил 14-December from KDE Quality Team - KDE Quality Team: [ 21 ] Linux.com. (2007, February 12). Linux.com :: FSFE's Fiduciary License Agreement is no panacea. Retrieved December 16, 2009, from Linux.com The source for Linux information: [ 22 ] McPherson, A., Proffitt, B., & Hale-Evans, R. (2008). Estimating the Total Development Cost of a Linux Distribution. San Francisco: The Linux Foundation. [ 23 ] Melton, D. (2003, 7-January). '(fwd) Greetings from the Safari team at Apple Computer' - MARC. Retrieved 2009 йил 12-December from MARC: Mailing list ARChives: [ 24 ] Miller, R. (2004, June 11). Linux.com :: New IBM patent may encumber simple utility. Retrieved December 16, 2009, from Linux.com The source for Linux information: [ 25 ] Mozilla Foundation. (n.d.). History of the Mozilla Project. Retrieved 2009 йил 9-December from Mozilla.org - Home of the Mozilla Project: [ 26 ] Nokia. (n.d.). Contribute to Qt Qt - A cross-platform application and UI framework. Retrieved 2009 йил 14-December from Qt - A cross-platform application and UI framework: [ 27 ] Nokia. (2009, 14-January). LGPL License Option Added to Qt Qt - A cross-platform application and UI framework. Retrieved 2009 йил 11-December from Qt - A cross-platform application and UI framework: [ 28 ] Nokia. (2009, 7-October). Qt - QtContributionGuidelines - Wiki - Qt by Nokia. Retrieved 2009 йил 15-December from Qt by Nokia: [ 29 ] Nokia. (n.d.). Qt Licensing Qt - A cross-platform application and UI framework. Retrieved 2009 йил 5-December from Qt - A cross-platform application and UI framework:

37 [ 30 ] Nokia. (2009, 11-May). Qt now open for community contributions. Retrieved 2009 йил 4- December from Qt - A cross-platform application and UI framework: [ 31 ] Nokia Software Products. (2009, 11-May). Agreement Qt - A cross-platform application and UI framework. Retrieved 2009 йил 4-December from Qt - A cross-platform application and UI framework: [ 32 ] Open Source Initiative. (2006). Report of License Proliferation Committee and draft FAQ. Retrieved 2009 йил 16-November from Open Source Initiative: [ 33 ] Open Source Initiative. (2009). The Open Source Definition. Retrieved 2009 йил 11-November from [ 34 ] Parloff, R. (2007, 14-May). Microsoft claims software like Linux violates its patents - May 28, Retrieved 2009 йил 13-December from Fortune 500 Daily & Breaking Business News - FORTUNE on CNNMoney.com: [ 35 ] Rappa, M. (2009, 1-June). Business Models on the Web Professor Michael Rappa. Retrieved 2009 йил 10-December from Managing the Digital Enterprise Professor Michael Rappa: [ 36 ] Raymond, E. S. (2001). The Cathedral and the Bazaar (Vol. 2). California, US: O'Reilly Media, Inc. [ 37 ] Reichard, K. (2000 йил 4-September). LinuxPlanet - Reports - Trolltech to Release Qt Under GPL - Decision Alters Linux GUI Landscape:. Retrieved 2009 йил 4-December from Linux Planet: [ 38 ] Riehle, D., Ellenberger, J., Menahem, T., Mikhailovski, B., Natchetoi, Y., Naveh, B., et al. (2009, March/April). Open Collaboration within Corporations Using Software Forges. IEEE Software, 2009 (26), pp [ 39 ] The Adium Team. (2009, 24-August). CommitterRules Adium Trac. Retrieved 2009 йил 15- December from Adium Trac: [ 40 ] Tidd, J. (2006). Innovation Models. Imperial College London. [ 41 ] Troll Tech AS. (n.d.). TROLL TECH FREE SOFTWARE LICENSE. Retrieved 2009 йил 5- December from KDE - be free: [ 42 ] Troll Tech; The KDE Project. (1998, June). KDE - KDE Free Qt Foundation. Retrieved 2009 йил 11-December from KDE - Be free: [ 43 ] Tucci, C. L., & Afuah, A. (2003). Internet Business Models and Strategies: Text and Cases (Vol. 2). New York: McGraw-Hill Higher Education. [ 44 ] Välimäki, M. (2003). Dual Licensing in Open Source Software Industry. Systemes d!information et Management, 8 (1), pp [ 45 ] WebKit. (n.d.). The WebKit Open Source Project - WebKit Project Goals. Retrieved 2009 йил 13- December from The WebKit Open Source Project:

38 [ 46 ] Wheeler, D. A. (2009, 6-October). Make Your Open Source Software GPL-Compatible. Or Else. Retrieved 2009 йил 2-December from David A. Wheeler s Personal Home Page: [ 47 ] Ye, Y., & Kishida, K. (2003). Toward an Understanding of the Motivation Open Source Software Developers. Proceedings of the 25th International Conference on Software Engineering,

39 Appendix A: Policies and Guidelines These are the policies and guidelines that where found stated for each project. Eurephia: This project does not have any policies and guidelines. Adium: Coding style guidelines Qt: API Design Principles. Coding Conventions. KDE: SVN Commit Policy Application Life Cycle Licensing Policy Library Documentation Policy Library Code Policy Kdelibs Coding Style Adding New Classes to kdelibs CMake Coding Style CMake and Source Compatibility CMake Commit Policies Binary Compatibility Issues With C++ (Original) URI & XML Namespaces Policy API to Avoid Security Policy Packaging Policy 29

40 Appendix B: Illustrated Contribution Models Illustrations of the commit processes used by the Qt and eurephia projects. Qt project 19 : Figure 2: Qt contribution model, figure from Qt Development Frameworks 19 Eurephia 20 : Figure 3: Integration Manager Workflow, figure from whygitisbetterthanx.com Qt contribution model, figure from: 20 Integration Manager Workflow, figure from: - any-workflow 30