# In-between Open and Closed - Drawing the Fine Line in Hybrid Communities

Hanna Mäenpää, Terhi Kilamo, Tomi Männistö

<figure><img src="image_1.png" /></figure>

## To cite this version:

Hanna Mäenpää, Terhi Kilamo, Tomi Männistö. In-between Open and Closed - Drawing the Fine Line in Hybrid Communities. 12th IFIP International Conference on Open Source Systems (OSS), May 2016, Gothenburg, Sweden. pp.134-146, 10.1007/978-3-319-39225-7_11. hal-01369059

HAL Id: hal-01369059

https://inria.hal.science/hal-01369059

Submitted on 20 Sep 2016

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# In-between Open and Closed - Drawing the Fine Line in Hybrid Communities

Hanna Mäenpää<fnref n="1" />, Terhi Kilamo<fnref n="2" />, Tomi Männistö<fnref n="1" />

**Abstract.** Today, the community driven development model extends into a variety of new, often web based collaborations. Among these are hybrid open source development set ups in which various online tools are used to facilitate cooperation between virtual teams of commercial and voluntary stakeholders. As yet, how these relationships form and evolve is not understood extensively. This article presents a longitudinal case study of a smartphone startup that founded its early product development strategy on reliance on feedback from its customers through a web based question and answer forum. With this, the company managed to extend values typical for open source communities to support development of its proprietary software. Our main findings include that the challenge in similar settings lies in striking the right balance between the open and the proprietary – while overt openness may risk the competitive advantage of a company, leaving too much behind closed boundaries can create unnecessary friction in the relationship.

**Keywords:** crowdsourcing, customer community, open source software

## 1 Introduction

The open innovation approach allows profit-oriented companies to outsource tasks that are essential for their production process to the general public, yielding results for significantly less expense than companies would otherwise be willing to invest [1,2,3]. A desired audience for these collaborations are lead users who pioneer in identifying needs for technical solutions and are willing to bear some of the costs and risks of fulfilling them [4]. Therefore, collaborating with Open Source Software (OSS) communities and adopting their ways of working have been identified as promising growth strategies for software companies [5]. These opportunities are especially highlighted at both early stages of product development [6] and when introducing new innovations to the marketplace [7,1,8].

<footnote n="1">¹Department of Computer Science, University of Helsinki, P.O. 68 (Gustaf Hällströmin katu 2b), FI-00014 University of Helsinki, Finland
hanna.maenpaa@helsinki.fi, tomi.mannisto@helsinki.fi</footnote>

<footnote n="2">²Department of Pervasive Computing, Tampere University of Technology, Korkeakoulunkatu 1, FI-33720 Tampere, Finland
terhi.kilamo@tut.fi</footnote>
Understanding how these relationships in between companies and their 'unpaid employees' [1] can form and be managed has not yet received much attention from the scientific community. Future research is called for to understand reasons for entering these relationships [5], as well as on principles, processes [9] and forms of control [10] that take place in their governance.

The main contribution of our paper is to report how proprietary software development can be supported by an open innovation community for customers, describing how knowledge can act as both a reward and a detriment for motivation in this setting. In the next section, a theoretical background is laid for understanding the context of our study. Section 3 introduces the research approach. A description of the case company is provided in section 4, followed by results of the study in section 5. The work is concluded by discussing implications in sections 6 and 7.

## 2 Background

Open Source Software communities consist of individuals, many of whom participate voluntarily and out of their own inherent interests in the development activities. Here, decision power is distributed among people who belong to the same community and individuals are empowered to make decisions based on their personal merit [11,9,12]. When commercial stakeholders enter this environment, their interests become blended with those of the voluntary contributors, creating a hybrid environment where a balance needs to be struck between the community based decision making and centralized governance that is typical for companies [13,14,11].

