The Emergence of Openness in Open Source Projects: The Case of openEHR

The meaning of openness in open source is both intrinsically unstable and dynamic, and tends to fluctuate with time and context. We draw on a very particular open source project primarily concerned with building rigorous clinical concepts to be used in electronic health records called openEHR. openEHR explains how openness is a concept that is purposely engaged with, and how, in this process of engagement, the very meaning of open matures and evolves within the project. Drawing on rich longitudinal data related to openEHR we theorize the evolving nature of openness and how this idea emerges through two intertwined processes of maturation and metamorphosis. While metamorphosis allows us to trace and interrogate the mutational evolution in openness, maturation analyses the small, careful changes crafted to build a very particular understanding of openness. Metamorphosis is less managed and controlled, whereas maturation is representative of highly precise work carried out in controlled form. Both processes work together in open source projects and reinforce each other. Our study reveals that openness emerges and evolves in open source projects where it can be understood to mean rigour; ability to participate; open implementation; and an open process. Our work contributes to a deepening in the theorization of what it means to be an open source project. The multiple and co-existing meanings of ‘open’ imply that open source projects evolve in non-linear ways where each critical meaning of openness causes a reflective questioning by the community of its continued status and existence.


Introduction
The notion of openness is far removed from the binary condition that the idea of open versus closed implies.We have grown to appreciate how openness is a case of degree or intensity.The question posed by West (2003) of "how open is open enough?" still remains very relevant today.Some studies put great stock into defining the openness of software by explaining its adherence to an OSI approved licence (Stallman, 2009;Stewart et al., 2006), while others see openness in relation to its capacity to create innovation (Boudreau and Lakhani, 2015;Chesbrough, 2007).As such, different interpretations of 'open' perform different functions, for example, ensuring the continued existence of an alternative mode of production (Kelty, 2008).The interpretation of what is 'open' can cover multiple meanings so to reduce open source to a binary conception in information systems and socio-technical objects doesn't do justice to the complexity of it.Thus, literature has attempted to treat 'openness' and its various forms by considering how open the process of development is (Shaikh and Vaast 2016); the changing governance of the project (O'Mahony and Ferraro 2007); openness of the tools used in the larger development project (Cornford et al. 2010); access to metadata of the code (Cornford et al. 2010); how developers become a part of the community (Fitzgerald and Agerfalk 2005); and even the level of aggression shown towards fellow community members during debates (Nafus 2012).Additionally, the meaning of openness is not necessarily antonymic to that of closed.As Shaikh and Vaast (2016) suggest, there are privileged folds where work is carried out in enclaves that allow participants to participate more freely than they would have been able if they had been under public scrutiny.
Questions of openness are not restricted to the open source world.Research in areas of crowdsourcing (Afuah and Tucci 2012;Boudreau and Lakhani 2013;Feller et al. 2012;Piezunka and Dahlander 2014), crowdfunding (Beaulieu and Sarker 2015;Belleflamme et al. 2014;Davidson and Poor 2016;Gleasure 2015), and open innovation (Alexy et al. 2013;Felin and Zenger 2014;West 2003;West 2006) more generally reveal that we have yet to understand the optimum conditions of participation and inclusiveness.What further motivates our study is that the world of practice is only beginning to negotiate how crowds and contests function, and there are more failures than success stories (Schenk and Guittard 2011;Ye and Kankanhalli 2013).Part of this stems from managers still being unable to grasp how to formulate the problem of open participation, but it also has much to do with the related issue of how to assess and implement solutions that arise from open participation (Felin and Zenger 2014;Piezunka and Dahlander 2014).Which crowd should be trusted, how open to make the contest, when to make it open, and how to manage the crowd without showing too much control, are all questions linked to the openness of the process.These questions are far from easy to answer for practitioners and scholars alike, which encourages us in this work to make better sense of openness and how it is articulated in the field.
Specific to the open source domain, the idea of openness has developed over time.The Free Software and Open Source Software (FOSS) movements have evolved over time, and moved apart from each other (Raymond, 1999;Stallman, 2009).These works accentuated openness as an essential way to improve software quality, and as an existential necessity of sharing knowledge between programmers (Kelty, 2008).Some of these original works have gained a mythical status in the open source world (Coleman, 2012), but almost three decades later FOSS has changed greatly and triggered change in other domains.In this work we want to engage with ideas of openness where we are keen to make sense of how an open source project evolves over time and reinterprets the meaning of openness as a community (the latter of which also undergoes considerable change over time).The research question that drives our study is: How is openness understood in open source projects and why does it evolve?
The nature of our research question has led us to conduct a single, in-depth qualitative case analysis.Our findings reveal that openness is a multiple idea which evolves across the span of a project.
The main contribution of this paper is an understanding of the two different processes -maturation and metamorphosis -that we found to give rise to multiple interpretation of openness within the same project.Both processes are separate yet entangled, and become visible through the crises that the openEHR project experiences.
In the next section we trace ideas of openness through literature; we then describe our methodology and move onto a description of our case study, openEHR.This is followed by our findings, after which we provide our conceptualization of how an evolved understanding of openness emerges within a project.We end with a section on our implications for literature and conclusion.

Literature Review
For the purpose of this research we define openness of open source as the (evolving) underlying shared philosophy of inclusive and transparency-inducing characteristics of license, governance, process, practices and membership.The aim of our paper is to understand if and how the idea of openness mutates within one specific open source project and why such change happens.Studies at a more macro level have reflected on how there have been shifts in free software towards open source ideas and how this is related to a need for pragmatism rather than ideology (Barrett et al. 2013).There is conceptual literature on how openness has been negotiated by companies (Dahlander 2007;Dahlander and Magnusson 2008;Deodhar et al. 2012;Morgan and Finnegan 2014;Spaeth et al. 2015;Tullio and Staples 2014;von Krogh et al. 2012;West and O'Mahony 2008), and how this has led to an enriched mutual understanding between companies and communities (Dahlander and Frederiksen 2012;Dahlander and O'Mahony 2011;Dahlander and Wallin 2006;von Hippel and von Krogh 2003).What has yet to be explored is how a community mutates over time where different influences -both internal and external -build a new understanding of the evolving nature of openness and its implications for the project.
Open source, and the multiple ideas of openness that it conjures up have seen substantial research.These studies span multiple projects in search of overlapping characteristics of openness (Capiluppi et al. 2003;Gacek and Arief 2004;Krishnamurthy 2002).Some have focused on the legal aspects of what it means to be open (Fitzgerald and Bassett 2003) while others have a mostly technical understanding of openness (Wang and Wang 2001).These studies belong to an earlier period of research that looked for stable characteristics that implied openness across multiple projects or within specific projects; the goal being to understand how open source development was done and how projects legitimated openness by being a rational choice that could objectively lead to higher quality software.
An exemplar of this early concern to define openness as a stable notion is Gacek and Arief's (2004) study that created a taxonomy of open source features.The study suggested that the two common factors across 80 open source projects were the need for an OSI-approved licence and that the developers also be users.Although such taxonomical studies are useful to set a basis for further discussion, authors have shown how variable the interpretation of openness in open source projects can really be (Coleman, 2012;Kelty, 2008).
As a basis for our paper, we identify four streams that tackle the idea of openness in different ways (see Table 1): mythical hacker accounts, essentialist ideology, managerial accounts, and pragmatic innovation involving forms of co-production.Three of these belong specifically to FOSS, while the last one discusses how openness has been understood within open innovation.
Mythical hacker accounts of openness form a unique stream in open source because they were for the most part written by hackers themselves, and became the trigger for FOSS movements some decades ago (Raymond, 1999;Stallman, 2009).They were vital in building our understanding of open source development and methodologies in practice (Feller and Fitzgerald 2002).These initial accounts were positioned as a stark comparison point to traditional software development where a project was either open or not, but degrees of openness were not questioned (Kogut and Metiu 2001;Ljungberg 2000;von Hippel 2001).Other mythical hacker accounts of openness have also looked at the historical evolution of the economics of FOSS (Ghosh 1998;Lerner and Tirole 2002), license changes (Edwards 2005;Scacchi and Alspaugh 2012;Ven et al. 2008), and development changes (Bezroukov 1999a;Conlon 2007).A common theme throughout these accounts is the need to legitimise openness as a viable form of software production and a competing alternative to closed-source software.As such, the view taken on openness often gains a mythical status that echoes their early articulation that sociotechnological objects should be open.Hacker accounts have become a historical reference that gives FOSS a way to evolve from its rich past and adapt to tackle contemporary issues such as access to infrastructure (Corsin-Jimenez, 2014).

