Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

Open innovation communities create complicated issues for organisations and researchers because they are more multifaceted than simply technology-enabled groups; they are a mix of power and knowledge, liberty and enlightenment, progress and intervention (Kelty 2009). Open innovation communities adapt to dynamically changing situations, accommodate altered plans and engage in non-typical, cooperative work in which there is an emergence, never a guarantee, of stability (Germonprez et al. 2007). In our chapter, we define an open innovation community as a collection of varied organisational members where organisations approach the community as a strategic motivation and seek to leverage the community for organisational benefit (West and Lakhani 2008).

The technology used in an open innovation community is only one-half of the design process. The other, equally important half includes the reflective, active and interactive practices that community members engage in. Within open innovation communities, members create new structural couplings in alignment with their domain of action in coordinating efforts, eliminating redundancy, pursuing options and sequencing activities (Germonprez et al. 2007). As design and development evolve within open innovation communities, new affordances present new possibilities and organisations must balance “contributions to” and “differentiation from” the open innovation community for reasons of cost, resource management and time to market. These considerations are instilled in both practice and academe, and in this chapter we aim to contribute to the advancement of both organisational participation and research inquiry in open innovation communities.

We build on principles of public sharing and collaboration using the Linux open-source community as our basis for understanding (see Fitzgerald 2006). The Linux Foundation estimated the value of Linux to be $10.8 billion in 2008 with the number of participants surpassing 3,500, illustrating that the Linux open innovation community is both viable and important for study. While open source is strictly a licensing distinction that does not necessarily define an open innovation community, it is often used to describe permissively licenced software developed by an open innovation community (Fitzgerald 2006; Ågerfalk et al. 2009). The focus of this chapter is not on Linux per se; rather it is on open innovation community participation associated with the design and development of Linux.

We explore primary features of organisational participation with the Linux open innovation community including leverage, contribution and differentiation. Leverage constitutes the power of open innovation community to benefit all participants: How does the community provide advantages for participants? Contributions constitute the degree to which community participants play a part in the open innovation community: Do they actively engage in the design and development of Linux? Differentiation constitutes the degree to which participants follow the primary release of the artefact: Do they use Linux as publicly released or do they differentiate it for internal reasons? Practice and research are beginning to address these issues through frameworks, theories, methods and contributions of open innovation communities (von Hippel and von Krogh 2003; Henkel 2006; Ågerfalk et al. 2009). To extend literature on open innovation community participation, we used reference literature and the Linux open innovation community to create frameworks relevant to both our problem and research domains. To begin, we understand the interaction between the open innovation community and the corporate organisation and consider what characteristics foster a relationship. In doing this, we address why organisations participate with the Linux open innovation community, leading us to our first of two research questions:

  • Why do organisations participate with the Linux open innovation community?

Determining the why of participation leads to the second research question.

  • How do organisations participate with the Linux open innovation community?

We expect these patterns to be varying as members balance commercial and community responsibilities and knowledge sharing at the interface between the participating organisation and the Linux open innovation community (Henkel 2006). We investigate how organisational decisions determine and are determined by participation with the Linux open innovation community. This understanding can act as a roadmap for both organisations considering open innovation communities as a viable systems development option and researchers seeking to expand organisational theory around open innovation community participation.

In addressing both research questions, we investigate the growing research streams associated with open innovation communities. As open innovation communities represent an emerging and fast growing consideration for organisations, it is incumbent on practitioners and researchers to better understand this domain and to learn how the findings apply to a generalised study of open innovation communities.

2 Open Innovation Communities

“Whenever possible, design the system to run with open content, on open protocols, to be potentially available to the largest possible number of users, and to accept the widest possible range of experimental modifications from users who can themselves determine the development of the technology.”

  • James Boyle (2006) quoted in The Cultural Significance of Free Software (Kelty 2009)

Open innovation communities have clearly reached a business-critical tipping point as organisations strive to better understand them in order to participate with them (von Hippel and von Krogh 2003; Fitzgerald 2006). Open innovation communities have become media darlings, garnering considerable recognition and success. Linux continues to make strong gains as a viable business option (Kelty 2009). Twitter’s market cap has surpassed $1billion in 2009 as reported by The New York Times. Flickr claims over four billion images and Wikipedia over 16 million articles as reported on their respective Wikipedia pages. These are all tremendous successes where openness and adaptability are valued over management and control (Kelty 2009). In these cases, coordination, contribution and compliance in open innovation communities become the processes of design for new and emergent systems. Organisations must look to balance their knowledge of property, their styles of management and their notions of control within open innovation communities made up of non-developers, casual participants and corporations. This balancing act is not an easy task in this apparent “Wild West” of development, but it is a necessary one in order to participate in open innovation communities and leverage their advantages.