In these collaborations, the commercial stakeholder must often be prepared to align its own strategy to fit that of the existing community – or to establish a new one [8]. In the latter case, the amount of power vested in external collaborators can manifest in initial decisions about who gets to participate in the activities, how responsibilities are shared [15] and how rights to contribute to decisions are gained [9]. An apt division of knowledge, labor and decision power is needed to build trust and reciprocity between the stakeholders [10,16,11]. This balance can be achieved through conscious decisions on how the community is built and governed and what socio-technical infrastructure it is to be supported by [17].

When voluntary, non-affiliated individuals affect product development remarkably, an unclear legal relationship between a company and its contributors may emerge [18]. This can be managed by keeping the intellectual property rights of selected software assets in the company, creating a “gate” for the voluntary contributors [17]. This limits their possibilities to not only modify and re-use the software, but also to know about and have influence on its development decisions [17]. As the values of community driven development ideology become compromised, the motivation of contributors decrease as they feel their opinions are not being heard [19,9]. In this context, encouraging a global voice of the customers on open platforms may prove harmful as users willingly share their bad experiences in public. Therefore it is important to have a strategy for curating
the community created content and for evaluating users by their trustworthiness. Equally important to identifying malicious users is rewarding users that are influential and produce interactions that are of a high quality [20]. A visible commitment from top management is often required [16,5].