Mythical Hacker
The hacker account stream treats openness from a mythical perspective that established open source as a viable alternative to closed-source software.These accounts build incrementally on the early accounts of FOSS and adapt them to contemporary challenges.(Behlendorff 1999;Bezroukov 1999b;Dinkelacker et al. 2002;Feller and Fitzgerald 2002;Ghosh 1998;Kogut and Metiu 2001;Lerner and Tirole 2000;Lerner and Tirole 2002;Ljungberg 2000;Raymond 1998;Raymond 1999;Sharma et al. 2002)

Essentialist Ideology
The ideological literature defines openness as part of a wider network of beliefs.As such, openness is negotiated but holds a translatable common essence that can be applied from one open source project to another.There is little change in the notion of openness within a project.The differences in ideology from one project to another are associated with different project characteristics or culture.(Barrett et al. 2013;Campbell-Kelly and Garcia-Swartz 2009;Choi et al. 2015;Dedrick and West 2007;Feller et al. 2008;Kreiss 2011;Lakhani and von Hippel 2003;Stewart and Gosain 2006;von Krogh et al. 2012)

Managerial Accounts
This stream considers that openness needs to be governed, specifically those facets that are unique to open source such as its communities.Change in the notion of openness within a project tends to be linear and reflects incremental maturation of project ideas.

Pragmatic Innovation
The open innovation stream takes a strategic stance when studying openness.Many such studies look at the different conceptions of openness from different communities and their relation with firms.
A change in openness is usually the result of a hybridisation of 'open' into selective revealing of certain open source facets (e.g.community, code, or licence).(Alexy et al. 2013;Chesbrough 2003;Conboy and Morgan 2011;Dahlander and Piezunka 2014;Feller et al. 2012;Henkel 2006;Huston and Sakkab 2007;Morgan and Finnegan 2014;Saebi and Foss 2014;von Hippel 2005;von Hippel and von Krogh 2003;West and Gallagher 2006;West and Lakhani 2008) Essentialist ideological accounts of openness move beyond a mythological view and instead openness is viewed from the lens of an underlying belief system (Barrett et al., 2013), which can be negotiated (Choi et al. 2015;Stewart and Gosain 2006).The level of detail provided on different aspects of ideology like norms, beliefs, and values (Stewart and Gosain 2006) and their relationship to team size and trust conditions indicates how ideas of strong 'freedom' (and openness) could negatively affect cognitive trust.In this stream, openness is part of a wider framework that gives it meaning (e.g.forking is discouraged but not denied) (Stewart and Gosain, 2006).To find such 'essence', these studies tend to look for openness and its' meaning across a number of cases and derive categories of ideologies that can be measured against different cultural and psychological user and developer characteristics (Campbell-Kelly and Garcia-Swartz 2009;Choi et al. 2015, Dedrick andWest 2007).
Managerial accounts examine openness to find better ways to build and govern communities.
Managing open source communities is becoming more crucial so research has addressed this issue by looking to within community governance (O'Mahony and Ferraro 2007) but also to how value is created between companies and communities through better governance (Morgan et al., 2013).A small but growing body of work also questions just how much openness is needed to create an optimal governance model for different forms of joint problem-solving domains (Dahlander and Gann 2010;Felin and Zenger 2014).This stream tends to focus on communities, with a specific analysis of changes in governance, and thus deals with the idea of openness only indirectly through authority structures and their evolution (O'Mahony and Ferraro 2007).The evolution tends to be linear, often looking at the incremental maturation of governance structures and the tensions that characterize such a change.
Openness in such instances is one amongst a number of issues rather than the only or key concern being traced.
A large body of literature that speaks to the idea of openness comes from open innovation studies (Chesbrough, 2003).
Though not specifically open source the work in the area of open innovation often draws on cases and examples that are FOSS related (von Hippel, 2005).Indeed, the private-collective innovation model (von Hippel and von Krogh, 2003)  open data and beyond.However, as noted above we have yet to establish strength of understanding in how openness as a concept and idea evolves and matures over time within a project where outside interaction is controlled (to a degree).Our study focuses on this idea through an in-depth revelatory case study.

Methodology
To study the evolving interpretation of open source, we chose a revelatory case study-openEHR-an example of the transformed understanding of open source projects (Fitzgerald et al. 2006) where there is an increased hybridization of licences, business models, and community.In health care, the use of open source has only increased recently, because many providers and adopters prefer to remain with proprietary models (Marsan and Paré, 2013).As a late-comer to the adoption of open source, as well as the degree of separation that exists between the software world and clinicians, we propose the study of openEHR as a revelatory case from which to theorise the interpretation and articulation of 'openness'.