Many open source research publications have focused exclusively on a single open innovation community and not its interface with participating organisations. For example, Sowe et al. (2008) examine knowledge sharing internal to the Debian open innovation community and Kuk (2006) explores interactions within the KDE open innovation community. In each of these cases, the focus is on the open innovation community itself and not the relationship between the open innovation community and organisational participants. This is an important point, as our aim is to squarely examine why and how organisations participate in open innovation communities; therefore, our chapter is positioned at the interface of participating organisations and existing open innovation communities. To address this, we provide an iterative process of literature investigation and applied considerations as the research team members represent both academe and practice regarding organisational participation with the open innovation communities.

Through the research questions we consider all participants in an open innovation community to be of equal importance and do not predetermine organisations to be better or worse participants. We aim to understand why and how they participate in open innovation communities and issues associated with the critical requirements, motivations and challenges of participants. In doing so, we assume that the ecosystem of an open innovation community supports a variety of participants and that quite likely, a vibrant ecosystem needs much variety. In the next section, we introduce action research as an important approach for contributing to these goals, using it to frame our quantitative field study of organisational participation in the Linux open innovation community.

3 Research Approach

We apply action research as a methodological approach within which a qualitative study is conducted (Chiasson et al. 2009). Action research allows us to specifically address practice and research cycles, providing critical structure in defining our project. Action research supports our dual goal of developing a solution to a practical problem which is of value to the people with whom we are working, while at the same time developing theoretical knowledge of value to a research community involved in research and pedagogy (Mathiassen et al. 2009). A dominant approach of action research is used to frame our study within which other, more localised research methods are applied (Chiasson et al. 2009). Action research requires specification of an area of concern under investigation, a problem-solving context, research frameworks, problem-solving and research methods and their respective contributions (Mathiassen et al. 2009). Table 3.1 highlights these action research elements and their application in our project.

Table 3.1 Action research elements (Mathiassen et al. 2009)
Full size table

Action research was used to achieve two outcomes. First was a developmental round of data collection to establish grounding for the project. To achieve this outcome, the investigation was rooted in practice, not academe, to foster a strong problem-solving connection. Rooting in practice provides an opportunity to embed practical concepts from the Linux open innovation community into our researched areas of concern. A similar approach was used by Davison and Martinsons (2002) to investigate how the practical use of GSS could inform organisational culture. As such, industry participants were interviewed regarding the broad issues of why and how organisations participate in open innovation communities. The primary outcome associated with this phase of the action research was the development of the interview questions. In all, three organisations were involved in the development of the interview questions, iterating over the course of 6 months. The interview questions have a strong practice orientation, and their high applicability to a variety of open innovation community participants provided traction for our second outcome.

The second outcome of the action research approach was to discover the characteristics associated with why and how organisations participate in open innovation communities. Interviews with members of participating organisations were conducted in the execution of the interview questions. Participating organisations were identified through personal contacts, Linux Foundation membership and online media. Each interview lasted approximately 1 h depending on the depth of the answers. To date, 15 interviews have been performed and analysed thematically. The interviewees were both developers and managers directly associated with Linux open innovation community participation. The 15 interviewees represented 9 different organisations, all rooted in the technology industry.

Evidencing participation within the Linux open innovation community provided a mechanism for generalising from descriptive observations to our studied areas of concern (Lee and Baskerville 2003). Generalisation from the Linux community to a similar community (see the Apache community) was not done as community-to-community comparisons can prove problematic. Instead, we generalise to our within-case areas of concern (Lee and Baskerville 2003). The findings constituted the progression through one action research cycle. Through this cycle, we grounded our project in the practice of the Linux open innovation community and we engaged academe in the dissemination of our findings to the aforementioned areas of concern (Brown and Duguid 1991; Wenger 1999; von Hippel and von Krogh 2003; Chesbrough 2003; Neus and Scherf 2005). The findings represent the first phases of a long-term research project to engage organisations and provide tractable findings to better understand and describe organisational participation in open innovation communities.