Research is called for to understand the reasons why companies choose to use OSS collaborations as the core of their value creation processes (Henttonen et al. 2012), what principles and processes constitute community management in this environment (O'Mahony, 2007) and how these managerial practices can evolve on a longitudinal perspective (Di Tullio et al. 2013).

# 3 Research approach and questions

We employed a mixed method case study [21,22] on a longitudinal perspective from December 2013 to November 2015, focusing on how a company created and managed an online customer community<fnref n="1" />. Our aim was to answer the following research questions:

**RQ1:** How can an open community aid the development of proprietary software?

**RQ2:** How can a company **initiate an open community** for collaboration in software development?

**RQ3:** How can a company **manage the collaboration** with its open community?

As the phenomenon in focus is inseparable from its context, a combination of different viewpoints, data sources and research methods were used to create a realistic representation [22]. These are overviewed in the following subsections.

## 3.1 Viewpoint of the company

Our research started by characterizing the company and forming a general understanding of its crowdsourcing strategy. For this, freely available documents such as press releases, blog posts and social media interactions of managers were observed manually. This was continued until the end of the research period.

In January 2014, we selected two of the company's employees based on their active role in the customer community and performed an in person, semi structured interview to understand their conscious aims in building the community. Questions included: "What is your role in your company's internal software development process? How do you use the knowledge from the online community in your work?". Follow-up interviews were performed in June 2014 later in April 2015 to review how the community created knowledge was currently influencing software development decisions, how the managerial practices had evolved and what concrete new forms the collaboration had taken throughout the months.

<footnote n="1">¹ http://together.jolla.com</footnote>
## 3.2 Viewpoint of customers

From early on, we recognized the need for including the customers' viewpoint in the study. To prepare for this, a semi structured telephone interview was performed with a voluntary community moderator (CM) in June 2014, seeking answers to questions such as: "What have been the success factors and pitfalls of building the community? Why do people choose to work for the benefit of the company without rewards? How do you see the role of the online platform in this collaboration?" Results highlighted the need for understanding motivation of individual community members and prepared us for choosing a theoretical alignment for addressing it [12]. We composed a survey with 12 Likert scale questions of motivational factors and two open ended questions about other reasons for participating. The survey was instrumented to the online community website on June 25th 2014, yielding 192 responses through the three week survey period. This study was repeated in November 2015 to review whether the motivation of the members had changed along time. The latter survey received 101 responses.

## 3.3 Actions of the stakeholders

In addition to self reporting by individuals, we wanted an objective representation of actions the community members had performed during the research period. For this aim, the community created content was first sampled in February 2014 with the help of a web crawler<fnref n="2" />. A quantitative overview of meta keywords attached to the messages by community members was formed to distinguish the most common discussion topics. 25 examples of discussions were chosen and qualitative analysis of their textual content was performed to model their interaction sequences, two of which are illustrated in Figure 2. In addition to the community created content, we harvested all freely available user profile records to review the growth of the registered user base.

An identical data set was yielded later in November 2015 using a Software as a-Service tool tool<fnref n="3" /> and a retrospective of the community's development and concrete actions its members had engaged in could be formed. The number of items in each data sample are presented in Table 3.3. Due to the space limitation, we are able to present only a summary of this work.

<table><caption>Table 1: Data items in the customer community content data samples</caption><thead><tr><td>Sample</td><td>February 2014</td><td>November 2015</td></tr></thead><tbody><tr><td>Number of messages</td><td>2 473</td><td>13 332</td></tr><tr><td>Keywords in the content</td><td>1 151</td><td>10 577</td></tr><tr><td>User profile records</td><td>2 716</td><td>8 449</td></tr></tbody></table>

<footnote n="2">² Scrapy Python script</footnote>

<footnote n="3">³ Cloudscrape</footnote>
# 4 Case: Jolla Together

The case company, Jolla, was established in 2011. Their first product, a smartphone, was launched by a crowdfunding campaign in May 2013 and delivered to pre-order customers in 136 countries in December 2013 [23]. The devices were equipped with Sailfish, an operating system (OS) founded on open source components such the Linux kernel<fnref n="4" />, Mer OS middleware<fnref n="5" /> and application layer framework Qt<fnref n="6" />. The company's collaboration strategies with the external OSS communities were various: work of the Linux community set the foundation of their product. They sought benefit from and contributed to the work of the Mer and Qt communities. For application development, Jolla chose to host an application store platform - trusting that an ecosystem of independent application developers would emerge among their first customers.

Jolla's largest contribution to Sailfish OS were libraries that defined fundamentals of user experience, including hand gestures, user interface themes and basic applications for calling, messaging and managing contacts. For them, a proprietary licensing strategy was chosen, securing the company's competitive advantage of building an user experience "unlike" those of its competitors. Figure 1 presents the Sailfish OS software architecture, related licensing models and the collaboration strategies.

Sailfish OS was introduced as a minimally viable prototype to the customers and the smartphone was to be used as a toolkit for lead user innovation in early product development. For harvesting feedback, an online forum, *together.jolla.com*, was opened. Later in the text, we call this forum *the online (customer) community* or *Together* for short. Users of the forum we refer to as *online community members* or *customers*. The following chapters present our findings on how this relationship was initiated and what practices were used in guiding the customer community to support the company's internal proprietary software development process. Implications for similar settings are discussed later in chapter 6.

# 5 Results

While sections 5.1 and 5.2 address RQ2. Sections 5.3 and 5.4 seek to provide answers for RQ3. Based on these, RQ1 is later discussed in chapter 6.

## 5.1 Initiating the customer community

Jolla used minimal marketing efforts in initiating the customer community: new smartphone owners had received an invitation in their delivery box and management had sent Twitter messages [24] welcoming people to join. The online

<footnote n="4">⁴ https://www.kernel.org/</footnote>

<footnote n="5">⁵ http://merproject.org</footnote>

<footnote n="6">⁶ http://qt.io</footnote>
community platform<fnref n="7" /> allowed asking questions, answering and commenting on them, attaching keywords and voting publicly on any piece of the content created. “The first evening we had hundreds of people logged in and contributing”, explained the quality manager in January 2014. Jolla’s value proposition was “We want to create an innovation platform for ideas, opportunities and openness.” To highlight this, customers were engaged with aspects that were not commonly discussed in public such as packaging and manuals<fnref n="8" />, brand values<fnref n="9" />, delivery strategies<fnref n="10" /> and future visions of the hardware<fnref n="11" />. Ideas were vividly shared, refined and ranked by voting. Section (A) of Figure 2 displays a typical idea harvesting interaction pattern. As the Askbot platform supported gathering personal “karma” community members were allowed to self-organize: moderators were elected via a process of self-representation and voting and best practices for content organization were agreed upon. In addition to the moderator status, employees of the company were marked with a logo alongside their member profile. Jolla’s software quality manager (QM) established a visible and interactive role among the community members. “He did great work in focusing the discussion and solving conflicts constructively. [sic] He wanted to have both customers and employees have an equal voice in both asking and answering questions”, a community moderator explained in April 2014.

<figure><img src="image_3.png" /><figcaption>**Fig. 1.** Licensing architecture of Sailfish OS and the company's strategies for collaborating with external communities. Adapted from https://sailfishos.org/about/</figcaption></figure>

<footnote n="7">⁷ http://www.askbot.com</footnote>

<footnote n="8">⁸ "What's missing from the user guide?"</footnote>

<footnote n="9">⁹ "What does Jolla mean to you?"</footnote>

<footnote n="10">¹⁰ "What hardware / devices would you like to see Sailfish OS on?"</footnote>

<footnote n="11">¹¹ "Poll: The Other Half of Your Dreams"</footnote>
<figure><img src="image_4.png" /><figcaption>Fig. 2. Typical collaboration patterns between the company and customers</figcaption></figure>

## 5.2 Creating a focus

The online community acted as the first touchpoint for customers and defects quickly emerged as the most discussed topic. A majority of questions concerned elementary interactions: importing contacts, typing text, using email and browsing the web. The company had prepared for this - questions such as "Did you have trouble with Jolla not discovering GPRS/3G data settings?" had been submitted to wait for the customers' attention. This particular question briefly resulted in 29 professionally crafted test reports from 17 geographical locations around the world.

Most defects were submitted by the customers themselves and were followed by comments with rich detail of the testing process. As a defect had been described satisfyingly, community members created hypotheses about its origins and presented suggestions for solving it. Voting complemented these interactions by providing indicators on the urgency of the problem, feasibility of the solutions and quality of related comments. Figure 2 (B) presents a common defect reporting interaction. After six months, feedback from the customer community had become the main source of knowledge for the company's software product development decisions.
5.3 Sustaining motivation of contributors

As already in February 2014 the company’s integration and release mechanism allowed a stable software update to be delivered monthly, discussing a bug and then seeing it fixed was gratifying for all involved. Members had become aware of the value of their contributions, demanded more say on prioritization<fnref n="12" /> and information about the progress of the development<fnref n="13" />. "Customers are demanding in this regard. Sometimes we give a time window for releases but it is not enough. When the window is starting to get smaller, users ask: Hey Where is the update, What’s happening? I want it now!" QM explained. Here, the software program manager (PM) came to be in a key role to control visibility to the progress. Status codes began to be marked by modifying headlines of the original defect report messages (Figure 3).

As pointed out by the forum moderator, the Askbot platform “had not served its purpose well”. Rapid pace of interactions encumbered organization of the content and voting based community evaluation emphasized opinions of the most active and loudest members. “Even if crucial, a feature that is important to a niche user segment does not reach enough attention to be noticed by the company” he explained. At the same time, the extensive input from the customer community seemed to be overwhelming for the company. “In some cases it might not be feasible to implement even those (features) that the great majority advocates for” the quality manager explained. However cumbersome managing the in- and outflow of knowledge was, the company still ruled out giving visibility to their internal bug reporting and workflow coordination tools.

<figure><img src="image_5.png" /><figcaption>Fig. 3. Notification of progress in a message headline on together.jolla.com</figcaption></figure>

For the proprietary licensing of the user experience components, community members perceived the subject of their contributions as a black box. While no external rewards or guarantees on uptake of their innovations were made by the company, the motivation of the participants became of interest. Our first survey was performed in June 2014 for 193 customer community members. Results revealed that a total of 89% were owners of the Jolla smartphone and 32% indicated an affiliation with OSS development. A prime motivator was to make a better product for themselves (92% agreed) and to receive (90%) and to give (77%) help in using the smartphone. While creating new ideas inspired the customers (77%), a majority of the respondents wanted to help the company directly to succeed (90%).

<footnote n="12">¹² "Jolla should target business users"</footnote>

<footnote n="13">¹³ Which features do you crave and would like to know its roadmap status on?</footnote>
The second survey of 101 persons in November 2015 confirmed that the motivational factors had not changed in almost two years. The most active online community members had remained smartphone owners (83%) and the proportion of open source developers in the population was roughly one third. Contributors were still inspired by the product, the company's way of working and altruism. A noteworthy change was that neither recognition among peers (8% positive, 26% negative) nor showcasing expertise to the company (7% positive, 26% negative) were dominant among the community members. Willingness to help the company to succeed had decreased only somewhat (Strongly agree -19%, agree somewhat -12%). Still, as the company faced the need for steamlining its operations in November 2015, the loyalty of the customers manifested as initiatives for crowdfunding campaigns<fnref n="14" /> to help the company.

When asked about the members’ “other” and “ideological” reasons for participating, a clear majority reported being motivated by characteristics of the OSS ideology: freedom, openness and empowerment of individuals to control their own information and assets. As one respondent summarized: “I love the idea to exit from iOS, Windows and especially Android world: with Sailfish we’re talking about real open source, freedom and the close contact between us users and the Company giving us the possibility to do something new, unlike and interesting.”.

## 5.4 Evolution of practices

As the number of Sailfish OS devices grew, pre-release testing had gained emphasis and the company strengthened its internal process with a small, closed group of community members who were given release candidates *before* they were delivered to the customers. *"This helps us to confirm the quality of our*

<figure><img src="image_6.png" /><figcaption>**Fig. 4.** Roles of customers in supporting the company's internal software process</figcaption></figure>

<footnote n="14">¹⁴ https://together.jolla.com/question/122312/emergency-crowdfunding/</footnote>
*releases before they are released to the rest of our customers.*" explained the software program manager in March 2015. Later, the company had started an "early access" test community by providing any Sailfish OS user with an unreleased version of the OS after the C-Beta group had sufficiently tested it. "*If no critical issues are found from in field, we release the update to the rest our end users.*" After the improvements, feedback from the web based question and answer forum started to have less impact on the company's short term planning compared to its early stages. "*Decisions mostly rely on technical know-how and debts in software to stir the development in the right direction*" explained the software program manager in March 2015, continuing: "*Feedback and reports from Together still guide us to identify the most painful issues for our end users.*" Figure 4 displays the relationship of the described sub communities to the whole customer population.

# 6 Discussion

First, limitations of the study are described. Sections 6.2 and 6.3 provide answers to research questions RQ2 and RQ3, laying the foundation of understanding how the open community model can aid the development of proprietary software (RQ1) in similar settings. This question is discussed in Section 6.4 with implications.

## 6.1 Limitations

Several factors of both the phenomenon and our study design limit generalisation of the results. Our surveys, in spite of the high number of participants, represent at best only a fraction of the Together community's active members who on their part represent a limited subset of Jolla's customers (see Figure 4). Our sampling strategy is thus inclined to present characteristics of not a random set but a purposefully selected sample [22] of those customers who are the most actively involved in the community. We claim that these people have been some of the most influential in the relationship and argue that the set represents that of early adopters (i.e. lead users) of the Sailfish OS technology. The history of the company as a continuum of Nokia's work may partly explain the community's loyalty and proneness to support values of OSS development. Therefore, the results can not be generalized to any product development context as is. However, we claim the results to be directional to situations where both the product in question relies on OSS software and at the same time a large personal investment on a hardware product has already been made.

## 6.2 Initiating the collaboration

Offering the smartphone as a pre-order campaign helped the company to test the viability of the product concept and size of its market. Customers made an initial financial commitment to the company and were set to expect an unpolished
product. This, combined with an invitation to help build the product together with the company and low barrier of communication with employees created a promising start for the collaboration.

The OSS related history of the product resonated strongly with a small, yet very active group of lead users. However, using an independent, web based community platform that anybody could easily register to invited non-technical users to participate in the collaboration. While the platform supported merit based self-representation and autonomous decision making, users were given tools to organize and manage their own contributions. Even though the customer community was open for anybody to join, a between-the-lines prerequisite was the customership: discussions dealt almost solely with either using or not being able to use the product. This created an aim for contributors: to solve problems and help others in doing so. Personal achievement and helping others were altruistically celebrated. As the community managed its own contributions the company was relieved from curating the content. Voicing constructive criticism was allowed, increasing the quality of contributions while multiple viewpoints could be represented. Benefits for the crowdsourcing practise were indisputable. As at that time the company operated in only two cities in Finland, the extent of the testing activities could not have been achieved without the help of its customers.

## 6.3 Managing the collaboration

The company had chosen a gated source approach for the UX components of Sailfish OS, yet its strategy was to acquire feedback for developing them from customers from the customer community. This allowed hiding specifics of the software process from external contributors. Surprisingly, for the first years, no visible incentives were required to sustain the collaboration.

A large reward for contributors was the frequent and timely delivery of OS upgrades and thus, knowing when and what was to be shipped acted as a powerful incentive. While the company promised its customers openness and transparency, the "gate" created pressures for disclosing information. Maneuvering the situation required careful consideration on what, where, and to whom knowledge should be let out. Neither decision power, full transparency of the development process were ever offered as incentives - the company chose to offer more information about its internal development process through personal interactions with only those customers who were willing to contribute more to their development process.

## 6.4 Applying the community driven model in similar settings

Our main research question (RQ1) calls for understanding how an open community of contributors can support development of proprietary software. We described a specialized setting where a company founded its product on open source collaborations, searched a crowd for funding its development and harnessed the first customers for contributions that helped the company take its first steps for the first two years of its existence.
From this, we learned that in order to gain benefit for the proprietary de-
velopment, the values of the company have to match those of the community.
A sincere relationship between the stakeholders needs to be created and more
interactive this relationship is, the richer results are to be expected. However,
all interactions require time and effort from the company and to balance this,
a sufficient degree of autonomy for the community in managing its own actions
and contributions is required. From the online tools this requires support for
merit-based self-representation, consensus decision making and general enough
functionality that allows diverse types of interactions to emerge.

As a community matures, value of its work becomes established. Therefore,
the need and means for rewarding voluntary contributors should be reconsidered
from time to time. While several motivations are at play, reciprocity in the
community membership experience is important, as well as sustaining the focus
of the community's work on its original purpose. In our case, weaving all this
together required the hosting company to have a strict policy of what knowledge
to disclose, what issues to take a stand on and what not.

7 Conclusions

The interplay of community driven values and commercial interests flourish in hybrid OSS communities. To explore this phenomenon, we used interviews and surveys supported with publicly available data to follow the inception and management of an open, online customer community. Our main findings include that the challenge in similar settings lies in striking the right balance between the open and the proprietary – while overt openness may risk the competitive advantage of a company, leaving too much behind closed boundaries can create unnecessary friction in the relationship. Where the fine lines are drawn depends on how much knowledge, decision power and autonomy are vested in the community.

8 Acknowledgments

The authors wish to thank Digile's Need4Speed program<fnref n="15" /> funded by the Finnish Funding Agency for Innovation (Tekes<fnref n="16" />) for its support for this research. We are also grateful to Sezin Yaman, Max Pagels, Sini Ruohomaa, Soumya Billal and Eric Le Roux.

References

1. F. Kleemann, G. Vo, and K. Rieder, “Un(der)paid innovators: The commercial utilization of consumer work through crowdsourcing,” *Science, Technology & In-novation Studies*, vol. 4, no. 1, 2008.

<footnote n="15">¹⁵ http://www.n4s.fi/</footnote>

<footnote n="16">¹⁶ http://www.tekes.fi/en/tekes/</footnote>
2. J. Pénin and T. Burger-Helmchen, "Crowdsourcing of inventive activities: definition and limits," *International Journal of Innovation and Sustainable Development*, vol. 5, no. 2-3, pp. 246-263, 2011.

3. E. Estellés-Arolas and F. González-Ladrón-de Guevara, "Towards an integrated crowdsourcing definition," *Journal of Information science*, vol. 38, no. 2, pp. 189-200, 2012.

4. E. von Hippel, "Lead users: A source of novel product concepts," *Management Science*, vol. 32, no. 7, pp. 791-805, 1986.

5. K. Henttonen, P. Pussinen, and T. Koivumäki, "Managerial perspective on open source collaboration and networked innovation," *Journal of technology management & innovation*, vol. 7, no. 3, pp. 135-147, 2012.

6. J. Kim and D. Wilemon, "Focusing the fuzzy frontend in new product development," *R&D Management*, vol. 32, no. 4, pp. 269-279, 2002.

7. V. Duarte and S. Sarkar, "Separating the wheat from the chaff: a taxonomy of open innovation," *European Journal of Innovation Management*, vol. 14, no. 4, pp. 435-459, 2011.

8. E. Schenk and C. Guittard, "Towards a characterization of crowdsourcing practices," *Journal of Innovation Economics*, vol. 0, no. 1, pp. 93-107, 2011.

9. S. O' Mahony, "The governance of open source initiatives: what does it mean to be community managed?" *Journal of Management & Governance*, vol. 11, no. 2, pp. 139-150, 2007.

10. D. Di Tullio and D. S. Staples, "The governance and control of open source software projects," *Journal of Management Information Systems*, vol. 30, no. 3, pp. 49-80, 2013.

11. S. Sharma, V. Sugumaran, and B. Rajagopalan, "A framework for creating hybrid-open source software communities," *Information Systems Journal*, vol. 12, no. 1, pp. 7-25, 2002.

12. M. Antikainen, M. Mäkipää, and M. Ahonen, "Motivating and supporting collaboration in open innovation," *European Journal of Innovation Management*, vol. 13, no. 1, pp. 100-119, 2010.

13. Y. Benkler, "Coase's penguin, or linux and the nature of the firm," *Yale Law Journal*, pp. 369-446, 2002.

14. B. Fitzgerald, "The transformation of open source software," *Mis Quarterly*, pp. 587-598, 2006.

15. V. Midha and A. Bhattachacherjee, "Governance practices and software maintenance: A study of open source projects," *Decision Support Systems*, vol. 54, no. 1, pp. 23-32, 2012.

16. L. Dahlander and M. Magnusson, "How do firms make use of open source communities?" *Long Range Planning*, vol. 41, no. 6, pp. 629-649, 2008.

17. S. K. Shah, "Motivation, governance, and the viability of hybrid forms in open source software development," *Management Science*, vol. 52, no. 7, pp. 1000-1014, 2006.

18. S. M. Wolfson and M. Lease, "Look before you leap: Legal pitfalls of crowdsourcing," *Proceedings of the American Society for Information Science and Technology*, vol. 48, no. 1, pp. 1-10, 2011.

19. S. K. Shah, "Understanding the nature of participation and coordination in open and gated source software development communities." in *Academy of Management Proceedings*, vol. 2004, no. 1. Academy of Management, 2004, pp. B1-B5.

20. A. Doan, R. Ramakrishnan, and A. Y. Halevy, "Crowdsourcing systems on the world-wide web," *Communications of the ACM*, vol. 54, no. 4, pp. 86-96, 2011.
21. P. Runeson and M. Höst, "Guidelines for conducting and reporting case study research in software engineering," *Empirical software engineering*, vol. 14, no. 2, pp. 131-164, 2009.

22. R. K. Yin, *Case study research: Design and methods*. Sage publications, 2013.

23. (2013, Aug.) Press release of the first smartphone pre-order campaign's progress. [Online]. Available: https://cdn.jolla.com/wp-content/uploads/bsk-pdf-manager/5_JOLLA PRESs RELEASE 21.8.2013.PDF

24. (2013, Dec.) Welcome message from the company to join the together.jolla.com online customer community. [Online]. Available: https://twitter.com/JollaHQ/status/415868959519698944