Case Background
openEHR (open Electronic Health Records) is an open source project that aims to create electronic health records, a key part of health IT systems (Dünnebeil et al. 2012) with interoperable EHRs (Lezcano et al. 2011).The interoperability of EHRs is one of the most challenging goals in health IT (Martínez Costa et al. 2011) featuring high on governmental agendas (Roy-Byrne et al. 2004;Salzberg et al. 2012).openEHR's solution is to create multi-dimensional ontological layers to semantically describe clinical concepts (Wollersheim et al. 2009).These descriptions participate in the technological organisation and diffusion of knowledge within health information systems (Nickerson et al., 2012).Since they define and classify semantic knowledge, such systems can contribute to the interoperable exchange of information by developing compatible model representations of information as abstracted concepts, which can later be exchanged and interpreted by machines (Soguero-Ruiz et al., 2013), even if the machines follow different standards (Berges et al., 2012).Following from increased interoperability, ontology-based information systems hold promising expectations to be more amenable to complex queries (González-Beltrán et al., 2012), along the patient's medical history (McMurray et al., 2015), and become less susceptible to change (Wang et al., 2014).In other words, descriptions that need to hold clinical meaning and are not fixed to terminological descriptions of pathologies, which is especially important in the health domain where the changing interpretation of concepts is commonplace (Mol 2002).
The way openEHR is able to create semantically-valid clinical concepts is by assembling layers of blocks of information together.openEHR provides the building blocks to define a meaningful concept such as 'blood pressure'.An archetype is such an assembled block and is responsible for maximising the expressiveness of the clinical concept (Atalag et al. 2011).An archetype is assembled from elements belonging to a lower level of abstraction (called the reference layer) which defines, for example, the systolic or diastolic measurements of arterial blood pressure alongside contextual data (e.g.sitting down, laying with left-tilting).These values and data are themselves blocks of assembled information that define the measurements they can provide to higher-level concepts (e.g.defining pressure units in the range of 0.0 to 1000.0 mm[Hg]).It is hoped that this multi-layered approach will allow EHR systems to be interoperable (Isern and Moreno 2016), where other approaches resulted in mitigated results (Wollersheim et al. 2009).The blood pressure archetype is designed to represent a coherent unit of observation that will, when put together with other archetypes, come to form a patient's medical history.The consultation of a pregnancy, for example, will lead to the observation and recording of several other archetypes such as past pregnancies, vaccine, blood type, or fetal movements (Pahl et al., 2015).These building blocks provide different scales of abstraction that ultimately form concepts that map with world entities that would allow clinicians and health researchers to link otherwise disparate knowledge bases (e.g.biology, pathology, genomics, clinical practice) to allow global queries (González-Beltrán, 2012, Nickerson et al., 2015).
By and large, openEHR is a requirements project since it aims to map world entities into machine specifications (Jackson and Zave, 1995).In addition to requirements and specifications, however, openEHR also develops software that parses and validates the use and definition of its clinical concepts.In this sense, openEHR bridges pure implementation software by 3rd parties by providing open source implementable clinical concepts that are computationally-validated.The choices taken by openEHR will thus influence other open source projects down the line (Christensen and Ellingsen, 2015).For the sake of simplicity, the term 'clinical concept' and 'requirements' will be used as a replacement of the term archetype, an equivalence that health IT practitioners commonly make (Atalag, 2010;Pahl et al., 2015), when referring to artefacts that will define the purpose of the information systems; which is in turn, an intuitive definition of requirements used by software developers and computer scientists alike (van Lamsweerde, 2000).Such an abstraction is valid since an archetype represents the ideal and generalised embodiment of an abstracted clinical concept.
The openEHR Foundation was created as a non-profit in 1999 when the core members entertained the idea of an organisation that would develop the notion of interoperable health IT systems, a domain in which all the core members had already dedicated several years.Its principal goal would be to create rigorous clinical concepts that they saw as the necessary condition for EHR interoperability.
The core members decided, early on, contrary to the landscape then-dominated by proprietary solutions, to make the project open source.The direction of the project would be under the aegis of a Foundation Board composed of core members whose objective would be to set the first organisational structures in place.The first mailing lists, the announcement mailing list (AML), the clinical mailing list (CML), and the technical mailing list (TML) went online in 2002, on servers provided by University College London, the Foundation's parent organisation.The following years, and in line with its primordial goal of creating rigorous clinical concepts, the Foundation worked towards the creation of formal processes of definition and review under the control of two other boards.These would guarantee the quality and the soundness of clinical concepts, and thus legitimise them.
We argue that openEHR is a revelatory case (Yin, 2003), the study of which presents novel aspects regarding the development of open source projects.First, in contrast to many open source projects that tend to fail after their first iteration (Schweik and English 2012), openEHR is successful.
It is currently being implemented by Australia and Brazil (at the federal level across the country), and holds close ties to the NHS in the UK, as well as grassroots movements worldwide (e.g. the NHS hackday).Second, the project is also extremely formal with a great emphasis on rules, planning and hierarchy in its approach to development, resembling characteristics seen in literature (Fitzgerald, 1999).Third, openEHR also crosses the domains of health care and software development, which creates a novel mix of clinicians with software engineers -two widely heterogeneous groups with different agendas.Fourth, the project's core is not a software system, but an open source specification using a custom open source language and its interpreter.The clinical concepts described in the custom language form the kernel around which possible implementations may create different, albeit interoperable, interpretations.Implementations exist in Eiffel, .NET, Java, Ruby, and Python.In this sense, more than anything else, openEHR is a requirements project first, and a software project second.