4 Why Organisations Participate in Open Innovation Communities

Open innovation community participation is not a solution to all design and development projects. However, open innovation communities and their supported leverage, economics and flexibility represent viable approaches to why organisations participate (Fitzgerald 2006). Table 3.2 provides illustrative quotes from our interviews based on why organisations participate in the Linux open innovation community.

Table 3.2 Why organisations participate in open innovation communities
Full size table

Open innovation communities provide flexibility and adaptability as a real option through this fundamental principle: we all give a little; we all get a lot. This has the benefit of enabling “leveraged design” of a system that has shared value for all participants. A system is built through a model where design and development are leveraged through participants, value is provided for all and prediction, planning and control are the domain of an open innovation community.

4.1 Leveraged Development and Support

With the leveraged development model, systems can be developed through the “leveraging” of the open innovation community where participants contribute portions of a completed system (von Hippel and von Krogh 2003). A complete system can be developed by leveraging the rest of the open innovation community. For example, the Linux open innovation community can develop “5/6ths” of the Linux kernel to a new chipset. A single organisation must then only contribute the remaining “1/6th” of development costs to produce an artefact that they, as well as the rest of the community, can benefit from. The complexities and costs of developing are distributed throughout the open innovation community, not a single organisation, where all organisations play crucial roles in providing a leveraged development model (Fitzgerald 2006) (Fig. 3.1).

Fig. 3.1
figure 00031

Leveraged development model

Full size image

Participating organisations also leverage the open innovation community for support. Organisations aim to have their contributions to the community accepted and subsequently released in future versions of the Linux kernel. This allows the original, participating organisation to receive support from the open innovation community through testing, bug reporting and patches to the contribution. Organisations are also able to leverage the Linux open innovation community when entering third-party contracts. A contracted organisation can perform development work for an organisation that is not a community participant. A contracted organisation can then actively participate with the Linux open innovation community, aiming to have contracted work accepted upstream. In doing this, they are able to return successfully contracted development work back to a client, while shifting support to the Linux open innovation community. The consultant becomes “free and clear” of the maintenance of the contribution, while at the same time maintaining their own strong citizenship within the open innovation community.

In both leveraged development and leveraged support, organisations are responsible for maintaining compliance with the open innovation community. Compliance includes social interaction and expectations of participating in the community and also includes the more pragmatic licence compliance. The Linux open innovation community is primarily compliant to the General Public Licence (GPL) which defines the rules of engagement. Compliance includes organisational responsibilities for providing authored source code to defining code authorship. In all cases, organisational costs are incurred in how to maintain compliant participation within the community.

4.2 Economics

Open innovation communities represent a shift in how systems are designed and developed (Neus and Scherf 2005; Kelty 2009). The economics of open innovation communities have been well established in literature (Henkel 2006; Lerner and Schankerman 2010; Aksulu and Wade 2011) and include the free artefact costs often associated with open communities. The artefacts created in these communities (see Linux, Apache, Mozilla) are often a free and viable economic alternative to proprietary solutions.

In addition to the free costs of an artefact, it is widespread to consider open innovation community participation for developing and supporting systems used for organisational profit (see leveraged development). We have traditionally designed systems in proprietary ways, so why shift to an open innovation community model? The answer lies in the financial reality that the costs of developing an open innovation community are reduced as a result of the leveraged development model (“I pay for 1/6”). As such, the economics of participation also include reduced costs of development and support stemming from community leverage (Triole and Lerner 2002).

4.3 Flexibility

Participation in the Linux open innovation community is legally defined by the aforementioned GPL which accepts flexibility in how organisations participate. The GPL allows organisational participation to include differentiation and embedding of the Linux artefact to suit specific organisational goals and strategies. Flexibility is largely evident in embedded devices which are fuelling the growth of the Linux open innovation community. As specific and tailored computing devices become more prevalent in the form of television menus, navigation systems and router interfaces, differentiating embedded Linux has become a primary way to engage the Linux open innovation community and deploy the Linux artefact.

