103 KiB
Deliberate change without hierarchical influence?
The case of collaborative OSS communities
Abstract
Purpose – Deliberate change is strongly associated with formal structures and top-down influence. Hierarchical configurations have been used to structure processes, overcome resistance and get things done. But is deliberate change also possible without formal structures and hierarchical influence?
Design/Methodology/Approach – This longitudinal, qualitative study investigates an open-source software (OSS) community named TYPO3. This case exhibits no formal hierarchical attributes. The study is based on mailing lists, interviews, and observations.
Findings – The study reveals that deliberate change is indeed achievable in a non-hierarchical collaborative OSS community context. However, it presupposes the presence and active involvement of informal change agents. The paper identifies and specifies four key drivers for change agents’ influence.
Originality/value – The findings contribute to organizational analysis by providing a deeper understanding of the importance of leadership in making deliberate change possible in non-hierarchical settings. It points to the importance of ‘change-by-conviction’, essentially based on voluntary behaviour. This can open the door to reducing the negative side effects of deliberate change also for hierarchical organizations.
Keywords
Open-source communities, deliberate change, change agents, change by conviction, hierarchical influence Introduction
There is widespread agreement in research as well as in management practice that deliberate change is key for an organisation’s success, if not for its long-term survival (By, 2005; Teece, Pisano, & Shuen, 1997). On the other hand, it is also generally acknowledged that deliberate change challenges organisations and potentially stresses their members. It disturbs existing structures and causes disorder (Schumpeter, 1934), violates the truce of existing routines (Nelson & Winter, 1982), drives people out of their comfort zones, and evokes resistance (Hon, Bloom, & Crant, 2011; Waddell & Sohal, 1998). Therefore, deliberate change is also typically associated with strong leaders and execution power (Kotter, 2007). Thus, there is general agreement that hierarchical influence is particularly needed during the implementation stage in order to get things done and overcome resistance (Somech, 2006). Strong leaders are also needed to promote change in organisations and create a sense of urgency (Higgs & Rowland, 2011; Yates, 2000).
But what happens if there are only informal leaders with no formal and positional power and organisational members are basically left doing whatever they want? This is exactly the situation for many collaborative communities such as open-source software (OSS) communities. In many of these communities, participation is voluntary, so leaders have only very limited formal power known from hierarchical organizations. How do these communities handle the challenges of deliberate change without formal power successfully? How do they secure efficient and consistent planning procedures? How do they overcome resistance and get things done? Are collaborative communities able to change at all or are they doomed to fail in the long term? Differently put, what does it mean for OSS communities to change deliberately? Organisational scholars have already shown extensive interest in OSS communities and collaborative communities in general (Martinez-Torres & Diaz-Fernandez, 2014). Key topics of interest include the motivation to participate in and contribute to collaborative communities (Cromie & Ewing, 2009; Hars & Ou, 2002; Lerner & Tirole, 2002), structures and the division of labour (Mockus, Fielding, & Herbsleb, 2002), governance structures and processes in communities (Demil & Lecocq, 2006; Markus, 2007), and coordination and communication mechanisms (Lee & Cole, 2003). While extant research thus provides a detailed picture of how OSS communities work, no studies have yet examined deliberate change in OSS communities. The few studies that address change have found that most change in OSS communities is fluid, tacit, and emergent because task execution is typically dependent on the informal structures and the voluntary contributions of members (Sharma, Sugumaran, & Rajagopalan, 2002).
The aim of this study is to investigate how deliberate change is accomplished in OSS communities. More specifically, the empirical foundation for this research has been based on a longitudinal single-case study. Data have been collected about one OSS community, called TYPO3, during 2006–2010. We refer to deliberate change as change that is intended and planned. Change is therefore not the residual outcome of a multitude of processes, even though there might be disparities between plans and outcomes (Burnes, 1996, 2009; Kanter, Stein, & Jick, 1992). In our data collection we observed various deliberate change initiatives in TYPO3 at the strategic as well as at the organisational level. The focus of this paper is on one strategic change initiative carried out in order to redirect the project’s focus towards more product usability. Our results show deliberate change is possible in OSS communities and that change agents play an essential role in change processes. We summarise our findings in a model, structuring the success factors of change agents. Two main contributions are offered. First, our paper advances knowledge about change processes in non-hierarchical structures, such as OSS communities. Because of their increasing relevance for economic activity, it is relevant to know if informal and non-hierarchical organisations allow for executing deliberate change. If this is not possible, such organizations are not likely to become old. Second, and much more important, our investigation of changes in OSS communities gives new insights into how deliberate change in non-hierarchical organisational settings is possible. It shows how organisations can master ‘change by conviction’, i.e., when organisational members are not being forced to change but accept and adapt to change voluntarily. We will discuss how the insights of this study may be used to reduce tensions and frictions of change in traditional business organisations as well.
Structure and governance of OSS communities
An OSS community consists of individuals who voluntarily contribute to the development of open-source software (Martinez-Torres & Diaz-Fernandez, 2014). Open-source software is freely available to the public under an open license and is based on unrestricted access to source code (Bonaccorsi & Rossi, 2003). Well-known examples of OSS are Linux, Firefox, and Apache (Lakhani & von Hippel, 2003). OSS communities typically demonstrate classic textbook principles of organisations in that they (i) form an entity distinguishable from its environment (Lawrence & Lorsch, 1967), (ii) have specific goals (Etzioni, 1964), (iii) have purposive actions to realise these goals (Mooney & Reiley, 1939), and (iv) are dependent on and affected by the external environment (Scott, 1981). However, at the same time, OSS communities distinguish themselves from traditional business organisations in that they are basically open to anyone to participate, participation is voluntary, there is a high degree of self-assignment, and they don’t have a physical location like a headquarters. This is enabled by modularization of the software and by distributed activities allowing for rather loosely managed and structured development processes that leave the developers free to choose which tasks to execute (Vujovic & Ulhøi, 2008). Demil and Lecocq (2006) argue open license is indeed a unique contractual framework that has generated a new type of governance structure distinct from the familiar governance modes of hierarchy, network, and market. Although OSS communities differ in terms of structure, size, and formalisation, there appears to be an ‘ideal type ground architecture’ that has been identified for many of these communities. The main characteristics of this architecture also apply to TYPO3.
OSS communities are often managed through a two-layer task structure, containing a core and a peripheral layer (Lee & Cole, 2003). The core consists of project leaders and maintainers. While leadership in some projects (e.g., Linux) is more centralised and there is one undisputed project leader, in other projects (e.g., Apache) a committee solves particular leadership tasks, such as disagreements and conflicts, through voting or consensus (Lerner & Tirole, 2002). On the one hand, these communities align with the definition of shared leadership—“distributed phenomenon in which there can be several (formally appointed and/or emergent) leaders within a group”—and which generally focuses on the emergence of such leaders (Mehra, Smith, Dixon, & Robertson, 2006, p. 233). On the other hand, investigations of shared leadership stem mainly from the context of organizational teams and emphasize the importance of formal leaders to set the stage for informal leadership roles to arise and create the conditions which will maximize the successful outcome of shared leadership in teams (Denis, Langley & Sergi, 2012). This stands in contrast to OSS communities, which are not based on formal leadership in the traditional sense. Such leadership is in fact not required for informal leaders to emerge in OSS communities. In OSS, informal leadership positions emerge through reputational gains based on “technical acumen and managerial skill” (Fleming & Waguespack, 2007, p. 165). In addition, trust is a requirement for leaders to be selected by the community (O’Mahony & Ferraro, 2007). Usually, the founders count on the project leaders having earned credibility to act as leaders by contributing the initial source code and demonstrating their expertise. Project leaders typically act as visionaries, providing recommendations, work tasks, milestones, etc., to the community. Another important leadership task is to attract new members by posing challenging programming problems for potential contributors (Lerner & Tirole, 2002, p. 220). The nature of leadership in OSS communities changes as communities grow and mature (O’Mahony & Ferraro, 2007). Over time, project leaders will perform less technical tasks, such as programming, and more organisational building tasks (ibid.). The periphery of an OSS community is often structured by the development and bug-fixing team (Lee & Cole, 2003). Members of the periphery are more loosely connected with the community. Task assignment here is mostly completely voluntary (ibid.).
Participation in OSS communities is driven by intrinsic (e.g., fun and enjoyment) and extrinsic (e.g., peer recognition, signalling of skills for career benefits) rewards (Lerner & Tirole, 2002). Lakhani and von Hippel (2003, p. 923) emphasize three motivations for participation in OSS communities: need-driven participation (e.g., the need for software), enjoyment-driven participation, and reputation enhancement. Reputation is a low-ranking incentive to join and contribute to an OSS community (ibid.). However, once a reputation is achieved, the member’s desire to maintain his or her reputation encourages the member to continue to provide quality contributions (Sharma et al., 2002). This structure is supported by a number of governance mechanisms that help direct, control, and coordinate individual efforts in OSS communities (Markus, 2007). These mechanisms include the self-assignment of tasks (Crowston, Li, Wei, Eseryel, & Howison, 2007), peer review (Lee & Cole, 2003), bug reporting, voting procedures, and the process of determining software requirements (Scacchi, 2002). Collaboration is enabled through software platforms, which provide infrastructure for sharing solutions, asking for help, etc. Services and tools, such as mailing lists, discussion forums, archives, and blogs, are the key infrastructures that enable communication and collaboration in OSS communities (Fjeldstad, Snow, Miles, & Lettl, 2012; O'Mahony & Ferraro, 2007).
To sum up, OSS communities have well-developed structures, resembling project structures in traditional business organisations. They also have leaders involved in organising and structuring processes. The major difference is that such leaders have no formal authority and thus no execution power. Participation in OSS communities is voluntary, and tasks are self-assigned. Leaders cannot therefore exert hierarchical influence but can only lead based on expertise, persuasion power, and reputation among peers. The literature has called this type of influence informal leadership (De Souza & Klein, 1995; Hongseok, Labianca, & Myung-Ho, 2006). Lakhani and von Hippel (2003, p. 923) found the informal leaders of OSS communities are capable of organising the “mundane but necessary” tasks in the day-to-day business. But are they also capable of mastering the challenges of change that are already difficult to master in formal companies and for which leadership and power are needed?
Deliberate change in organisations Like in other organisations, in OSS communities change concerns the “organisation’s direction, structure, and capabilities” (Moran & Brightman, 2001). In this sense, there is nothing unusual about the basic nature and substance of change in OSS communities. It resembles the basic structure and demands of other organisational change processes.
Many researchers have emphasised the process character of organisational change (Bullock & Batten, 1985; Hayes, 2010; Lewin, 1951). Van de Ven and Poole (1995) identified 20 models that structure change processes in different ways. However, the vast majority of these models identify three key tasks with which deliberate change processes have to deal. First, the need for change has to be recognised and the change process initiated (Kirzner, 1997). This need typically results from opportunities or threats that can be addressed by change. Further, the change initiative has to be put on the organisation’s agenda in order to secure action is taken (Kotter, 2012). Organisational change on the strategic level is a genuine management task. The recognition of change needs might come from ‘ordinary’ employees, but it is the exclusive right of the management to acknowledge these initiatives and put them on the agenda (Kesting & Ulhøi, 2010), at least in traditional business organisations. The main rationale behind such a governance structure is to secure consistency—between the different initiatives and organisational activities but also with shareholder and stakeholder interests.
Second, deliberate change tends to be based on some planning and decision-making activities (By, 2005). Goals have to be defined and information has to be acquired and analysed. The results of this process are management decisions and documents like road maps or business plans. In traditional business organisations, leaders have to drive and structure this process by creating a sense of urgency, involving organisational members and keeping track of the process (Kotter, 2012). A distinction between deliberate and emergent change is acknowledged both in the strategy literature (Mintzberg & Waters, 1985) and in the change management literature (Liebhart & Garcia-Lorenzo, 2010). Other aspects like contingency and choice have also been included in this discussion. The review of By (2005) shows how complex, heterogeneous, and inconsistent this distinction is. In this paper we do not intend to contribute to this discussion. For the argumentation of this paper, it is sufficient to specify the substance of deliberate change by the two above attributes: purpose and reason. In our understanding, deliberate change neither implies that everything goes according to plan nor that goals are realised exactly in the planned way. As Dunphy and Stace (1993) argue, organizational change takes place in a dynamic environment and organizations have to adapt their plans accordingly. Against this background, we posit that deliberate change does not rule out the emergent element. Rather, it implies change is grounded in the intention to change. This view corresponds to Mintzberg’s (1994) view of change as an element of the strategy process. In contrast, change is (completely) emergent if it is simply the accumulated result of a series of unrelated decisions and events that have no change or strategic perspective.
Third, change has to be executed and decisions implemented. This means organisation members have to make an effort to bring about the change. Also, routines have to be altered in order to adapt to change. The literature on conflict and resistance caused by change (del Val, 2003; Huy, Corley, & Kraatz, 2014) emphasises leadership and execution power as particularly necessary to get things done and overcome resistance and resolve conflicts.
Leadership power is thus required for all three tasks, most of all, however, for the implementation. Change often burdens organisations and stresses people. Leadership power is needed to change behaviour and overcome resistance. Traditional business organisations therefore often rely on a top-down implementation of planned change (Howell & Avolio, 1993). Leadership vision is needed to motivate organisational members.
But how can these challenges be handled by informal leaders? How can resistance be overcome without the use of any formal power? How does the governance structure of OSS communities handle deliberate organisational change? Currently, there is no research addressing these questions systematically. However, there is one concept of change leadership that offers some theoretical grounding for an answer that will also be important for the analysis of this article: the concept of the change agent.
Based on Caldwell’s findings (2003), we define change agents as individuals who initiate, direct, manage, and/or implement specific change initiatives. Like many other concepts, the concept of change agents is also used heterogeneously (Wylie, Sturdy, & Wright, 2014) and there are closely related concepts like (product) champions in the literature (Ginsberg & Abrahamson, 1991). The key point for our study is that change agents are individuals that drive change initiatives, i.e., create momentum and ensure decisions are made and actions are taken. In doing so, change agents can assume complex sensemaking (Brown, Colville, & Pye, 2015) and sensegiving (Petkova, Rindova, & Gupta, 2013) roles that can be essential to attract collective attention and gain legitimacy for their change initiatives. Change agents do not have to be assigned leaders with formal given responsibilities. They can even be outsiders like consultants (Volberda, Van Den Bosch, & Mihalache, 2014). However, in traditional business organisations they have to be authorised and supported by formal leaders. Therefore, the activity of change agents is also based on hierarchical influence, even though mostly indirectly. While change agents thus might not have the power to order change, the supporting formal leaders do possess such power. In this case, sensegiving, i.e. “the processes by which strategic change is framed and disseminated to an organization’s constituents” (Fiss & Zajac, 2006, p. 1173) can be particularly relevant for change agents to attract management attention and promote initiatives.
As outlined above, deliberate change cannot be decided and enforced by management in OSS communities like in traditional business organisations. Even when initiatives come from the core, they have to be based on initiative and promoted in the community. Here, sensegiving may be particularly relevant for change agents as a way to attract the attention of the community and/or even attract media attention in order to promote change initiatives. Sensegiving can support positions in the “symbolic struggles over the purpose and direction of an organization” (Fiss & Zajac, 2006, p. 1173). When coming from the periphery, it requires even more initiative to change an OSS community deliberately. Therefore, it can be expected that change agents play an important role here. However, conditions are fundamentally different because in OSS communities there is no management support or hierarchical influence upon which to draw. So, how can change agents realise change initiatives here?
Methods
Two main criteria guided the selection of our focal case. First, our case had to be a representative example of an OSS community. Second, the community had to be a mature case that had already established and formalised work procedures, guidelines, and rules. Studying change in a developed, growing community would hold promises for providing an intensive and rich case that would “manifest the phenomenon of interest intensely (but not extremely)” because extreme cases may distort the manifestation of the phenomenon (Patton, 2002, p. 234). Accordingly, we selected an OSS community named TYPO3 for this study. In line with the research objective, we first identified deliberate changes at their various stages. Then, we followed the process underlying those changes before tracing the mechanisms used to address the changes. The unit of analysis is the community, i.e., the focus is on the intraorganisational level.
Study setting
TYPO3 has been public since 2000. At the time of the study, this community was experiencing continuous growth (see Figure 1). The TYPO3 system is an enterprise-class content management system (CMS) offering out-of-the-box operation with standard modules (http://typo3.org/). The system is aimed at two different groups: (i) authors and (ii) administrators and content managers. TYPO3’s core team members play a central role in the community because they contribute most of the source code and manage the design and development of the project on a voluntary basis. When the study started, approximately half of the core team members (i.e., nine individuals) comprised the project’s R&D committee, the members of which also belonged to the project’s other teams and working groups. Moreover, the members of this committee could be described as the project’s central coordination body, as their responsibilities included (i) supervising and coordinating the development of the software; (ii) providing knowledge, contacts, and financial support; and (iii) supervising and supporting the community-driven teams. We chose the committee as a point of departure for the study because of these responsibilities. With 85.5% of their discussions focussing on governance issues (Table 1), the relevance of the R&D committee members as informants was undeniable. In addition to interviewing seven R&D committee members, two core team members were interviewed because they were directly involved with specific organisational changes before joining the core team (i.e., when they still belonged only to the community’s periphery). As the study unfolded, hundreds of other informants pertaining to the community’s periphery became involved through observations of relevant mailing lists on the TYPO3 website (Table 2).
--- Table 1 ---
--- Figure 1 ---
Starting in the year 2003, TYPO3 began to grow fast, and the number of registered developers doubled each year from 2003 to 2005. This continuous growth trend set the stage for the community changes that are the focus of this study. The time lag between the growth registered from 2003 to 2005 (Figure 1) and the start of the data collection process in 2006 was necessary to see how the community would respond to this growth.
Data sources
Multiple sources of data (Table 2) were employed to strengthen the design of the study and to capture the complexities of the case in question. These data sources allowed us to triangulate the data and validate the theoretical constructs. The data were collected on several occasions between 2006 and 2010. When the study began, TYPO3 was addressing organisational issues that had surfaced because of the growing size of the community. However, we soon discovered TYPO3 had experienced other organisational challenges in the past. Therefore, learning about the project’s history and its prior development was just as important as illuminating its current development. We collected our data through interviews, observations of face-to-face R&D committee meetings, three relevant community mailing lists, and archival data. An introductory interview with the project founder, who also acted as the project leader from 2000 to 2007, provided a deeper understanding of the community, its history, its development up to that point, its structure, its internal work processes, its products, and its current and future strategies. The rest of the interviews with the community manager of the TYPO3 Association, the R&D committee, and core team members—some of whom had only recently made a move from the periphery to the core of the community—were focussed on managing deliberate changes in TYPO3. The interviews addressed the following main themes: (i) change initiatives; (ii) activities, roles, and practices related to the identified change initiatives; (iii) motivation; and (iv) background. The same interview guide was used throughout the process, but as new relevant information emerged about specific community changes, additional questions were incorporated into the following interviews. The interviews, which lasted about 60 minutes on average, were recorded and transcribed.
Furthermore, over a two-day period in 2006, more than 18 hours were spent observing face-to-face meetings among R&D committee members. This method yielded insights into a range of organisational issues related to the community’s development and the background for the deliberate change initiatives.
A review of 235 posts from the R&D committee mailing list gave access to the content and type of discussions, the contributions and roles of various individuals, and work coordination and delegation. In particular, this source of information allowed us to obtain a deeper understanding of the organisational challenges facing the community during that time period and how those challenges were resolved.
The interviews, the observations of the R&D committee’s meetings, and the R&D committee mailing list together led to the uncovering of a number of change processes in the TYPO3 community. Additional relevant mailing list data (namely, the human-computer interaction (HCI) team’s mailing list and the core team’s mailing list) were included in the data collection. Using archival data allowed us to cross-check some of the facts uncovered during the observation activities and interviews.
Data analysis
Since we were interested in both if, how and why deliberate changes are possible in a specific context, a case study design was deemed appropriate. More specifically, when studying contemporary activities and/or events over which the researcher has no (or very limited) control, a case study research is the obvious choice (Yin, 1994). Qualitative techniques were used to analyse the data (Eisenhardt, 1989; Miles & Huberman, 1984; Strauss & Corbin, 1998). Overall, the analysis focussed on organisational practices, change, and structuring while paying specific attention to grounded concepts and proceeded in three steps. First, we constructed case studies (Eisenhardt 1989) for each identified organisational change initiative. We focussed on major change initiatives that affected the entire community. At the time of the study, four change initiatives were ongoing: (i) reorganisation of product development, (ii) establishment of a non-profit organisation called the TYPO3 Association (a central hub from which to support active developers), (iii) installation of usability as a mindset (thus replacing the strong technical mindset... in the community), and (iv) restructuring of the entire community to create more efficiency through a more transparent structure with clear responsibilities and increased team autonomy. Although the general character of three of the initiatives was structural and one of them was cultural (the usability initiative), all of the changes involved changes in both structures and practices.
Second, we divided the coding process into open, axial, and selective coding and employed a constant comparative method within each coding phase to identify the concepts and relationships relevant to each type of change (Locke, 2001; Strauss & Corbin, 1998). Third, a cross-case analysis (Eisenhardt, 1989; Miles & Huberman, 1984) was used to identify any similarities and differences across the three change types. This process was repeated several times. Each time, the resulting conceptual insights were refined and further developed. The analysis generated four core categories that represent the mechanisms employed by TYPO3 to address deliberate changes (Table 4).
The interviews, the observations from the R&D committee meetings, and the data from the three mailing lists enabled us to determine precisely the timing and order of deliberate changes and their intended effects. The same data sources were used to trace the unintended, emergent effects of the identified deliberate changes. However, the three mailing lists, which documented the reactions (or lack of reactions) of the entire community, played a central role. The interviews played a central role in establishing the timeline for the parts of the change processes (e.g., decision making) that took place offline. The preliminary findings were presented and discussed with the project leader and two core team members, who provided valuable comments that confirmed and elaborated upon the uncovered theoretical constructs. Findings
We observed multiple change initiatives in the community, some of them successful, some less successful. The most significant of these are summarised in Table 3. Change agents played a decisive role in all key tasks of the observed change management processes: recognition, decision making, and implementation. In the observed initiatives, all but one change agent originated from the community’s core. One reason for the prevalence of the core member change agents might be the fact that the identified initiatives were major and, as such, expected to have a wide-scale effect on the community.
--- Table 3 ---
Below, we sketch the four change initiatives (Table 3) by elaborating (i) the aims of each initiative, (ii) what made them deliberate, (iii) specifying the change agents, and (iv) whether the implementation was successful.
The first change initiative “Reorganization of product development” was launched because the product development process was inefficient. It was characterized by a lack of release discussions between the core and the community, the community’s failure to test enough different software versions, failure to read existing instructions about different project contributions (i.e. release management procedures, testing instructions), and poor planning of subprojects (e.g. too many postponements, unrealistic deadlines). For its part, the Core Team did not have the capacity to respond to all of the inquiries, project proposals and general input. A meeting was arranged where potential solutions were discussed, demonstrating explicit intent to plan and execute the needed change. A Core Team and R&D Committee member, who was in charge of the software release process at that time proposed a solution, which was subsequently adopted. Release management was consequently improved by introducing a rotating release manager function in July 2007. During this change process the R&D Committee’s tasks were taken over by the Core Team and one hierarchical layer got removed. This created more flexibility and readiness for the Core Team, and easier access for new contributions. Additionally, the core development mailing list was opened and created a direct communication channel between the core and periphery. The activity level increased drastically on the mailing list and this initiative more than doubled the amount of incoming patches to the core list and thus freed the Core Team members to also be able to pursue larger projects to a much higher extent than before. The initiative was thus successfully implemented.
The second change initiative “Founding of a non-profit organization called the TYPO3 Association” intended to create a committee structure, which resembled a functional organizational structure. It consisted in establishing a non-profit organization called the TYPO3 Association and was initiated by the project founder. This complex task demanded deliberate action and took many discussions, especially during the Core Team meetings and TYPO3 conferences. The main goals of the Association were to support core development on a steadier basis and improve the efficiency of the project by “providing a central hub from which to support active developers as well as to concentrate its members into a pool of regular contributors” (mailing list). The TYPO3 Association was meant to support core development by providing funds to take care of the development that was not taken care of by the commercial interests. One way was through donations, i.e. individuals who earn their income (or part of it) by using this open source software choose to give some of this income back to the community in form of donations. Another way was membership, i.e. firms and individuals could become members of the Association by paying an annual fee, which was used to sponsor software development in TYPO3. Furthermore, the Association was able to create transparency regarding decision-making, roles and activities. The change initiative was thus successfully implemented and the Association created a period of growth under goal-oriented and integrative leadership of the board whose chairman was the project leader.
The third change initiative “New team structure” was a deliberate and direct response to the rapid community growth. The project founder was the change agent behind this initiative that sought to make particular responsibilities and tasks explicit in order to create more transparency in project activities (and not only at the upper echelons of the Association). At the team level, therefore, it was determined that the following should apply to team leaders’ tasks: (i) leaders are solely responsible for the team; (ii) members are appointed/accepted by the leader; (iii) decisions are made by the leader (however, agreement is sought with the team members as far as possible); (iv) delegation of tasks is encouraged; and (v) a minimum timeframe is set for the leader’s response to team members’ requests. By defining responsibilities, the community attempted to introduce a measure of accountability in team performance, which was considered vital in this virtual context due to the voluntary nature of participation. To formalize responsibilities and tasks, the project founder thus introduced “team contracts”. These contracts served the purpose of creating synergy between the already existing teams through elaboration of a written mission statement, which, as a minimum, contained the following team information: the team’s position in the organizational structure (i.e. to which committee or project does the team belong?), a description of the team’s mission, a specification of the team’s responsibilities, the name of the team leader, and the rules for becoming a team member. Although these contracts were introduced, tasks were still taken on by self-assignment. The motive underlying the team contracts was to define two aspects: responsibility and authority. However, team contracts never really gained momentum and attempts at introducing formal authority at the team level did not succeed either. The initiative failed because the attempted structure left too few degrees of freedom to the project contributors. The type of executed authority resembled that of hierarchy (Demil & Lecocq, 2006; Powell, 1990) and unintentionally led to authority erosion. This accentuated the need for more autonomy with regard to following one’s own “personal itch”.
Finally, the aim of fourth initiative “Installing usability as a mindset” was to redirect the project’s focus towards product usability. At the time, the project’s focus was almost entirely technical in nature, which limited the product’s appeal to those customer segments with low technical skills, e.g., a secretary who edits the content on a company website: “A lot of OSS is created by technicians for technicians. […] And then there are those [users] who use [the software] every third week. They don’t demand that many functions; they demand that they don’t need to remember how [the software] works because they are only using it every third week” (interview, project founder).
The wish to introduce a greater degree of product usability was put forward by a newcomer to the TYPO3 community in 2001. This newcomer, i.e. a periphery member of the community, became the change agent, who made an explicit decision to launch a process of change, making this initiative a case of deliberate change. He was a software designer by profession and realized the need for TYPO3 to improve its design. The idea remained in the background until 2006, when the project leader established the human-computer interaction (HCI) team and an appertaining mailing list, which was intended to act as “the melting pot for ideas about usability improvements” (the HCI team mailing list). However, the progress was slow. A breakthrough first came about when the change agent started making a more focussed effort to implement the usability idea. In the end, the change initiative was successfully implemented.
While our findings are based on the analysis of all the observed initiatives in the community, we selected the fourth initiative “Installing usability as a mindset” as a representative initiative to illustrate the general traits of the organisational change mechanisms that drove the success of the change initiatives. By focusing the presentation of the study’s results on one particular change initiative our intention was to promote clarity and comprehensibility of the findings.
In the following, we present our findings, which consist of the four mechanisms that our analysis revealed as central drivers of successful, deliberate change management in the community (Table 4).
--- Table 4 ---
Individual initiative
Our data first of all reveal the community cannot be expected to embrace a change initiative—regardless of its inherent value to the community—unless there is a persistent change agent who will bring the initiative from the point of inception to successful implementation. This is a direct consequence of the absence of formal power and hierarchical influence in OSS communities. Since community members cannot be ordered to do something, they have to be persuaded to become active. The change agent of the HCI project expressed the difficulties in doing so by saying, “You can find developers that are interested in [design] topics, but you don’t really get very far. And that’s what we experienced with the HCI team…a lot’ (interview, change agent).
Even if a change agent has the right idea and engages with the right community members, this is not enough to set the change in motion. As a consequence, the change agent persevered for four years before the concept of usability penetrated the prevailing mindset and culture of the community. Persistence involves a high dose of patience, primarily because the community also needs time to adapt to organisational changes. This need was pointed out by one core member of TYPO3: “There is a gap between the design of the organisation and letting the organisation accumulate around the design…giving time to people to flock to the teams” (R&D committee meeting, core member).
We found clear indications that it is less about organisational planning and decision making and more about individual effort and achievement that motivate community members to contribute to a change initiative.
Do decisions matter in OS [communities]? No. The one thing that matters is what is actually done. Post factum situation. By doing things, people make decisions. If we make a decision, it doesn’t mean that people will be motivated to implement it, work by it. The only thing that matters is action. Consult people, hook them up with knowledge and resources, and hope that they do what you would like, what you expect… we should think of ourselves as service providers. (R&D committee meeting, core member)
This was one of the key statements of our investigation, outlining the structure of an individual initiative as clearly as possible. This view was also supported by a project founder of TYPO3 with the short statement, “First you have to do things yourself, and then others will follow” (interview, project founder). Before taking action, the change agent of the HCI project reflected upon what motivated him and other developers to do work for the project leader. He found a key driver was the project leader’s “front guy and guru status” and the fact that “he usually keeps his promises and is able to do huge workloads” (interview, change agent). Based on this insight the change agent tried to motivate others to participate in the HCI team: “I tried to find guys who were motivated by my work and then do work for me” (interview, change agent). The success of this approach was evident already in 2007 when the change agent became the HCI team leader. This success was also recognised by other community members:
Someone from the usability mailing list comes up with a nifty and good-looking screenshot and proposes his usability changes to the core developers. They are fascinated and go implement it because it seems like a really great idea to them. Especially [the change agent] has been very successful with this way of getting his suggestions implemented, and now he’s the HCI team leader. (interview, core member)
And even:
I don’t know how many have seen the PDF [the change agent] produced, but I saw it and also met him in Frankfurt before the PHP conference ([core team member name] and I joined a meeting of him and [project leader])—and there is hard and impressive work being done. (core team mailing list, core member)
In the end we found the role of change agents in communities is similar to that of product champions who experience progress over time only through persistent and enthusiastic effort (Tushman & Anderson, 1986). Persistence and leading by example are traits that define a change agent’s degree of individual initiative. Persistent change agents who are able to self-motivate and self-direct their performance, i.e., to exercise self-leadership (Manz, 1986), are an essential part of any organisational change initiative in OSS communities because it takes a great deal of time and persuasion to garner acceptance and support for any organisational change. A change agent demonstrating high levels of commitment (personal motivation and skills) may develop mutual, cognitive-based trust, which, in turn, may strengthen the community members’ readiness to engage and collaborate (Chowdhury, 2005; McAllister, 1995). Thus, we put forward the following proposition, which is grounded in the above and similar behaviours observed in the other three change initiatives (Table 3):
Proposition 1: The individual initiative of change agents is positively related to a successful implementation of deliberate organisational change initiatives in communities.
Reputation and reputation lending
Power struggles were visible during the change process for each initiative. For instance, during the observed R&D committee meeting, one member left the room because he was frustrated the rest of the group did not support his views. He was arguing against an excessively predetermined team structure, which was about to be implemented. However, he lost the debate because he was arguing against the stance of the change agent responsible for the particular change initiative, who had a higher status within the community. It was later revealed the opposing member was actually right and the team structure was, in fact, too prescriptive. This example shows how difficult it is to accomplish anything without the support of community members with higher social statuses. This difficulty exists even when the difference in social status between the change agent and the supporting high-status member is rather low (e.g., when both were members of the core team).
We find that, by lending their reputations to lower-status members, high-status members can share their influence. This was clearly recognised by the project founder: “And then, it is clear that for those individuals who have that kind of naturally given power, as I for example have, it is natural that other individuals whom we appoint and those close to us easily gain influence” (interview, project founder).
In situations where a change agent has a rather lower status in the community, as was the case in the early days of the HCI team, the change agent can gain influence by teaming up with one or more community members who enjoy a high-status reputation.
In the case of the HCI team, the change agent “did a lot of work for [the project founder]” to establish himself as a worthy community member. Eventually, he was invited to a TYPO3 Board meeting to discuss usability issues: “With [the project founder] at [the ] T3 Board we talked about why Drupal is easier than TYPO3 or why WordPress is easier than TYPO3”. By linking to high-status members in this way, the change agent gained respect and support from the high-status core members. They addressed the change agent in complimentary terms and praised his work: “As the usability guru, please give me your feedback on the description of the two mentioned features in the page tree below…” (core team mailing list, core member).
But after he was appointed HCI team leader, it was evident the he had not yet gained the same respect from other members, as they were systematically circumventing the HCI team and instead discussed the usability issues on the core team’s mailing list. An effort was made to redirect the attention towards the HCI team, in particular towards the role of the change agent, endorsing him and building his authority. Some examples of that include:
[By the way], this is [user interface] change, so it can be committed only if you get approval from [the change agent]. (core team mailing list, core member) I agree with all this but we do not have anyone else properly educated in these questions. I do not trust anyone else in [the] HCI field for TYPO3 because no one showed good HCI skills so far. [The change agent] is the only one who did. (core team mailing list, core member)
You might also have watched the podcast issue [2] where [the change agent] demonstrates some great ideas about usability improvements in TYPO3 or have seen the PDF [3]. (core team mailing list, core member)
In the subsequent period the activity levels in the HCI team increased significantly. However, there seemed to be no obvious relationship between the content of the change initiatives and the skills of the high-status members supporting the initiatives. This finding implies a potential spillover effect between reputations rooted in technical contributions and reputations rooted in organisational contributions.
There were also instances when high-status members (e.g., project and team leaders, core team members, and other respected members) met the change agents halfway. Our data show the leaders in TYPO3 work with the community’s initiatives through a process of mutual adjustments. The leaders notice promising initiatives, assess them, and try to provide them with the necessary resources:
I tried to motivate him to build a team around that. I just noticed him. In this way, I try to enable people to work. It’s a bit intuitive also. I [have been] working already for ten years on this system, so the foundation for something like this was probably already laid a couple of years back. (interview, community manager)
This type of leadership emphasises intuition and alertness. The main task consists of providing support for change initiatives in the form of knowledge and resources without making decisions on behalf of the community members. Rather, the leaders establish the infrastructure and framework that will hopefully assist the community change agents in paving the way for the intended improvements and changes. High-status members lend their lateral authority and reputation to a change agent by providing any type of visible support, even if it is only verbal in nature. One reason this method works is that high-status members’ support provides the change agent with credibility, which is crucial if the initiative is to stand a chance of being implemented (Markus & Benjamin, 1996). This finding further suggests community leadership is shared via reputation lending, which also facilitates organisational changes in communities. Therefore, based on the above and similar behaviours observed in the other three initiatives (Table 3) we make the following prediction:
Proposition 2: Reputation lending (from high status to lower status members) is positively related to a successful implementation of deliberate organisational change initiatives in communities.
Change-oriented communication
We found communication about change initiatives was essential to their successful implementation. Through meetings and presentations to small and large target audiences at various community events, change agents in TYPO3 communicated the rationales and arguments behind the initiatives. Still, it took the change agent behind the HCI initiative a long time to realise communicating the idea about usability was vital to its success. The change agent attracted support for the usability initiative by communicating (in a change-oriented fashion) the basic ideas behind the concept in several rounds of presentations to the developer community: “This is why [the project founder] and I decided that maybe we just need to find out how we can change that point of view to guide developers in a different direction—so a typical marketing and communication thing” (interview, change agent). From 2007 to 2008, the change agent tried to motivate the community by communicating the relevance of usability to TYPO3 through presentations at the community’s main yearly events.
The first presentation was just about usability flaws, ten major usability flaws […] at the Developer Days in 2007. Then, in 2008, at T3Con, I held a presentation about what can be done in a positive way with usability, solutions and future interfaces like, for example, the interfaces in “Minority Report” […]. If I look back, that was the second phase to motivate [people], saying, “Look, that’s possible if we work together”, and “Wouldn’t it be fun to have some amazing interfaces in there?” (interview, change agent)
In all observed projects, the presentations helped change agents to gain the community’s trust in them and their capabilities.
After I showed them [through presentations] that it could really get done, they kind of trusted in the words I said. Because usually it’s a very inner circle, only developers with developers, so they could trust each other. They have the same language. But now, there comes this strange design guy and he says, “You are doing everything wrong; you have to change everything, and you don’t even have the knowledge to understand what you are doing wrong.” That doesn’t really end in trust. (interview, change agent)
In addition to establishing the trustworthiness of the change agent (Gurtman, 1992), the change-oriented communication process in TYPO3 also helped stimulate the community members to participate because the process also aimed to educate the target audience about the attempted changes. The community developers were the target: “Then through the Usability Week, we started, in some way, to educate [people]” (interview, change agent).
This facilitation of community participation resembles a particular dimension of shared leadership, called voice, which is known to increase a person’s social influence among the members of a community (Carson, Tesluk, & Marrone, 2007). During the change initiatives, which had a successful outcome, the change agents excelled at initiating and facilitating constructive, change-oriented dialogue and debates around how the community should achieve the needed changes. Thus, voice boosted the change agents’ level of social influence by increasing immersion and participation through various means, such as opening the core team’s mailing list (under a set of rules) to the rest of the community, implementing rotating release managers, presenting ideas at community events, and establishing Usability Week. Voice in the form of change-oriented communication may be associated with successful change implementations because voice is based on interpersonal events that promote communication and feedback, which, according to Ryan and Deci (1985), catalyse feelings of competence and thereby stimulate intrinsic motivation. Based on the above and on similar behaviours exhibited in the other three initiatives (Table 3), we make the following prediction:
Proposition 3: Change-oriented communication is positively related to a successful implementation of deliberate organisational change initiatives in communities.
Motivation through challenging tasks
Because of the self-assignment principle (Crowston et al., 2007), one of the major challenges in open-source communities is motivating developers to work on tasks that are uninteresting but necessary to complete (Lakhani & von Hippel, 2003). We can see this problem extends to organisational change initiatives. This was also recognised by the change agent of the HCI project, “[…] usability topics are not really challenging for developers usually. It’s about removing staff, making staff simple, and that’s usually not the challenge for developers. It’s a challenge for me as designer” (interview, change agent). The resulting challenge was put more generally by one member of the core team: “We were uncertain how to get people to do some of the more boring and time-consuming, but essential, tasks” (interview, core team member).
Working with usability demanded the developers overcome three fundamental tasks. First, the developers needed to become motivated to work on usability issues. Second, the TYPO3 community had to attract skilled software designers who possessed the necessary knowledge regarding usability. Third, the change agent had to find a way to stimulate the developers to follow the designers’ recommendations.
To motivate developers to work on usability issues, the change agent came up with the idea to create “fake challenges […] to motivate them to finish the goals” (interview, change agent). His approach was based on the idea that developers would be more willing to work on their tasks if they perceived them to be challenging.
After a while I came up with the idea to have a ‘Usability Week’. The concept was pretty simple. I rented a castle for one week, and I locked 30 developers in that castle, and they had a certain task they needed to solve within that one week. So, the challenge was there in some way because they needed to solve the problem in one week, which is kind of tough because the problems I took [on] were too huge to solve in one week. So, there was a challenge even if the task was simple because they had time pressure. (interview, change agent)
During Usability Week, five mixed teams were created. Each team consisted of three developers, one core developer, one manager, and one designer. Each day of the event three meetings took place. The meetings were designed to streamline the tasks and motivate the teams.
To attract designers to the TYPO3 community and the usability project, the change agent used a different set of tools. He created an entrance barrier that the designers needed to overcome before they could join the community. My major wish through that Usability Week wasn’t to solve those tasks but to find more designers who [were] able and motivated to join the TYPO3 community. My idea to make it more interesting to them was, again, to make it a little bit more complicated because they had to apply to the Usability Week. So, we had about 60 or 70 applications and only 30 places. In the end, only five designers out of 50 could join, and they were somehow charmed because they could attend and others couldn’t. It really worked out and they really stuck to the project and until today [are] doing some design work. (interview, change agent)
Finally, to motivate the developers, the change agent needed to make the tasks related to usability issues more challenging. He achieved this by incorporating (i) novel task structure and content and (ii) freedom to execute the tasks in a different way than usual into simple problems. By doing so, the change agent successfully motivated the developers to solve those problems.
For example, to structure a website we have something called a ‘page tree’, which looks like the tree in Explorer on your Windows machine, and that’s kind of very old style, how it is done […]. However, there is a framework called XJS, written in Java Script, and that is interesting for developers because it’s a new technology in some way and a new framework, and it’s hard to implement, and they need to change a lot. So, I decided that they should use XJS for that page tree, even if we don’t need it, but then I would be sure that in the end I would have the page tree I wished to have and they would have a challenging task to actually do it instead of writing some lines by themselves to change [the page tree]. (interview, change agent)
We really had the freedom to totally change the core… Actually, the way […] we worked… we [were] taking the beta version of 3.9 back in time, and we just coded anything we liked inside the core. Usually, someone who creates an extension is [told] “never touch any core file”, [but here] we could really go deeply inside and delete files, replace files totally, and we did not have to focus on keeping [it] compatible with the old code and being compatible with the old […] extensions. (interview, developer)
In the case of the HCI project, Usability Week turned out to be quite successful:
They were challenged by whether they could reach the goals. This really moved the project hugely forward in one week […] In the end, I have to say, we didn’t reach any of our goals […] But they got pretty far, and it really gave the whole [usability] project a new motivation. (interview, change agent)
The self-assignment of tasks, which is the prime mechanism for work division and task allocation in OSS communities, is obviously an issue if the tasks do not attract enough interest and, consequently, remain undone. Task challenge here refers to a continuum ranging from low-to high-stimulation tasks (e.g., highly routinized tasks versus non-standardized, original tasks). The case of TYPO3 shows that increases in task challenge due to, for example, entrance barriers, competition, level of within-task stimulation, task novelty, or freedom to execute a task in a new way, can compensate for an initial lack of personal desire, which would normally drive the self-assignment of tasks. Our analysis shows that in the case of tasks related to the implementation of organisational change initiatives, the change agent needs to increase the perceived task challenge in accordance with the skills and interests of the targeted members. Thus, task challenge should be seen as a dynamic factor dependent on the person-task interaction (Campbell, 1988). Task challenge is associated with increased participation because it appeals to intrinsic motivation, the primary motivational factor in open-source communities (Lakhani & Wolf, 2005). In turn, increased participation improves performance (Hackman & Oldham, 1976; Herzberg, 1959). Furthermore, creating entrance barriers to team membership proved effective at activating a sense of achievement and recognition as stimuli (Herzberg, 1959). Hence, based on the above and the other three observed change initiatives (Table 3) we make the following prediction:
Proposition 4: Increased task challenge is positively related to a successful implementation of deliberate organisational change initiatives in communities.
Discussion This study offers the first comprehensive investigation of deliberate change in OSS communities. It presents clear indications that OSS communities are indeed capable of changing deliberately and, therefore, not doomed to fail in the long run. A change is deliberate because it is desired by a community member—the change agent—and then supported by a sufficient coalition within the community; in the observed HCI project, the change initiative was carried out with the clear goal of improving the usability of TYPO3.
Our study also shows that in OSS communities deliberate change is highly dependent on change agents who play an essential role in managing the key tasks of change processes: (i) change agents recognise the need for change and translate that into organisational goals; (ii) they create a sense of urgency and convince community members to make decisions in this matter; and (iii) they push the change process and ensure things are getting—often by doing things on their own. This is a clear contrast to hierarchical business organisations, where change is mostly driven by leaders with positional power and/or special functions and change agents only play a secondary role. Against this background, this study of deliberate change in OSS communities focuses on the investigation of change agents and the success drivers of their initiatives. The insights of this study can be summarised in a simple model:
--- Figure 2 ---
These findings are first of all relevant for the research on non-hierarchical organizational settings such as OSS communities. They provide insights into an area that was vastly under-researched so far. In addition, knowledge of change is as important for collaborative communities as it is for traditional business organisations because (i) it allows designing change processes more purposefully and (ii) it provides insights into the long-term behaviour of collaborative communities in relation to their (competitive) environment. As long as they are based on a similar governance structure, there is good reason to assume these findings also apply to other types of communities of practice not related to software development (Bridwell-Mitchell, 2015). This gives a broader relevance to our findings since the importance of communities is increasing in an information- and knowledge-based economy (O’Mahony & Ferraro, 2007).
However, the findings of this study also include some quite interesting and relevant findings that go beyond communities and also concern change processes in traditional business organisations. In this way, our paper can also contribute to the broader change literature. The elements of the above change model are not all completely new. We already know about change agents, informal power and leadership from investigations of other contexts. What is new and important, however, is that the complete absence of formal power does not prevent the execution of deliberate change and the critical role of change agents to drive the process. OSS project leaders and core team members do not have formal command authority to enforce decisions (von Hippel & von Krogh, 2003). This is also clearly illustrated by especially the third change initiative “New team structure” (Table 3), in which the project leader and founder was the change agent. Although he kept the team contracts on the agenda for two years, he was unable to implement this initiative. Had he had any kind of formal fiat in the community, this initiative would probably have lead to a different outcome. But OSS communities “do not rely on employment contracts and so are unable to be governed by formal authority, as is the case in a hierarchy” (Demil & Lecocq, 2006, p. 1454). This allows for some quite interesting perspectives and insights.
The first important finding is the apparent irrelevance of decision making in a hierarchical sense, as expressed by community members. This point needs some clarification. It does not mean there is no deliberate planning or decision making taking place in OSS communities. Instead, these statements relate to their power structure. In his article, Finkelstein (1992) distinguished various forms of management power. As outlined above, OSS communities are characterised by the inherent absence of formal power (‘structural power’ in the terminology of Finkelstein, 1992, p. 509, i.e., the “legislative right to exert influence” over others). Other forms of informal power, like ‘expert power’ and ‘prestige power’ not only exist in OSS communities, but they play an important role in the informal leadership that provides the foundation for the significance of the community’s core team (Fleming & Waguespack, 2007; O’Mahony & Ferraro, 2007). Individual initiative (proposition 1) as a mechanism of change resembles some change factors observed in ‘traditional’ organizations with formal leadership (i.e. hierarchies, Demil & Lecocq, 2006). Similarly to community change agents, agents in hierarchies make use of exemplary change or leading by example (Kotter, 2012). Also, individual initiative bears resemblance to the tasks performed by change champions (Ulrich, 1997) and product champions (Day, 1994), such as providing impetus for and strongly promoting the change initiative. However, the apparent irrelevance of decision making in community change points to a structural power deficit of change agents with regard to change initiatives. Change agents are able to convince relevant community members, decisions are made, and tasks are distributed, but this does not often result in action. In these situations, decisions are only relevant to legitimise the activities of change agents, not to trigger action. Often, change agents have to keep pushing to get things done; in other cases, they have to complete the tasks themselves. Against this background, individual initiative is a strategy to exert influence without formal power. Yet, it has to be noted this strategy only works locally, and informal power is still needed by change agents at other points. Individual initiative might even result in the acquisition of expert and prestige power because it makes change agents and their abilities visible. To date, the meaning of individual initiative and the structure of low-power contexts are not very well understood. It might be expected that individual initiative also plays a role in high-power contexts as a strategy to exert influence without power. However, more research is needed in this regard.
Another interesting point is the observations of what we have named ‘reputation lending’ (proposition 2). There is already some research on reputation and advancement in communities and other organisations without vertical lines of authority (Fleming & Waguespack, 2007). Research knows a lot about (i) what authority means for flat hierarchies and (ii) how authority is acquired there (Dahlander & O’Mahony, 2011). In the context of hierarchies, reputation lending parallels coalition formation, support building and gaining sponsorship from individuals with organizational clout, formal authority, and access to resources (Connor, 1998; Day, 1994; Kanter, 1994; Kotter, 2012). Such actions help legitimize the change initiative and the change agent as well as create acceptance of change by those affected (Buchanan & Boddy, 1992). Conceptually, reputation lending is also somewhat close to leader support in hierarchies (Amabile, Schatzel, Moneta, & Kramer, 2004). Leader support means using the formal power of managers to support activities by less-powerful organisational members, often in relation to innovation and change activities. This support can include resources and time, autonomy, and support in organisational decision making (Mumford, Scott, Gaddis, & Strange, 2002). In contrast, reputation lending implies using the informal power of community leaders to support change agents in their activities, mostly by giving them recognition, letting them participate in board meetings and decision-making procedures, and making them and their initiatives more visible in the community. This informal form of support has not been described so far in the literature. Still, this is interesting because the elements of visibility and acceptance play only a minor role in leader support. This finding indirectly confirms the research showing the importance of informal networks and policy systems for change agent success (Battilana & Casciaro, 2012).
We also discovered interesting findings with regards to the motivation of community members to carry out change-related tasks. As discussed in the conceptual section above, motivation has already been the focus of previous research. Lakhani and von Hippel (2003) found that participation in OSS communities is quite rewarding since “98% of the effort expended by information providers in fact returns direct learning benefits to those providers” (p. 923). However, we observed there are change-related tasks that are not rewarding and that it is rather challenging to motivate community members to work on them. In this regard, we observed the strategy of so-called ‘fake challenges’ (proposition 4). The underlying approach is to combine unattractive tasks with motivating elements like competitions or social gatherings. There is an interesting early description of the principle: the fence episode in the novel The Adventures of Tom Sawyer by Mark Twain (1876). Most readers perhaps remember: Tom had to paint Aunt Polly’s fence as a punishment after he dirtied his clothes in a fight. He hated this work; however, when one of his friends came to the spot, Tom was able to create the impression that it was a privilege and a pleasure to paint the fence. After a while, he was even able to sell painting permissions to his fellows. In this sense, the change agent was successful in creating a sense of exclusivity by restricting spaces at the challenge and transformed boring work into a socially attractive event. To our knowledge, this strategy has not been described by research on OSS communities so far. Ultimately, the strategy of creating challenging tasks is expected to improve the community members understanding and sense of ownership of the change initiative, and eventually enhance their motivation to participate in executing change. In that sense, this approach has the same objective as, for instance, empowerment of organizational members, which is an important element in the change leadership literature within the context of hierarchies (Caldwell, 2003; Gill, 2003; Goffee & Scase, 1992). While both strategies thus seek to remove obstacles to change, they are in fact each other’s opposites. One strategy uses task design to deal with the downsides of an innate characteristic of OSS communities, i.e. member autonomy. The other, however, seeks to increase member autonomy in a hierarchical setting, where strong administrative controls provide formal powers to supervise and regulate the behaviour of organizational members (Demil & Lecocq, 2006).
Although change processes have been theorized about and practiced in a variety of ways, the one finding that deliberate change in OSS communities has mostly in common with change in hierarchies is related to change-oriented communication (proposition 3). Through frequent communication change agents create opportunities for organizational members to understand and give input to the change process (Kotter, 2012). Practicing openness and widespread communication (Buchanan & Boddy, 1992) during a change process increases the chance of successful implementation because organizational communication plays a central role in eroding existing path dependencies (Cohen & Levinthal, 1990), thus paving the way for organizational change.
Yet, the most important finding of this study is perhaps the very observation that OSS communities succeed in handling deliberate change processes without any formal or pre-assigned power. Certainly, informal power, persuasion, and group pressure are relevant to manage deliberate change in OSS communities to a certain extent. Situations can arise in which organisational members are faced with the decision to accept change or leave the community. Still, no community member can be ordered to accept change like in traditional business organisations. Nobody can be laid off, and sanctioning possibilities are generally very limited. If community members comply with change, they do so because they believe in it or at least accept the majority decision. If a change project is not supported by a critical mass of the community, it will not be successful. We call this type of deliberate change ‘change by conviction’. Why is that relevant? If people comply with change voluntarily, there is a good chance negative side effects, resulting from enforcement, will be reduced (even though not completely eliminated because group members might submit to change unwillingly or leave the community). Indeed, we found some indications for that in our data, even though we were not directly looking for it. We are convinced these findings may also be applicable to hierarchical business organisations and that the latter can learn a lot from OSS communities to reduce the level of enforcement in change processes, thereby decreasing the levels of demotivation, insecurity, and resistance. Consequently, the relevance of our findings is much broader and does not only concern non-hierarchical settings such as OSS communities but helps shed additional light on deliberate organisational change in general. More research is, however, needed to substantiate these findings, clarify the impact of different elements of change on negative side effects, and explore possibilities for traditional business organisations.
Managerial implications
The most obvious managerial implication is that communities need to be aware of the central role of change agents in deliberate change to organise change processes accordingly. This study emphasizes the role and importance of individuals taking initiatives and responsibilities by outlining some critical success factors for realizing deliberate change in non-hierarchical settings such as OSS communities. Another implication is that hierarchical organizations need also reconsider their use and appreciation of change agents, including self-appointed ones. Change agents are already being used in hierarchical business organisations but often in an unsystematic way. However, the results of this study suggest it would be useful to base all major change projects on change agents here as well. After decisions have been made, change agents can simply be assigned and endowed with the necessary power or supported by top managers. Contrary to the non-hierarchical case analysed in this study, there is no specific individual initiative needed at this point in hierarchical organisations. Still, it might be important for change agents to care more than usual about the second driver in our model and build a reputation for being the right person to organise the change process among all organisational members involved in it. The two last drivers point to communication and education, as well as to motivation. We are convinced a lot can be done to smooth change projects in hierarchical business organisations, and it might be even possible to establish a regime of change by conviction there.
Limitations and future research
The first limitation of this study is of theoretical nature. When investigating deliberate change in OSS communities, we are touching on a variety of different themes, including leadership, reputation building, informal power, motivation, innovation, and others. Each of these themes can be further developed, and many of them might potentially offer new insights. For the sake of rigour, we decided to focus on change, the meaning of change agents, and the drivers of change agent success. We have targeted this study primarily toward the research conversations on communities and on change. This is a decision that was made to keep the study focused and detailed.
Second, in this study we were not looking at organisational context factors that mediate the effect of the success drivers of change agent activities like the cultural context, size and age of the community, degree of formalisation, or others. We also did not look at the antecedents of change agent activities. This means our study is far from offering a complete model of change agent activity in communities. Still, we think our propositions can be useful stepping stones towards a more holistic model.
Analysing classic concepts and/or phenomena such as deliberate change under entirely different and new(er) organizational regimes is important as it not only helps to clarify how such organizational settings work, it also sheds new light on the phenomenon under investigation. In our study, the realization of the phenomenon manifested itself in the form of self-appointment of change agents. While this was necessary for the phenomenon to exist in a completely different and non-hierarchical organizational setting, it also holds potential for being applied in hierarchical settings.
Conclusion
This study provides evidence that it is indeed possible to change complex organisations deliberately without formal power and hierarchical influence. All change initiatives we observed were grounded in the individual commitment of change agents. However, we also found the success of change agents’ initiatives depended on their ability to get sufficient support within the organisation. Key drivers of this are individual initiative, reputation and reputation lending, change-oriented communication and education, and motivation through challenging tasks. There is reason to assume these insights also hold for a broader range of organisations, including hierarchical business organisations. This is relevant because there are indications that change by conviction reduces the negative side effects of deliberate change.
References
Amabile, T. M., Schatzel, E. A., Moneta, G. B., & Kramer, S. J. (2004). Leader behaviors and the work environment for creativity: Perceived leader support. Leadership Quarterly, 15(1), 5-32.
Battilana, J., & Casciaro, T. (2012). Change Agents, Networks, and Institutions: A Contingency Theory of Organizational Change. Academy of Management Journal, 55(2), 381-398.
Bonaccorsi, A., & Rossi, C. (2003). Why Open Source Software Can Succeed. Research Policy, 32, 1243-1258.
Bridwell-Mitchell, E. N. (2015). Collaborative Institutional Agency: How Peer Learning in Communities of Practice Enables and Inhibits Micro-Institutional Change. Organization Studies.
Brown, A. D., Colville, I., & Pye, A. (2015). Making sense of sensemaking in organization studies. Organization Studies, 36(2), 265-277.
Buchanan, D., & Boddy, D. (1992). The expertise of the change agent. London: Prentice Hall.
Bullock, R. J., & Batten, D. (1985). It's Just a Phase We're Going Through: A Review and Synthesis of OD Phase Analysis. Group & Organization Studies, 10(4), 383-412.
Burnes, B. (1996). No such thing as ... a "one best way" to manage organizational change. Management Decision, 34(10), 11. Burnes, B. (2009). Managing change: a strategic approach to organisational dynamics (5th ed.). Harlow, England; New York: Prentice Hall/Financial Times.
By, R. T. (2005). Organisational change management: A critical review. Journal of Change Management, 5(4), 369-380.
Caldwell, R. (2003). Models of change agency: A fourfold classification. British Journal of Management, 14, 131-142.
Campbell, D. J. (1988). Task complexity: A review and analysis. The Academy of Management Review, 13(1), 40-52.
Carson, J. B., Tesluk, P. E., & Marrone, J. A. (2007). Shared leadership in teams: An investigation of antecedent conditions and performance. Academy of Management Journal, 50(5), 1217-1234.
Chowdhury, S. (2005). The role of affect- and cognition-based trust in complex knowledge sharing. Journal of Managerial Issues, 17(3), 310-327.
Cohen, W. M., & Levinthal, D. A. (1990). Absorptive capacity: a new perspective on learning and innovation. Administrative Science Quarterly, 35(1), 128-152.
Connor, D. R. (1998). Managing at the speed of change. Chichester, UK: John Wiley & Sons.
Cromie, J. G., & Ewing, M. T. (2009). The rejection of brand hegemony. Journal of Business Research, 62, 218-230.
Crowston, K., Li, Q., Wei, K., Eseryel, U. Y., & Howison, J. (2007). Self-organization of teams for free/libre open source software development. Information and Software Technology, 49, 564–575.
Dahlander, L., & O'Mahony, S. (2011). Progressing to the Center: Coordinating Project Work. Organization Science, 22(4), 961-979. doi: 10.1287/orsc.1100.0571 Day, D. (1994). Raising radicals: Different processes for championing innovative corporate ventures. Organization Science, 5, 148-173.
De Souza, G., & Klein, H. J. (1995). Emergent leadership in the group goal-setting process (English). Small group research, 26(4), 475-496.
del Val, M. P. (2003). Resistance to change: a literature review and empirical study. Management Decision, 41(2), 148.
Demil, B., & Lecocq, X. (2006). Neither market nor hierarchy nor network: The emergence of bazaar governance. Organization Studies, 27(10), 1447-1466.
Dunphy, D., & Stace, D. (1993). The strategic management of corporate change. Human Relations, 46(8), 905-920.
Eisenhardt, K. M. (1989). Building theories from case study research. Academy of Management Review, 14(4), 532.
Etzioni, A. (1964). Modern organization. Englewood Cliffs, N.J.: Prentice-Hall, Inc.
Finkelstein, S. (1992). Power in top management teams: dimensions, measurement, and validation. Academy of Management Journal, 35(3), 505-538.
Fiss, P. C., & Zajac, E. J. (2006). The symbolic management of strategic change: sensegiving via framing and decoupling. Academy of Management Journal, 49(6), 1173-1193.
Fjeldstad, Ø. D., Snow, C. C., Miles, R. E., & Lettl, C. (2012). The architecture of collaboration. Strategic Management Journal, 33, 734-750.
Fleming, L., & Waguespack, D. M. (2007). Brokerage, Boundary Spanning, and Leadership in Open Innovation Communities. Organization Science, 18(2), 165-180.
Gill, R. (2003). Change management — or change leadership? Journal of Change Management, 3(4), 307-318. Ginsberg, A., & Abrahamson, E. (1991). Champions of change and strategic shifts: The role of internal and external change advocates. Journal of Management Studies, 28(2), 173-190.
Goffee, R., & Scase, R. (1992). Organizational change and the corporate career: the restructuring of managers’ job aspirations. Human Relations, 45(4), 363-384.
Gurtman, M. B. (1992). Trust, distrust, and interpersonal problems: a circumplex analysis. Journal of Personality & Social Psychology, 62, 989-1002.
Hackman, J. R., & Oldham, G. R. (1976). Motivation through the design of work - test of a theory. Organizational Behavior and Human Performance, 16(2), 250-250.
Hars, A., & Ou, S. (2002). Working for free? Motivations for participating in open-source projects. International Journal of Electronic Commerce, 6(3), 25–39.
Hayes, J. (2010). The theory and practice of change management (3rd ed.). New York: Palgrave Macmillan.
Herzberg, F. (1959). The motivation to work. New York: John Wiley and Sons.
Higgs, M., & Rowland, D. (2011). What Does It Take to Implement Change Successfully? A Study of the Behaviors of Successful Change Leaders. Journal of Applied Behavioral Science, 47(3), 309-335.
Hon, A. H. Y., Bloom, M., & Crant, J. M. (2011). Overcoming Resistance to Change and Enhancing Creative Performance. Journal of Management, 40(3), 919-941.
Hongseok, O., Labianca, G., & Myung-Ho, C. (2006). A mulitlevel model of group social capital. Academy of Management Review, 31(3), 569-582.
Howell, J. M., & Avolio, B. J. (1993). Transformational leadership, transactional leadership, locus of control, and support for innovation: key predictors of consolidated-business-unit performance (English). Journal of applied psychology, 78(6), 891-902. Huy, Q. N., Corley, K. G., & Kraatz, M. S. (2014). From Support to Mutiny: Shifting Legitimacy Judgments and Emotional Reactions Impacting the Implementation of Radical Change. Academy of Management Journal, 57(6), 1650-1680.
Kanter, R. M. (1994). The change masters. London: Allen & Unwin.
Kanter, R. M., Stein, B., & Jick, T. (1992). The challenge of organizational change: How companies experience it and leaders guide it. New York: Free Press.
Kesting, P., & Ulhøi, J. P. (2010). Employee-driven innovation: extending the license to foster innovation. Management Decision, 48(1), 65-84.
Kirzner, I. M. (1997). Entrepreneurial Discovery and the Competitive Market Process: An Austrian Approach. Journal of Economic Literature, 35(1), 60-85.
Kotter, J. P. (2007). Leading Change: Why Transformation Efforts Fail. Harvard Business Review, 85(1), 96-103.
Kotter, J. P. (2012). Leading change. Boston, Mass.: Harvard Business Review Press.
Lakhani, K. R., & von Hippel, E. (2003). How open source software works: "free" user-to-user assistance. Research Policy, 32(2003), 923-943.
Lakhani, K. R., & Wolf, R. G. (2005). Why hackers do what they do: Understanding motivation efforts in free/open source projects. In S. A. Hissam, B. Fitzgerald, J. Feller & K. R. Lakhani (Eds.), Perspectives in free and open source software (pp. 3-21). Cambridge, MA: MIT Press.
Lawrence, P. R., & Lorsch, J. W. (1967). Organization and environment: Managing differentiation and integration. Cambridge, MA: Harvard University Press.
Lee, G. K., & Cole, R. E. (2003). From a firm-based to a community-based model of knowledge creation: The case of the Linux Kernel Development. Organization Science, 14(6), 633-649. Lerner, J., & Tirole, J. (2002). Some Simple Economics of Open Source. The Journal of Industrial Economics, 50(2), 197-234.
Lewin, K. (1951). Field theory in social science; selected theoretical papers ([1st ed.). New York,: Harper.
Liebhart, M., & Garcia-Lorenzo, L. (2010). Between planned and emergent change: decision maker’s perceptions of managing change in organisations. International Journal of Knowledge, Culture and Change Management, 10(5), 214-225.
Locke, K. (2001). Grounded theory in management research. London: Sage Publications.
Manz, C. C. (1986). Self-leadership: toward an expanded theory of self-influence processes in organizations. Academy of Management Review, 11, 585-600.
Markus, M. L. (2007). The governance of free/open source software projects: Monolithic, multidimensional, or configurational? Journal of Management and Governance, 11(2), 151-163.
Markus, M. L., & Benjamin, R. I. (1996). Change agentry - The next IS frontier. MIS Quarterly, 20(4), 385-407.
Martinez-Torres, M. R., & Diaz-Fernandez, M. C. (2014). Current issues and research trends on open-source software communities. Technology Analysis & Strategic Management, 26(1), 55-68.
McAllister, D. J. (1995). Affect and cognition based trust as foundations for interpersonal cooperation in organizations. Academy of Management Journal, 38(1), 24-59.
Mehra, A., Smith, B., Dixon, A., & Robertson, B. (2006). Distributed leadership in teams: The network of leadership perceptions and team performance. Leadership Quarterly, 17, 232–245. Miles, M. B., & Huberman, A. M. (1984). Qualitative data analysis: A sourcebook of new methods. Beverly Hills, CA: Sage Publications.
Mintzberg, H. (1994). The rise and fall of strategic planning. New York (NY): The Free Press.
Mintzberg, H., & Waters, J. A. (1985). Of strategies, deliberate and emergent. Strategic Management Journal, 6(3), 257-273.
Mockus, A., Fielding, R. T., & Herbsleb, J. (2002). Two case studies of open source software development: Apache and Mozilla. ACM Transactions on Software Engineering and Methodology, 11(3), 309–346.
Mooney, J. D., & Reiley, A. C. (1939). The principles of organization. New York: Harper and Brothers.
Moran, J. W., & Brightman, B. K. (2001). Leading organizational change. Career Development International, 6(2), 111-118.
Mumford, M. D., Scott, G. M., Gaddis, B., & Strange, J. M. (2002). Leading creative people: Orchestrating expertise and relationships. Leadership Quarterly, 13(6), 705.
Nelson, R. R., & Winter, S. G. (1982). An evolutionary theory of economic change. Cambridge, Mass.: Belknap Press of Harvard University Press.
O’Mahony, S., & Ferraro, F. (2007). The emergence of governance in an open source community. Academy of Management Journal, 50(5), 1079-1106.
Patton, M. Q. (2002). Qualitative research and evaluation methods (3rd ed.). Thousand Oaks, CA: Sage Publications.
Petkova, A. P., Rindova, V. P., & Gupta, A. K. (2013). No news is bad news: sensegiving activities, media attention, and venture capital funding of new technology organizations. Organization Science, 24(3), 865-888. Powell, W. W. (1990). Neither market nor hierarchy: network forms of organization. Research in Organizational Behavior, 12, 295-336.
Ryan, R. M., & Deci, E. L. (1985). Intrinsic and extrinsic motivations: Classic definitions and new directions. Contemporary Educational Psychology, 25, 54-67.
Scacchi, W. (2002). Understanding the requirements for developing open source software systems. IEE Proceedings--Software, 149(1), 24-39.
Schumpeter, J. A. (1934). The theory of economic development; an inquiry into profits, capital, credit, interest, and the business cycle. Cambridge, Mass.,: Harvard University Press.
Scott, W. R. (1981). Organizations: rational, natural and open systems. Englewood Cliffs, NJ: Prentice Hall.
Sharma, S., Sugumaran, V., & Rajagopalan, B. (2002). A framework for creating hybrid-open source software communities. Information Systems Journal, 12, 7-25.
Somech, A. (2006). The Effects of Leadership Style and Team Process on Performance and Innovation in Functionally Heterogeneous Teams. Journal of Management, 32(1), 132-157.
Strauss, A., & Corbin, J. (1998). Basics of qualitative research - techniques and procedures for developing grounded theory (2nd edition ed.). London: SAGE Publications.
Teece, D. J., Pisano, G., & Shuen, A. (1997). Dynamic capabilities and strategic management. Strategic Management Journal, 18(7), 509-533.
Tushman, M. L., & Anderson, P. (1986). Technological Discontinuities and Organizational Environments. Administrative Science Quarterly, 31(3), 439-466.
Twain, M. (1876). The adventures of Tom Sawyer. Toronto: Belford Bros.
Ulrich, D. (1997). Human resource champions. Cambridge, MA: Harvard University Press. Van De Ven, A. H., & Poole, M. S. (1995). Explaining development and change in organizations. Academy of Management Review, 20(3), 510-540.
Volberda, H. W., Van Den Bosch, F. A. J., & Mihalache, O. R. (2014). Advancing Management Innovation: Synthesizing Processes, Levels of Analysis, and Change Agents. Organization Studies, 35(9), 1245-1264.
von Hippel, E., & von Krogh, G. (2003). Open Source Software and the 'Private-Collective' Innovation Model: Issues for Organization Science. Organization Science, 14(2), 209-223.
Vujovic, S., & Ulhøi, J. P. (2008). Online innovation: the case of open source software development. European Journal of Innovation Management, 11(1), 142-156.
Waddell, D., & Sohal, A. S. (1998). Resistance: a constructive tool for change management. Management Decision, 36(7/8), 543.
Wylie, N., Sturdy, A., & Wright, C. (2014). Change agency in occupational context: lessons for HRM. Human Resource Management Journal, 24(1), 95-110.
Yates, M. (2000). Developing leaders in a global landscape. In D. J. Giber, L. Carter & M. Goldsmith (Eds.), Linkage Inc.'s best practices in leadership development handbook: Case studies, instruments, training (1st ed.). San Francisco, CA: Jossey-Bass/Pfeiffer.
Yin, R. K. (1994). Case study research: design and methods (2nd ed.). Thousand Oaks, CA: Sage Publications. Biographies:
Sladjana Nørskov is an External Lecturer at the Department of Management, Aarhus University. She received her Ph.D. from Aarhus School of Business. Her research interests include organizational development, user-centered innovation processes, community governance, and new organizational forms.
Peter Kesting is an Associate Professor of Management at Aarhus University, Denmark. His research interests primarily concern innovation management, the cognitive and conceptual foundations of routine and decision-making, negotiations, and the life and work of Joseph A. Schumpeter.
John Parm Ulhøi is a Professor of Organization and Management Theory at Aarhus University. His research interests include organisational development, new forms of organising, human and social capital, and innovation and entrepreneurship. Over the years, he has served as TIM-Division Board Member of the Academy of Management and as Editorial Board member of various journals. He has served as member of various International Expert Boards such as, for example, Directorate-General Research, The European Commission; Israel Science Foundation; European Science Foundation; The Belgian Office for Scientific, Technical and Cultural Affairs; The Research Council of Norway. Figure 1. The growth of TYPO3 depicted as the number of registered developers, references, and extensions (2003-2005).\textsuperscript{1} Source: http://typo3.com/
\begin{figure} \centering \includegraphics[width=\textwidth]{typo3_growth.png} \caption{The growth of TYPO3 depicted as the number of registered developers, references, and extensions (2003-2005). Source: http://typo3.com/} \end{figure}
\textsuperscript{1} The graph shows the number of registered developers from 2003 to 2005. Unfortunately, reliable statistics for the ensuing years could not be obtained.
Figure 2. Model of the moderators of change initiatives in OSS communities
\begin{figure} \centering \includegraphics[width=\textwidth]{change_initiatives.png} \caption{Model of the moderators of change initiatives in OSS communities} \end{figure} Table 1. Topics discussed in the R&D Committee’s mailing list
| Number, # | Governance-related postings | Technical postings | Other | Sum |
|---|---|---|---|---|
| 201 | 21 | 13 | 235 | |
| 85.5 | 9.0 | 5.5 | 100 |
Table 2. Data sources
| Data source | Description | Purpose | Time |
|---|---|---|---|
| Mailing list I | 235 postings from the R&D Committee mailing list | Insight into the contributions and role of each Committee member; an in-depth understanding of the organizational tasks and issues and how they were addressed | 2006 |
| Mailing list II | 1,088 postings from the HCI Team mailing list | Understanding organizational developments within the HCI (Usability) Team. Related to a particular change initiative. | 2006-2009 |
| Mailing list III | 1,191 postings (selected for their relevance from a total of 13,587 postings) from the Core Team mailing list | Understanding the interactions between the core and the periphery and how the interactions developed over time. Actions and reactions related to the identified change processes. | 2006-2008 |
| Interviews | 11 interviews: - 1 interview with the project founder - 1 interview with the community manager - 9 interviews with 9 Core Team members, out of whom 7 were also members of the R&D Committee | Understanding of the community, its history and development, and change in TYPO3. Managing change in TYPO3; follow-up on specific developments and change initiatives. | 2006-2010 |
| Observation | 18 hours (a two-day R&D Committee face-to-face meeting) | Insight into issues regularly addressed by the R&D Committee. The observations revealed a range of organizational issues and | 2006 |
| Archival documentation |
Project description, bylaws, videos of conferences and meetings, summaries of meetings, and news
Learning about the formal regulations and structures of the community. Crosschecking some of the facts uncovered during the observation activities and interviews.
2006-2010
Table 3. The four change initiatives
| Change initiative | Components of the change initiative | Rationale behind changes | Change agent | Outcome |
|---|---|---|---|---|
| Reorganization of product development | New work processes | |||
| Feedback | ||||
| Gate keeping | ||||
| Closer interactions | ||||
| Release management | Motivate contributors via feedback, gate keeping, and closer interactions, which were expected to act as rewards and retention mechanisms. Release management improved after setting up strict development phases. | Core member | Successfully implemented | |
| Founding of a non-profit organization called the TYPO3 Association | Create a committee structure (similar to a functional structure) | Support core development on a steadier basis. Improve the efficiency of the project by "providing a central hub from which to support active developers as well as to concentrate its members into a pool of regular contributors." | Project founder | Successfully implemented |
| New team structure | Establishing 'Team Contracts' for each team. Implement a more transparent structure with clear responsibilities, increased team autonomy, elaborate structure. | Ensure responsibility and accountability for each task and role. | Project founder | Unsuccessful |
| Installing usability as a mindset | Usability as a mindset | |||
| Changing the mindset of developers. | ||||
| Bringing software developers and designers together. | Create a team that would work to increase the usability of the TYPO3 system. Developers usually lack the user perspective. Designers are needed to create more user-friendly software. | Periphery member | Successfully implemented | |
| Individual initiative | ||||
| -------------------------------------------------------------------------------------- | ------------------------------------------------------------------ | |||
| Persistence | You need to be extremely enthusiastic and not afraid of setbacks because you will experience many, and it will take a long time to make changes happen. (Interview, core member) | |||
| Leading by example (creating credibility and merit in the community to gain followers for the change initiative) | But what didn’t work out is that I couldn’t motivate persons just to follow the guidance of my changes. So I created about, I would say, 200 mock-ups. And about 10 percent have been realized in TYPO3 until today. (Interview, change agent) So you need to prove to them that you have the skills and that you are able to assess their solutions. (Interview, change agent) |
| Reputation and reputation lending | |
|---|---|
| Endorsement by high-status members to the change agents | I also realized that [change agent’s name]– who is one of the most active participants in here – has been continuously working on a lot of TYPO3 HCI Topics: |
- […] New Installer 2.0
- Backend interface improvements for TYPO3 4.2
- TemplaVoilá 2 (together with [name])
- Starting to work on Extension Manager 2 (with [name])
- And finally, [change agent’s name] is also an active member of the TYPO3.org redesign group (Core Team mailing list, core member) |
| Redirecting attention and work efforts towards the initiative | > Could you tell us a bit more about this? Maybe in the [developer list]?
Answer: Or HCI, that is. Please continue the discussion there. (…) can you re-send your mail in the HCI list please, once you feel like you want to continue the discussion. (Core Team mailing list) | | Proactive recognition and support of initiatives by high-status members | It’s more of keeping this big overview and picking the cherries. It is a dynamic system. I never have an idea all of a sudden. (…) It’s mostly about things that are already under way. (Interview, core member) | | | You work mostly with the things that are going on and try to find little suggestions or ask someone else: “What do you think about this idea, about this project? Do you have anything to add to that?” (…) It’s mostly that there are already ongoing projects. As a community manager I see, okay, this guy is working on it and this guy is working on it, and I try to connect them. (Interview, community manager) |
| Change-oriented communication | |
|---|---|
| Inform and educate the community about the rationale and arguments behind the initiatives | |
| --- | |
| The breakthrough was the presentation for 5.0 with a guy called [name]. After that presentation, the spirit in the community changed because they saw that it is really possible to do this. […] (Interview, change agent) | |
| I just watched the HCI podcast and was really impressed. Once we get there, we can all be very proud of not only a flexible product but a user-friendly product as well! As an ‘outsider’ to the HCI team, it produced two random thoughts I would like to share with you. […] After viewing the presentation I was overwhelmed when thinking about what it would mean to achieve all this. To really get a consistent look and field, it would require rewriting a lot of code and adapting tons of extensions. Some things like the installer might be easier since it is better modularized. But to achieve major changes, I strongly feel that it would be best to focus on the 5.0 development. (HCI mailing list, developer) |
| Motivation through challenging tasks |
|---|
| Novel task structure and content |
| It was exciting for the developers to use a framework that is so powerful, so new, that has so many functions already inside. By just using the framework, we could use a lot of things out of the box that we could never just pluck into the old system. (Interview, core member) |
| Freedom to work in new ways |
| So removing everything and replacing them with totally new components for the whole frame and for the page tree, this was really [going] to bring something totally new in there. Our coding was driven by the huge set of features that were there. Every one of us was coding in the past and was in a position of coding extensions for a customer […] and to create new menu items was never possible in the past […] So we really at some point had the freedom to drop compatibility and this was quite helpful to go fast forward to say, ok, let’s delete everything and create new. (Interview, core developer) |