Data Collection and Analysis
In this section we describe the very iterative process of data collection with data analysis that we undertook.Data collection started as an exploration into the use of requirements in open source projects.openEHR's objective is to formally define its requirements in an open way, yet, how such formality has come to exist did not seem settled.The data collection process happened along four phases (see Table 2), which reflects the iterative nature of the data collection process (Eisenhardt, 1989).The  (2002)(2003)(2004)(2005)(2006)(2007)(2008)(2009)(2010)(2011)(2012)(2013)(2014)(2015).
Phase 1: Starting in 2009, the first phase of the research was used to confirm openEHR as a promising study with which to analyse ideas of openness, given the institutional backdrop that requires health IS to offer guarantees on safety.After the exchange of a few emails with a top-member of the project that showed interest in our study, a meeting was set up in 2010 in which an interview protocol was presented to him explaining the kind of data we required.The researchers followed a snowball approach and asked to be put in contact with key project members.Additionally, the researchers were granted a full disclosure of internal documents and the liberty to contact anyone to carry out interviews (including invitations to attend internal meetings); opportunities that were pursued as often as possible.
Phase 2: This phase consisted of formalising the interview guide.Questions were drafted and key members of the project were interviewed (see Table 3), some through snowballing, while others were contacted directly by us.At the same time, a first-attempt at tool-supported codification took place of two of the mailing lists, CML and TML, covering the years 2009 and 2010, and we conducted semistructured interviews.Systematic coding was carried out using grounded theory methods (Charmaz 2006; Urquhart 2012) (more details below).This specific coding was limited to the years 2009-2010 of both the TML and CML (2074 emails).These two mailing lists are openEHR's main working platform where people ask questions, coordinate, discuss project progress, argue for change, call on the board for specific queries, etc.The TML is specific to the technical organisation of the project and how clinical concepts should be described (e.g. the processes of development) are discussed.
The CML deals with the more clinically-oriented aspects of clinical concepts, such as invitation for review rounds.In both these lists, core, active, and potential new members participate, but a vast majority of the emails written come from core and active participants.Both core and active participants may be individuals, or part of an organisation (e.g.Linköping University).While core members have a formal relation to the openEHR Foundation, they may not necessarily be active in the mailing lists.
Active members have no formal ties, but are recurrent participants to the discussions throughout the years so that they may be considered to have achieved a certain status, evident in the way they guide newcomers who are in need of help.The participants are generally highly educated (e.g.software engineers, doctors, PhDs, researchers).It is also possible for core people to become active members and vice-versa.More recently (in 2012), a formal scheme of membership was adopted which explains various participation rights to the boards.Mailing lists however remain open to all.The data collected from these two mailing lists is precise, argumentative (especially after 2009), and open.This phase drew upon the themes that arose during codification.During this phase all the key project members and the community at large were formally introduced to the first author through the community news website.
Twelve interviews were carried out (2010)(2011).Of these, 9 were semi-structured and 3 unstructured, with 7 unique participants (active, core, or both).The 9 semi-structured interviews were coded systematically (see Table 3 for an illustrative example of coded data) and provided a reflective exposition of the members' understanding of the notion of open source.Phase 3: The themes that arose during the coding were discussed between the researchers.This process led to the emergence of agreed theoretical constructs that took into account unsettled phenomena emerging in the data in the form of a middle-range codification process (Urquhart, 2012).
It is also at this point that a decision was taken by the researchers to primarily focus on analysing the years 2009 and 2010.Two reasons motivated this choice: first, theoretical saturation and a desire to see any overlap/difference between the interviews and our analysis of the mailing lists.Second, the project members corroborated that these years represented a crucial period of change for the project, and thus, of controversies (Latour, 2005).Such triangulation of data strengthened our confidence (Yin, 2003).
Phase 4: In this phase we looked for additional data around particularly controversial phenomena.The programme used to parse every email and catalogue the 15 most controversial threads per year provided a holistic view of the increase of controversies and their subjects.The customised programme was coded by the first author to parse all the emails 2002-2015.This allowed us to have an overarching view of the TML and the main controversies that took place.The programme counted the number of emails per year, listed the 15 most controversial threads (by parsing and counting the subject of each email), and for every controversial thread, to output the number of exchanged emails (see appendix Tables 4 and 5).This gave us a quick feel of the position that open source took within the project and its evolution over time.Used in conjunction with the holistic search, we could compare the threads that discussed open source and 'openness' with the list of controversial threads to gain an overview of the evolving interpretation of open source.A controversy for this research was defined as any thread of conversation that created a sharp and large flurry of replies with regard to organizational and development issues.
A more holistic reading of the Announcements Mailing List (AML) (193 emails), for the period 2002-2015 was also carried out.These emails provided insights regarding the objectives and thoughts of the official, core members of the project, as well as contextual information (e.g. the launch of review boards).Some of the announcements represented turning points for the project and were reflective in nature (e.g.re-focus of the Foundation Boards' attention to the community).We specifically looked if they were corroborated by the TML and CML, and whether their perspective on 'openness' was shared by other members.

Theoretical Constructs
We believe the not-for-profit Foundation approach, with open-source licensing, to be the best and most sound way to approach our goal in health care.If there proves a better, more rigorous and effective way, we will be supporting it.
(May 4, 2004 (AML) • Need for rigour Right now I don't care about license issues, if we have problems in the future, we can just create our own testing archetypes and templates and go on with the development :D.About publishing, I think we need to discuss a little about how we will govern this repository, and how we will

Maturation of primordial concerns
The licencing that I think will occur will be as follows: ADL language definition document [the language to define clinical concepts] + language production rules (a bit more precisely produced than the ones I have included in this package)copyright to openEHR.The conditions of use are included below (and are very open as you can see).This copyright description was developed by the legal group of University College London; hopefully it is acceptable to all prospective users.(September 26, 2003 (TML) • License = open • Primordial concerns • Pragmatism Do you mean that your main worry is that you are afraid that somebody will take CC-BY-licensed archetypes from the openEHR-hosted repository, modify them a bit, and then redistribute under a less free license and start charging for it?Or do you have any other concerns that you can clarify?Won't your feared modified redistribution only be a problem to interoperability if, all the following comes true: a) If users will really consider the "commercial" versions to be a lot better than the openEHR-hosted versions and are willing to pay for something they used to get for free.b) If the adaptations, if found useful by openEHR, are of such innovation height that the modifying company can claim copyright/patent on the changes and somehow block openEHR from incorporating similar features in their revised archetype versions.(October 13, 2009 (TML)

engaging with open
Let's say there are ten emergency departments in ten different countries, and they all want to use [clinical concepts], are you going to say that they can't make changes until the international organisation say they can make changes?That's not going to work, so you're going to have to allow some peer to peer sharing of good quality

Metamorphosis of openness through implementation
[W]e must support and encourage regional OpenEHR communities, specs translation, and "open source multilingual up-to-date tools" (most tools available are: or not multilingual or the translations are horrible, or not open source, or not updated recently).I think regional communities can create courses, resources, materials, etc... and share them with other communities, through OpenEHR foundation.Guidelines to do this must be set from the OpenEHR Foundation Boards (I think they are there to lead the community, to encourage the spread and adoption of the standard, I can't remember the last time I saw an email of the OpenEHR Boards in the mailing lists).( November Analysis across the email messages and interviews was carried out over various periods of data collection.At every stage of coding both authors made it a point to work together and on certain key occasions and controversies in the data set both authors coded separately and in parallel.The aim was to share notes and test the strength of conceptual development (Miles and Huberman, 1994).Subsequent meetings between the authors happened when the first author had also begun to notice certain patterns and relationships between the codes and themes (Urquhart, 2012).The authors met for a full day of joint coding and discussion to tease out the very intriguing ideas of openness, and its fluctuation over the project.What was noticeable at this point was our different yet equally valid interpretation of openness.Whereas the first researcher highlighted the conceptual building of rigour and the small accretions of change in openness, the second researcher could not ignore the more mutative leaps in openness that were evident on the implementation side.This led us to build our analysis around the evidence of two processes where we traced through association the ideas of openness that bound both processes together.These ideas of openness were written up as detailed memos (Glaser and Strauss, 1967) and became our theoretical observations (see Table 3).open source is that it begins to become a driver of change within the project.There are four particular themes that are representative of the evolving trend.First, the project consistently considers primordial goals (e.g.rigour of clinical concepts) to be paramount where rigour is conflated with openness.These goals may evolve and change slowly over time into maturity but they are of persistent relevance in openEHR.Second, till around 2009 'openness' is considered unproblematic because the project's perspective is that openness is something that relates to a choice of license.Third, the metamorphosis of the understanding of 'openness' is increasingly fractured and creates new project dynamics, such as growing project participation by encouraging local actors to contribute (this is particularly important for some core and active members).Fourth, coinciding with a push for more 'open' participation, the absence of an external actor that would help scale the project sets it off into a reflection on the importance of the community and its role.

Primordial goals do not explicitly include openness: openEHR is not only an open source project.
First and foremost, its goal is to create rigorous clinical descriptions to allow for health systems to be interoperable.This partly explains why initially a clear idea of openness is not used or defined in the project, and instead developers are more attentive to establishing primordial aims where the latter almost reflect a modicum of agnosticism towards any ideological leanings.On the rare occasions that 'openness' is discussed, it is in the context of their primordial goals.This suggests that open source is, instead of an ideological way of life, a 'tool' that is used to achieve rigour, and not as a way to understand the realities of health IT or de-centralised collaboration.A Foundation Board member, for example, writes in May 2004 on the announcement list that open source licences are only one way to enable openEHR's goals in health care and help provide (perhaps non-exclusively to other means) a rigorous way to achieve them: We believe the not-for-profit Foundation approach, with open-source licensing, to be the best and most sound way to approach our goal in health care.If there proves a better, more rigorous and effective way, we will be supporting it.
This message is representative of the discussions on the meaning of open source and the greater importance that other goals have throughout the life-time of the project.The TML repeatedly ties 'openness' to rigour, even when traditional concepts of open source are discussed in detail in the later years.The persistent and on-going maturation of such ideas means that they constantly appear and reappear on the TML across the lifespan of the project (and are on-going).Indeed, an active participant in 2012, for example, brushes off the minute description of possible licence choice, superimposing the idea of consistency and rigour in the development of clinical concepts: Right now I don't care about license issues, if we have problems in the future, we can just create our own testing archetypes and templates and go on with the development :D.About publishing, I think we need to discuss a little about how we will govern this repository, and how we will converge to a common and consistent set of artifacts for testing.
The interviews conducted confirm this representation of 'openness' in the service of other goals.The interviews explained in more detail that openness was not irrelevant to them, but was just not as central as ideas of rigour.However when these developers were asked to explain rigour their description included words such as 'consistent', 'clear', 'scientific' but when pressed to explain how this could be achieved they would often return to principles of openness.What was emerging was a conflation of rigour with openness where newly formed interpretations of openness were put in relation to the matured primordial goals.

Openness is equivalent to an open license:
In the first years of the project, open source seems to be understood as a simple fact that does not hold much complexity.When, for example, a question of open source does emerge the developers black box the issue by pointing to the chosen license.The mailing list provides clear examples of core members discussing 'openness' as a matter-of-fact that does not need unpacking.There is a cavalier presentation of the project's licence by a core member which suggests that discussion is not even needed (i.e."will occur... will be as follows... very open as you can see") where open source seems to be understood as a tool, thus it could not have complex interpretations.There is an evident change in early 2009 when a flurry of threads began to hotly debate the various licence choices and insisted that the Board offer an opinion on this matter.Openness can no longer be taken for granted and must be discussed.Active members of the project initiated a debate where openness began to take new shape.The " board of directors" were to weigh options between the specific licences of CC-BY and CC-BY-SA and to consider the impact of each to the community and potential users, especially with regard to the worry shared among core members of a hi-jacking of their prized, rigorous clinical concepts should they be promiscuously 'open': Do you mean that your main worry is that you are afraid that somebody will take CC-BYlicensed archetypes from the openEHR-hosted repository, modify them a bit, and then redistribute under a less free license and start charging for it?Or do you have any other concerns that you can clarify?Won't your feared modified redistribution only be a problem to interoperability if, all the following comes true: a) If users will really consider the "commercial" versions to be a lot better than the openEHR-hosted versions and are willing to pay for something they used to get for free.

b) If the adaptations, if found useful by openEHR, are of such innovation height that the modifying company can claim copyright/patent on the changes and somehow block openEHR from incorporating similar features in their revised archetype versions.
License discussions 2009 onwards span all the key mailing lists such as the TML, CML, AML, but also the wiki itself, with evidence of further discussion conducted over private channels, repeatedly summarising arguments made, outcomes of formal enquiries conducted by experienced lawyers, recounting personal experiences, and analysing differences with other actors.At the moment of writing, this discussion still arouses much interest from the community and core members alike in the TML.This increased questioning of open source suggests that it has grown in importance to become detailed and discussed, even if it remains as a support to the project's primordial goals.

New and complex interpretations of 'openness' create novel project dynamics:
The growing treatment of 'openness' as a complex notion pushes participants to give more attention to new and emerging dynamics, particularly a wider participation and the use of local movements to advance openEHR further.Something larger than openEHR is taking place here and is pushing the project into a more radical form of mutation -a metamorphosis of sorts.This push for a greater participant uptake is made approximately at the same time that the meaning of open source started gathering more scrutiny and interest by core and active members alike (2009 onwards).This put the evolving interpretation of open source in potential conflict with the primordial goals of rigour and discipline.One of the core members interviewed in 2010 problematized the situation in the following way:

Let's say there are ten emergency departments in ten different countries, and they all want to use [clinical concepts], are you going to say that they can't make changes until the international organisation say they can make changes? That's not going to work, so you're going to have to allow some peer to peer sharing of good quality [clinical concepts].
The wording is particularly interesting: "allow some peer to peer sharing" shows the tight grip and importance given to primordial goals and yet some slack is essential and even inevitable.The consequences of the potential conflict with rigour is visible here; if the matured ideas of rigorous clinical statements are fully engaged (e.g.complete central control of clinical statements), without accommodating some openness then the project as a whole could be at risk.At the same time, the core member uses an imperative "have to allow", otherwise the project will not work.This palpable tension summarises the predicament of the project that sees the intricacies of the meaning of open source and 'openness' become more complex, while at the same time, make the new meaning of open source accommodate the project's primordial goals that it has developed so carefully.The need to interrogate the idea of openness takes the members by surprise.The actual spur to such dynamics is in fact the real world development and implementation of software built upon the primordial goals, indeed an implementation that is beginning to give real shape to openEHR but also its fault lines.
Understandably, development and implementation needs created an imperative to encourage participation in the project.In November 2010 a thread called 'Why is openEHR adoption so slow?' initiated by a recurrent contributor asks the community and the board to take a pro-active role in the creation of local communities.This question follows from an increasing concern to attract peer participation and encourage local community engagement.It coincides with increasing prospects of implementation in hospitals and governments (these are local environments in relation to the international core of the project which, itself, is not situated concretely).This active contributor discusses open source in terms of local, grounded needs: [W]e must support and encourage regional OpenEHR communities, specs translation, and "open source multilingual up-to-date tools" (most tools available are: or not multilingual or the translations are horrible, or not open source, or not updated recently).I think regional communities can create courses, resources, materials, etc... and share them with other communities, through OpenEHR foundation.
In this sense, discussions around the concrete meaning of open source (e.g.'openness' means increased local participation) become a driver to further the development of the project, which in turn drives changes in the organizing of the project.New, and bolder interpretations of open source and 'openness' can be seen to emerge.One such interpretation even proposes a new type of clinical concept, an 'alpha' that may not hold as much rigour as the published, official ones.These would be developed in a different space from the rigorous, disciplined clinical concepts.The spatial separation indicates how the project articulates the metamorphic interpretation of openness stimulated by increased participation in a way that simultaneously fits with or even feeds the maturing goal of rigour.In 2011 talk of "incubators" of clinical concepts begin to appear.These incubators provide an entry level for quick Wikipedia-style drafts of clinical concepts where reviewers would give less stringent scrutiny.
The hope is that a more accessible platform would allow participants with less modelling skills to write a 'stub' that could later be written in more detail.
The idea of an incubator is suggestive of a concept closely aligned with 'open source-time', 'opened to collaborations' and "light" governance models.openEHR was now more than a rigorous concept, it had been converted into a concrete and tangible object for the members of openEHR to play with where 'openness' was questioned, interpreted and re-interpreted until solidified into code.

Openness is thus about open implementation.
Realization that openness must develop further with external support: A year after acknowledging the importance of openness in openEHR a possible partnership deal with a relevant player in the field of health systems fell through 1 .openEHR needed this player's support because the latter was a large established actor in the health systems world and could help scale openEHR quickly.
As a consequence, the board, via the AML, announced an important shift in direction.It was established that the community needed to re-focus its efforts on building strength and numbers to ensure its future: The Foundation wishes to acknowledge that the future success of/open/EHR now clearly lies in the hands of the /open/EHR community itself.The Foundation is therefore seeking support for an international meeting to define and establish a new way of working.The meeting will discuss ideas about how to progress the work of /open/EHR and ensure that more people benefit from it.
From then on, and in conjunction with the increasingly intricate interpretation of 'openness' (e.g. the creation of local communities), a more complex understanding of the role of the community and its relation to the project began to take shape.A plethora of emails in the TML and AML in the following years (notably in 2012 and 2014) discuss the meaning of an 'open' community and the variety of members needed to build a more stable shared understanding of openness.The community morphed from a homogeneous body into a complex tangle of "professional organisations, universities, and industry", where each had their own needs and views about IP and other Foundation assets.A "collaborative refresh" is called for where the entire community needs to participate in order to reevaluate the direction of the Foundation.Efforts and goals of academia and industry must somehow become aligned around the use of open source tooling to attract yet more participation and better implementation of the project.Openness is now understood more as an openness of the entire process.
The change of focus from the absence of an external partner reinforces the need to rethink ideas of openness and make openEHR more flexible to mitigate differences within and across the community.Different voting rights were now offered depending on the financial capability of each member.A feepaying individual (15€) could be a member of programme committees (responsible for various aspects of the construction of clinical concepts) and vote in them, while other types of member could not.An industry partner with a fee based on annual gross revenue has the ability to participate in the elaboration of certification criteria.Nonetheless, all of openEHR's IP remain accessible under a variety of open source licences, and anybody is free to participate in the community's collaboration tools.The meaning of open source has been given a complex, but concrete interpretation regarding various levels of participation and the rights and duties that these necessitate. 1The two organisations are now re-entering discussions of formal rapprochement

Emergence of Openness: The Intertwined Nature of Metamorphosis and Maturation
These findings offer two clear explanations of the intertwined evolution of the meaning of open source.On the one hand, a mutational process can be identified -the metamorphosis of openness; and on the other hand the data shows a more deliberate and gradual refinement of the qualities of clinical concepts -the maturation of primordial concerns.

Maturation of Primordial Concerns
Maturation is a process that involves small changes that are similar in nature and accrue slowly to create a stabilising form.This idea of maturation signifies the existence of a stable 'deep-structure' (Barrett et al. 2013) that changes slowly over time.This type of change is strikingly different to metamorphic evolution that alters the original form to an unrecognisable degree.Maturation, instead, invites change that seemingly improves or refines the original form, and does not transform the meaning intrinsic to that form.In openEHR, maturation takes place throughout the life-time of the project, but is particularly evident in the formative period because it triggers metamorphic evolution in the interpretation of 'openness'.During the formative period maturation reflects a focus on ideas such as clarity in aims and need for rigour and discipline.The elaboration of these concerns is almost at the expense of developing a deeper understanding of openness of open source and the various consequences that different interpretations of openness can have.The refinement of the ideas of rigour in the project is supported by the serial creation of formal review boards to ensure the consistency of clinical concept designs, while the meaning of open source held in a generic and abstract form and not allowed to percolate within the community at large.The findings suggest that the project is somewhat wary of the unknown capacity of open source and how it may conflict with its primordial, purpose-giving goals (von Krogh et al. 2012).
As such, the refinement of the meaning of 'rigour' over time builds a 'deep-structure' that helps to frame the debate according to demanding interpretations, including early attempts to understand open source.The primacy of other goals and their maturation might have been motivated (consciously or otherwise) by an essential desire: the framing of a 'deep structure' that could either reign-in the excesses of possible interpretations of open source and 'openness', or mould them into participating with the primordial goal of rigorous description of clinical concepts.In this sense, openness is interpreted as an 'invited guest' (Ciborra 1999) which has to accommodate itself within the rules of the host's house, even if these are in flux.The meaning of open source and how 'openness' should be interpreted are thus not independent of each other.Our analysis of the mailing lists provides evidence that openness was discussed at various stages with varying degrees of emphasis thus defying a linear explanation.The size of the controversies in which open source is involved, although part of an overall increase, do actually wax and wane over the years of the project (2012 and 2014 in particular).The qualitative analysis of discussions shows that the project frequently looks backwards and re-interprets it's understanding (Venters et al. 2014) and the decisions it has taken.For example, the issue of licence is constantly discussed and its role relative to how it supports or deters openEHR to be a 'true' open source project.Another example is the curious questioning of the project's confidence or detachment from the various local communities that emerged when openEHR considered partnerships to become an international body.The desire to internationalise sprung a move to localise and revise its internal governance.In this sense, it is unfair to qualify the movements as linear because they eschew much of the difficulty; the going forwards and backwards that the project and its participants underwent when significant changes took place, even though a broad direction may be largely visible.

Metamorphosis of Openness
The metamorphic process frames the project's turn from the formative to the problematizing period.
We understand the metamorphosis to be broadly three phases of mutation (which is still on-going), the agnostic pragmatic phase, the engaging with openness phase, and lastly, the stabilizing openness phase.
Each phase is indicative of a sharp mutation triggered by internal and external controversies (see Figure 1).Agnostic pragmatism dominates the formative time period of 2002-early 2009.What is evident here is how certain organizations that adopt open source ideas do so with little thought or perhaps even patience for openness, ideology, or any rulebook.The aim for openEHR was simply to get the project afloat and create something useful together and open source was an uncomplicated way of doing it.The license was not seen as problematic, made explicit or discussed in detail.In some places contradictory information on the coverage of IP was evident.However, 2009 saw a sharp change as openEHR became an increasingly visible project and gained traction.Open source became an explicitly problematic force put in relation with governance, IP, process, technical contributions and objectives (implementations, requirements, connection to local realities, and primordial goals).It was not gradual and it created a very different sense within the project -and yet it remained the same functionally.The project had the same goals but the metamorphosis of openness gave it potential to explore and achieve those goals.
Openness was suddenly thrust into centre stage and the community was forced to engage with it because ignoring it jeopardized the existence of the project.This fundamental moment of metamorphosis where mutation became blindingly evident and vital was the engaged openness phase.First, an essential mutation took place which was visible (a morphology of form), for example, the interpretation of open source became a key driver for the community and its heterogeneity became an explicit and constituted body.This newly constituted body held a new potential and a varied capacity of action: different members had specific voting rights; new spaces were created for the tinkering of 'alpha' versions of clinical concepts; various open source licences were studied repeatedly and their consequences for the project and participants were evaluated.
That the two forms, the early and the problematizing one, hold little resemblance does not imply discontinuity: just as the butterfly is the continuation of the larva, openEHR still cares deeply of its primary goal of defining rigorous clinical concepts2 .So it is with openEHR, only that the new evolution were not clarified and tied to the matured primordial goals, then it was at risk of being hijacked by a number of different actors (both commercial and non-commercial).These new actors could harm the goal of rigour and obstruct the potential for interoperability of EHRs.At the same time, core members were increasingly aware of the necessity for change and the attractiveness of certain concrete forms of openness (despite the apparent shape-shifting of openness).The clear maturity of rigour as a concept meant that the project could clarify and develop preferential understandings of openness that were stable and a good fit for openEHR.

Implications of the Intertwined Nature of Metamorphosis and Maturation
The two processes---metamorphosis and maturation---both come to articulate the meaning of open source differently.Indeed these processes offer two different ontologies, and this in part is their significance, which we disentangle analytically to show how they relate, and what implications they create for openness as a collectively emergent concept in open source projects (see Figure 2).Where maturation is about lots of small 'change(s) in things' metamorphosis concerns more grounded 'reifications in process' (Langley et al., 2013, p.4) where the actual (multiple) processes of implementation of code reflect long-term evolution.Figure 2  The fear of a possible 'hi-jacking' of the clinical descriptions leads core and non-core members alike to discuss the merits of tightening the amount of controls behind possible derivations.The maturation process of change tends to focus on the evolution of single interpretations that are refined and improved upon.It is precisely because openness has had little attention in comparison to the other concerns that its accommodation happened the way it did.For example, the space for tinkering clinical concepts is different from that in which published and reviewed concepts live.This suggests that the somewhat uncontrolled potential of openness in open source requires a different space of negotiation where it can encourage participation without obstructing the other, dominantly seated concerns that were so elaborately defined during the formative period.Perhaps if the interpretation of rigour had not had dominance over that of 'openness' they may well have shared the same description space.At the same time it is interesting to draw a comparison of openEHR with more traditional projects such as Linux or Apache where we also see a clear separation of versions of the same software where one is visible to the core developers as they tinker and change parts of it.This version is seldom available to the public, while another more frozen, publicly available one is open for public use.
Both processes become more visible in the case of openEHR through controversies that provide us with a window of access.Tracing these controversies we find that there are four different interpretations of openness beyond openness as implementation (e.g. as a tool) that circulate; openness is understood as rigour; openness includes increased participation; openness is open implementation; and openness becomes an open process.These interpretations of openness are the circulating references (Latour, 2005) between both processes and at the same time define and direct both processes as well.
By unpacking discussions and debates that arose we can see that while openness was debated on the one hand, it was coded and made tangible through implementation on the other (see Figure 2).Within and between these two processes openness is a moving, living idea that takes multiple forms and remains a multiplicity.Figure 2  Each participant draws on concepts in novel ways to build something innovative yet this novelty can erode the basic principles of strictly crafted projects such as openEHR.openEHR is a project that survives because of its legitimacy which in turn hinges upon precision, accuracy and detail.If the latter characteristics become muddied then openEHR may no longer be seen as an interoperable scientific system.
Openness is open implementation where different open licenses are weighed and considered.
Evaluating license options compels open source projects to make pragmatic choices that are necessary in the current period but allow the project to develop and grow in a healthy manner over time.The need to sustain open source projects means that ideology and practicality must be considered together where, depending on the long-term vision of the project one or the other must take a secondary position.The case of openEHR shows us that even in a healthcare project where building and using software was itself seen as a secondary issue pragmatics of opening up over time began to sway arguments of tight control.With growing interest in openEHR came different groups and communities each with their own vision and thus choice of license.Each implementation of software is different as is the context in which it is appropriated and used.Openness needs to be inclusive and encourage variation in license schemes or openEHR will not survive beyond heuristics.
Finally, openness becomes an open process over time in order to survive.Openness must bring with it openness-in-process because license alone cannot lead to an open implementation in open source projects.Stable ideas built through careful maturing need to be released in order to attract external partners, participants and sponsors.This necessitates opening up communication channels, mailing lists, ability to contribute code, suggestions, and to even re-direct code.This is an immense step and one that openEHR, and other tightly controlled projects like it, struggle with.
Openness evolves, mutates, compounds over time, and yes, it is multiple in existence and practice.To trace the evolution of an open source project compels us to pursue a longitudinal study where crises that attack the idea of openness and create the potential for change bring us closer to an understanding of how complicated the idea of openness actually is for open source projects.It is not simply a license, though the license is very important, and it is not just about access to the source code or community.Openness is far more complex and changing a phenomenon.

Implications and Conclusion
openEHR is a concrete example where 'openness' and 'open source' are not immediately evident concepts waiting to be applied (Fitzgerald, 2006), or simply the result of adopting an OSI-approved licence (Gacek and Arief, 2004).Openness is a fluctuating concept which is carefully crafted at times while other times external forces galvanize change.To theorise this evolution, we explain that two processes are at play: the metamorphic and the maturing.These intertwined processes affect the construction of the meaning of openness differently.
While our study may in part resonate with studies of open source it also provides substantial evidence that contradicts research to date.Hacker accounts do emphasise the relevance of a mythical view of openness and open source (Raymond, 1999;Stallman, 2009), but our data in line with Fitzgerald (2006), suggests that such a frame of reference did not guide the project's wider effort in interpreting openness.Our findings contribute to modern accounts of hacker culture that explain how concepts of openness help tackle contemporary challenges (Corsín-Jímenez, 2014).Rather than focus only on an open development methodology (Feller and Fitzgerald 2002;Raymond 1999) and how the openness of method builds better software, our work shows that openness is seldom static, and cannot be reduced to an embedded facet of software development.Instead, openness is a multiple idea that is embedded in different elements of license, development, practices, and community.

Where hacker accounts of the late 1990's-to early 2000's made clean breaks between what is
open and what is not -more a black or white issue -we find that recent research in open innovation has explored changes where open is seen to take on shades of grey (Dahlander and Wallin 2006;West 2003) be it with regard to platforms or accessing what is seen to be open communities to harness ideas external to the firm.Our work complements such studies with an in-depth analysis and explanation of how openness emerges, and fluctuates but at the same time is seen to be managed.We make the argument that open takes on many forms and indeed some are ideological (Choi et al. 2015;Stewart and Gosain 2006), but most are for the large part imbued with ideas of pragmatism (Dedrick and West 2007;Ven et al. 2008).Company negotiation with communities to harness open innovation has led to an opening up of the company (Dahlander and Wallin 2006;Dahlander and Magnusson 2005) to be better able to accept ideas and products external to it (Chesbrough, 2003).At the same time the communities in question have also had to adapt their governance to work more ably with companies where some compromise of ideology and openness (Baldwin, O'Mahony and Quinn 2003;Dahlander and O'Mahony 2011) has led to a rise in pragmatic ideas and practices.Our study takes a process perspective on the rise of pragmatism in management practices used by the openEHR core developers and managers to control the process of openness.Usually it takes an external actor that holds different interests to the community to force a questioning of what openness means for the latter (Dahlander 2007;Dahlander and O'Mahony 2011;Spaeth et al. 2015).Our findings contrast with those of O' Mahony and Ferraro (2007) because their results suggest that a project passes through a stage of de-facto, informally set governance.In openEHR, the organisational structures are in place before there is a critical mass of participation or project uptake.
To openEHR, the notion of 'open source' and the meaning of 'open' are, in these early years, either taken for granted or little articulated.This back-grounding of open source might be due to precisely that lack of mass participation that allows (some) difficult topics to be waived aside in lieu of pragmatism.
When change takes place in the articulation of openness, it seems to be irrevocable, pushing its interpretation into new dimensions.Contrary to literature (see Dahlander and O'Mahony 2011), a reevaluation of openness does not seem to be triggered by the involvement of external and financially powerful organisations.
Our study is different and relevant because of its absence of both a strong ideological backdrop usually present in mythical projects (Fitzgerald 2006)---visibly peripheral in openEHR---and an external actor which may trigger an ideological conflict, or a goal conflict (Spaeth et al. 2015;von Krogh et al. 2012).According to Star and Strauss (1999), absence is equally capable of revealing.The absence of external actors as catalysts of change in open source can illuminate complex internal processes of articulation of what it means to be open source.The 'formative level' centred on the creation of rigorous treatment of clinical concepts directly influenced the project's interpretation of openness, altering how the metamorphosis took place and the frequency with which fluctuations related to openness occurred within the project.There was little evidence that suggested the use of open source ideology to explain, guide, or encourage certain behaviours or events (Stewart and Gosain, 2006).The project's norms and beliefs were its own, and it grappled with its own interpretation of what openness would mean in a project that was first and foremost a health project.Instead of steadfast values that change little or slowly over time, our conceptualization reveals intertwined fluctuation in the meaning of openness that play out under different ontologies.
Our work makes some clear contributions but it is not without its limitations.Firstly, the case analysed is not necessarily a typical open source project.The domain of health IT is very specific and requires an important degree of formality.However, at the same time we know that open source is Although some participants did send us private conversations, it would have been impossible to gather them all, considering the time-span of the project and the large number of participants over the years.
Additionally, the ethical conundrum of using a private exchange is not easily solved, and we decided against using this data.At the same time one can argue that all methods have certain limitations and our pursuit has been to mitigate this through a multi-sourcing of data.
In conclusion, our main theoretical contribution is a conceptual explanation of how multiple understandings of openness emerge in an open source project and how these understandings are able to co-habit within the same community concurrently.We unpack two different types of processes that work to build a collective yet multiple understanding of openness.The processes we focus on are those of maturation and metamorphosis.Maturation shows the small and steady crafting of the core ideas of what the community wants openness to become while metamorphosis explains the significant, and mutational evolution of the meaning of 'openness' and how it comes to be interpreted as a concrete and complex notion by the members of openEHR through implementation.This conception of openness and the mutation it goes through suggests how difficult a notion it is to operationalise.This is especially salient for a project whose main output is a specification and is thus removed from the ideological epicentre more common to open source software projects that could otherwise have provided guidance.
Secondly, we contribute to the literature on open source and openness by tracing how conceptual understandings of openness in such projects become a reality through actual implementation of code and how the latter then reinforces certain ideas such as rigour, stability, and the balance between written code and an evolving project.
Additionally, while the project holds an interest in being open, this is not its principal objective.
As such, evidence suggests that openness was at first, described agnostically and non-controversially while openEHR's primordial goals were put forward and matured in-depth.The formative period helped openEHR make sense of the benefits that openness could provide, while it also aided the project to reign-in aspects that it saw as undesirable.We argue that such a significant evolution resembles the notion of metamorphosis where a body evolves into a new one holding a different potential that needs to be explored.
And lastly, though our conceptualization of maturation and metamorphosis as processes of emergence of openness speak directly to open source projects there is resonance to be found in online community evolution more generally.Many, if not all online communities evolve, mutate, and emphasize particular characteristics during certain periods of their existence.Future research in online community value mutations could be analysed using this dual process conceptualization to deepen our understanding of evolution in online community beliefs, norms and culture.

Appendix
four phases were: (1) informal exploration of the research question through conferences attendance and informal interviews; (2) exploration and initial coding of the mailing lists (2009-2010) and formal interviews; (3) selective coding of the mailing lists (2009-2010); and (4) longitudinal exploration of the mailing lists

••
exploration of the TML and CML mailing lists • Carried out informal interviews simultaneously with an archival exploration • Developed and refined the main research question • Trace ongoing controversies of the project 2010 2 Data analysis: formal interviews, tool-assisted codification of interviews and the TML and CML • Carried out 12 formal interviews • Focused on 2074 emails spanning 2009-2010 from the TML and CML • Initial coding of these email messages to build theoretical constructs around openness and emergence • Took note of evolution of openness ideas from data sources 2011-2012 3 Re-thinking data analysis: re-evaluation of codes, recodification and selective coding of the TML and CML mailing lists (years 2009-2010) Conducted deeper and broader coding after discussion with co-author • Began abstracting larger themes emerging from the data • Theoretical memos were written • Building of theoretical observations Focused on pinpointing main controversies in the project emergent longitudinally • Corroboration of themes noticed in other mailing lists • Combined with phase 3 this step led to theoretical constructs of maturation and metamorphosis 2015 CKM [Clinical KnowledgeManager, the openEHR repository for clinical concepts] provides us well-considered archetypes and templates.This is a great knowledge resource for mankind.However, to incubate archetype [a clinical concept] as a common concept takes long time like vintage wine.(September 7, 2011 /TML) to acknowledge that the future success of/open/EHR now clearly lies in the hands on the /open/EHR community itself.The Foundation is therefore seeking support for an international meeting to define and establish a new way of working.The meeting will discuss ideas about how to progress the work of /open/EHR and ensure that more people benefit from it.We would like to invite initial discussions on organising this meeting on the /open/EHR lists, which Sam Heard will moderate.[...] 1.The potential for a new Consortium that owns and provides suitable governance for the oversight, IP and other assets of the Foundation --this might comprise professional organisations, universities and industry; [...] 3. A collaborative 'refresh' and focussing of the aims and ambitions of the /open/EHR community; [...] 6.Alignment of the efforts of academia and industry around production of open source software tooling to support greater international collaboration and increased uptake of /open/EHR; […].(December 21, 2010 (AML) openEHR, as an open source project, began with an abstract understanding of 'openness' and development of its meaning remained, for a long time, a background concern.There was little mention of open source or openness at the start of the project.In fact, in the technical mailing list (TML), between 2002 and 2009, the threads which discuss open source are few: however, in only two years the issue of open source in threads was above the average for the period of data collection (2002-2015).In addition, those threads do not discuss open source directly as their main subject, in contrast to the period starting from 2009.From 2009 onwards, we interpret a change in open source as a discussion topic to something that grows in controversy.The consequence of the detailed (and increasingly controversial) meaning of

Figure 1 :
Figure 1: The Process of Metamorphosis seen alongside Key Controversies of the interpretation of 'open source' and what it means in terms of 'openness' has made the project aware of novel possibilities around the expressions of concrete articulation of openness.Stabilizing openness involved the late 2009-2015 time period when what was meant by open, what needed to be open, and how open openEHR intended to be was made concrete in relation to its primordial goals and how they matured through actual code implementation.In other words the metamorphosis was being explored and accommodated within the project's main goals, and evaluated through different implementations.Rules had to be structured as did those who would enforce them, what sanctions would be involved, and most importantly, how would different engagement partners possibly affect openEHR.If the rules and norms of behaviour related to what openness was in openEHR explains how both separate, yet closely related processes move through the passage of time.This relationship grows and deepens in time (shown by the double-ended arrows) giving rise to different interpretations of openness.The metamorphic mutation creates a multiplicity of concrete interpretations of openness with distinct potentials, some creating conflicts, for example, the push for localised governance structures could disrupt the project's coherence as the guarantor of rigour and consistency in the definition of clinical concepts.Another example confronts different interpretations of open source with each other.

Figure 2 :
Figure 2: Interweaving of Mutual Processes of Maturation and Metamorphosis is a simplified and tidy version of how openness as a multiple idea emerges in open source projects.Openness is understood to be rigour because if requirements and clinical concepts are meticulously built they can only be sustained if they are embedded and tested through implementation.Implementing such concepts also forces the project to re-define its idea of openness, and tackle the question of how open is open enough.The answer to the latter question shifts and changes over time because what is considered as open enough during the formative period is clearly not tenable for the engaged and stable phases where implementation becomes a reality.Openness includes increased participation that needs to find a way to fit comfortably with rigour.Allowing more participation, and indeed the existence of open source projects depends on participation, requires relaxing concepts such as rigour to become accessible to different audiences.
Past work on the governance of open source has focused on change within a single project; however this body of research has looked less at openness and far more at how structures evolve to build a more or less open source authority structure to filter contributions (O'Mahony and Ferraro 2007).
increasingly used and adapted to new contexts.The difficulty with which open source is implemented in those contexts can provide interesting insights to understand how various open projects come to create a useful articulation of openness.Secondly, we have studied the evolution of open source in openEHR using public mailing lists.