In adherence to the GPL, participating organisations are responsible for making a differentiated Linux code publicly available when a Linux-based system is sold for profit. However, organisations are not responsible for sharing the proceeds from the sale of the Linux-based system. The nuances of the GPL constitute a study in their own right. In our case, the licence flexibility of the GPL requires that participation with the Linux open innovation community balances organisational strategic and technical objectives with the necessary compliance imbued in the GPL.

5 How Organisations Participate in Open Innovation Communities

Once organisations realise why they should participate with open innovation communities, the following issue becomes how they should participate. Understanding the incentives to participate does not entail the knowledge of participation on a regular basis. Table 3.3 highlights the key issues of how organisations participate in the Linux open innovation community with illustrative quotes from our interviews.

Table 3.3 How organisations participate in open innovation communities
Full size table

As an organisation addresses how to participate, a sufficient argument must exist that compliance is a necessary part of participation with the open innovation community. As an example, a team may receive pushback regarding a contribution because the organisation does not want to expose the nature of particular intellectual property as a key differentiating factor in selling a product. The team must successfully demonstrate the leverage and financial benefits and the legal necessity of contributing changes. For an individual organisation, it is a balance of intellectual property, community compliance and organisational gains realised from participation in the open innovation community.

5.1 Contributions and Differentiation

Open innovation communities require the commitment of participants dedicated to common goals. Commitment as contributions comes in a variety of forms. Contributions are the degree to which participants supply committed changes to a product (Lakhani and Wolf 2005; Crowston et al. 2006). Contributions are also the engagement with an open innovation community to share, trade, test and develop ideas (Wenger 1999). In the context of our research, we identified contributions to the Linux open innovation community as high contributions and low contributions. A high contributor is a participant actively engaging in the community by developing “1/6” in the leveraged models. A low contributor is a participant far less active with respect to contributions to the leveraged development model. Both types of contributors, high and low, are necessary in the ecology of open innovation communities as the goals and applications of open innovation community systems vary from participant to participant.

We also found organisational participation to be defined by the adherence to, or differentiation from the open innovation community. Differentiation is the degree to which participants modify a stable, publicly available product for specific organisational requirements. Differentiation requires participating with the open innovation community, understanding changes and differentiating a product away from the open innovation community. Differentiation does not have a zero cost (Wenger 1999); it requires internal development support from the differentiating organisation but is expected to cost consistently less than non-leveraged development. Like the contributions, differentiation is viewed in two forms: high differentiation and low differentiation. Low differentiators are participants engaged in ways generally prescribed by the open innovation community. As an example in the Linux open innovation community, chip manufactures could be low differentiating participants as their processors should work with the largest, most stable release of the Linux kernel. High differentiators are participants engaged in specialised and tailored ways that are not necessarily in compliance with the majority of participants. As an example, manufacturers of embedded devices may differentiate a product in the development of tailored or customised devices specific to organisational strategies. High differentiating participants create new or “forked” systems that are quite different from their open innovation community. Table 3.4 presents a matrix of contributions and differentiation.

Table 3.4 Contributions and differentiation
Full size table

5.2 High Contributor/Low Differentiator

High contributors/low differentiators supply contributions that are compliant within the respective open innovation community. They can be paid as IBM employees or volunteers contributing to the Linux kernel (Lakhani and Wolf 2005). High contributors/low differentiators have the ability to help define and maintain a strategic roadmap for the open innovation community. They focus on lowering overall community development costs, improving system time to market and increasing the adoption of the system for a broad public. As a high contributor/low differentiator, effective communication, strong external relationship management and internal organisation structure for fostering contributions are expected (Gambardella and Hall 2006).

5.3 High Contributor/High Differentiator

High contributors/high differentiators are contributors yet choose to differentiate their application of the common or “mainline” system. This is done when a mainline system is applied in a system-specific manner with knowledge concentrated and applied strategically within the organisation. High contributors/high differentiators are active participants in their open innovation communities to maintain an understanding of community processes and future integration in an existing organisational innovation stream. Like the high contributors/low differentiators, the high contributors/high differentiators are interested in lowering development costs and improving time to market. They are also interested in differentiating in an otherwise commodity market and maintaining ties to an existing innovation stream to work with skilled individuals for internal design and development needs (Gambardella and Hall 2006). Challenges for high contributors/high differentiators come from earning and maintaining trust with the open innovation community and communicating and aligning the internal and external motivations associated with the respective system of the open innovation community (Henkel 2006).

5.4 Low Contributor/Low Differentiator

Low contributors/low differentiators do not actively contribute to the open innovation community, but mainly participate by viewing the open innovation community in a commodity-like role, considering the community responsible for the design and development of systems to run on top of or underneath a private solution. Perhaps in working with the “mainline” system of the open innovation community there is a potential for contributions through testing and use, but the overall participation is limited. Low contributors/low differentiators have a heavy reliance on industry standards and organisational product innovation is driven from elsewhere in the value chain (Henkel 2006). The low contributor/low differentiator is a common role for organisations as the open innovation community supports a broad range of solutions with little internal effort; “a rising tide floats all boats” irrespective of their role within an open innovation community. Rightfully, the low contributors/low differentiators have little influence on the open innovation community design decisions and much less opportunity for specialisation within the community.

5.5 Low Contributor/High Differentiator

Similarly, low contributors/high differentiators do not contribute back to the open innovation community in a consistent way. They differentiate the mainline system of the open innovation community, creating a black box around the new, differentiated and private system. Instances could include the need to build systems or services with very specific needs, but this comes at the expense of having to singularly maintain the differentiated or forked system and sacrificing much of the leveraged development model (Neus and Scherf 2005). At a minimum, low contributors/high differentiators must adhere to the open innovation community GPL licensing requirements. The low contributor/high differentiator is a model for embedded applications and can result in major competitive advantages, using the open innovation community as a launch pad for the differentiated system. It is difficult for the differentiated consumer to create a strong image within the open innovation community, and maintaining and synchronising parallel lines of similar systems can become onerous and expensive.

The aforementioned participant types regarding contributions and differentiation are community-based perspectives on how organisations participate with open innovation communities. Within an organisation, how questions remain regarding the more pragmatic, daily relationships with an open innovation community in the management of property, knowledge and power, leading to the second issue of organisational compliance with the open innovation community.

5.6 Compliance

Compliance has been alluded to as a characteristic of why organisations participate in open innovation communities. Henkel (2006) provides an examination of managing intellectual property through organisational licensing and contracting, illustrating complexities of the process. Complying with the GPL to effectively participate with the open innovation community has the aforementioned advantages of leverage, economics and flexibility. However, with compliance come certain risks of exposing intellectual property. Organisations require compliance considerations when participating with the open innovation community. These include both technical and legal considerations. First, technical considerations consist of solutions that the open innovation community could benefit and include new drivers or improved kernel performance. In these cases, the hurdle of compliance is relatively low as the contributions are primarily in support of the leveraged development model. Technical considerations also include contributions that must be made available to the community when the use of the Linux kernel is for organisational profit. In this, the GPL requires that specific guidelines be followed: display of appropriate copyright and warranty notices and a record of the differentiation from the original Linux kernel.

6 Discussion

The findings from this research contribute to our areas of concern within our specific study (Lee and Baskerville 2003). We speak to open innovation community participation as one of strategic motivation, seeking to leverage the community for organisational benefit (West and Lakhani 2008). From our findings, we draw two conclusions regarding organisational participation in the Linux open innovation community: conclusions of deference and distinction.

Participation remains an organisational decision of leverage, economics and flexibility, but the nature and design of organisational participation in the open innovation community is influenced by the community’s history and technical meritocracy. Being a participant requires organisational learning to understand the combined nature of organisational needs and design of the community being participated with (Brown and Duguid 1991; Wenger 1999). As highlighted in the following interview quote, deference is paid from a participating organisation to the community:

The [Linux] community favours good code over bad code. If you work yourself into the web of trust over time and you produce code, your code will go in. It doesn’t make any difference if you’re from [a large technology company] or a high school student in Bulgaria. Initially there was a worry that the community would disfavour companies/corporations, that wasn’t true. The community, we talk about it as a meritocracy. It’s an imperfect meritocracy, it’s filled with human beings, but by and large you get fair treatment and even treatment if you’re at a company and it depends on the code. You write good code, you’ll get it in; you write bad code, you won’t get it in.

Deference to the community is a necessary, learned consideration in organisational participation when engaging the open innovation community. Additionally, deference is paid from a participating organisation to the GPL or similar open source licences:

If we want our code to be accepted, you’ve got to write the code in the licence the community uses whether it’s GPL, or Mozilla, or APACHE, or whatever. The senior executives said that makes a lot of sense, so therefore, if we’re going to do Linux we have to be able to provide GPL code. Therefore, legal [had to] figure it out, which they did. But the key notion is there, that you have to use the licence that the community uses and that’s part of adapting to the community.

Under the GPL, deference is to the legal structure that, in part, defines participation in the open innovation community. Deference to the licence requires continued organisational learning around the legal aspects of participating in the Linux open innovation community (Brown and Duguid 1991), but the GPL also provides an avenue for distinction.

The GPL allows, and even encourages, organisations to create distinction within the community. In the findings, we identified four participant types as unique categories that define an organisation participating in an open innovation community. Distinction extends how we consider the participation types. It recognises that organisations are not solitary participants, residing in isolation, but are collaborative and contributive participants, part of their open innovation community:

[Flexibility] is certainly something that affects us more because we’re a high performance computing organisation. So it’s being able to allocate very large continuous and contiguous portions of memory for applications, and that’s actually one of the more successful areas where my organisation has been working with the community to push code back out to the general public, and it’s not necessarily a differentiation. It’s improving a portion of the kernel or a portion of the libraries that definitely affects us to a great degree but also has the added benefit of benefiting everybody else in the community too.

Distinction is evident through contributions to the community (benefiting everyone else in the community) as well as a differentiation of the Linux kernel (improving the kernel for high performance computing). Distinction highlights an appreciative approach towards an open innovation community, recognising that it takes all types of organisations to build a community:

Well, by definition, I mean there’s always a tragedy in the commons. So, yes, there’s bad code, people don’t know what they’re doing, people just going on this stuff and taking it, but I really think the deeper community, they just consider that it’s the cost of citizenship in a free society and in that free society of Linux development, so be it.

Distinction is also evident as organisations realise a change in their participation with the open innovation community. Distinguishing as a new participant type is not simply deciding to be a stronger contributor or a conscious differentiator; distinction is an organisation learning to involve the open innovation community as a new type of participant:

For a brief time [we] could have been considered [a free-rider of the community] because [we were] grabbing from the community any solution to get my project done and [we weren’t] contributing much at all. [We] did it because we had no budget and we really had a real good idea, and we could get there by reaching out to the community for some support. Ultimately when we were successful, we had no way of putting money back in, so the only thing that we could do was contribute back in and that converted [us] to being a contributor. Ultimately I think if you’re a constant freeloader and you’re not contributing back, pretty soon your ideas are going to run amuck and nobody’s going to help you and you’re going to be going down a path of burnt bridges and roads to nowhere. For the people that do turn around and start contributing, all of a sudden the user forums and the open source environment becomes a garden to kind of walk around in freely, and I think that we’ve kind of gotten to that point.

Distinction was seen to vary and evolve from the contributions and differentiation that can establish an organisation as a unique participant within the open innovation community. Finally, distinction can be applied outward, away from the community, to the marketplace that an organisation is a member of:

Something we definitely espouse is that we are involved in open-source and open-standards. It somewhat differentiates us in the marketplace. We embed Python interpreters in our product so that people can write their own controls, we publish our control protocol, we use open sound control, we work IEEE groups for open-standards, and Linux fits right into that. So it’s a whole package in which Linux plays a very large part.

We do not provide a precise mapping of how deference and distinction precisely relate to the findings of why and how organisations participate in open innovation communities. We expect participation to vary across organisations and communities, and prescription is premature. Participation in the Linux community is not likely to be the same as the Apache community as leverage, economics, flexibility, contributions, differentiation and compliance vary. As such, the evident deference and available distinction will also vary. This does not preclude us from drawing more generalisable and transferable conclusions based on our findings (Lee and Baskerville 2003). We believe organisations can facilitate, and even accelerate, their learning for successful participation in open innovation communities. The evolution of organisation participation in open innovation communities is actively unfolding and this domain is far from understood, in spite of the considerable research done in this area to date (Aksulu and Wade 2011).

Practical Tip

Organisations participate in open communities for reasons of leveraged development, cost savings and improved developer flexibility. However, knowing why an organisation participates in open communities is only half of the equation. Organisations must also consider how they participate through contributions to the community, compliance with the community and differentiation from the community. Realising these issues can aid organisations in future open community engagements.