Managing with Power by Jeffrey Pfeffer presents a very detailed and comprehensive analysis of power in all its different forms. The author painstakingly reviews numerous sources of power, strategies and tools to employ power effectively. The central message of his “clinical diagnosis of power” (p. 300) is that power is a necessary condition for action. In fact, even the most brilliant ideas require power to be developed, diffused, and executed.
The book, although deeply rooted in the literature, has been accused of cynicism. Many of the “heroes” presented as examples – prominent individuals, smart enough to get power and keep it, at least for a while – seem to perceive power as a zero-sum game. In this view, every means to get power can always be justified by the ultimate goal of “getting things done,” a mantra repeated many times throughout the book.
While this is probably true of the Machiavellian examples that Pfeffer included in the book, his relentless categorization of forms of power can also be read as a practical manual for the brilliant, honest member of an organization that just needs enough power for having his voice heard and make a change.
Indeed, the wide spectrum of categories of power represents a valid toolbox that can be applied to different situations and contexts. While the chapters of the book can be seen as different components or features of power to be activated or not depending on the specific case, the interaction between these elements is crucial to analyze real-life examples.
Here I would like to apply some of the most relevant elements of power to the case of the Open Source community, with the aim to show how Pfeffer’s points are valid even in a context that is sometimes perceived as unconditionally egalitarian, collaborative and open.
The Open Source community
Community is the key component of Open Source software (OSS) development. OSS is in fact based on the free access and redistribution of the underlying code, which each developer shares with the community of developers as a global collaborative effort towards the production of what was seen as a common [1].
Software developed as Open Source is widely adopted and its production model is so successful that some of the leading software companies in the world – including Microsoft – heavily invest in it. The model is based on a bottom-up structure, a non-coercive organization and a largely decentralized production [2]. OSS developers share a common culture (“hacker culture”) and ideology that, especially during the early days, has been called “Microsoft-phobia” [3]. This “alternative” view of software also derives from purely technical considerations, as commercial software is perceived as not totally reliable, and is consistent with the principles of self-production and user-driven innovation [4].
Entering the Community: Power Diagnosis and Allies
According to Pfeffer, the first step to get power is to diagnose “the relative power of the various participants and comprehend the patterns of interdependence” (p. 49). It’s important to define the relevant political sub-units, the existing social ties and reputational and representational indicators of each individual. Bergquist and Ljungberg [5] studied the case of a newbie (an inexperienced newcomer to OSS development) that wishes to enter the OSS community. They highlight the importance of studying the existing social interrelation and networks as well as community norms and values (p. 312).
In particular, to establish a sense of loyalty to the community, a newbie should understand the power relations in order to make allies. As Pfeffer points out, making allies is a crucial strategy to get power. Allies can be acquired thanks to obligations and favors. In the OSS community, the whole game is based on the “mutual interchange where one gift is given to another,” and a sort of interdependence is created between the giver and the receiver [5]. A complex network of givers and receivers then forms, in which the relations can be one-to-one but also one-to-many. The search for allies takes place on the Internet through the shared on line tools of communication. There, conversations are not only public but also private, with gathering of alliances mainly through private conversations, followed by an alignment of the arguments in the public forum [6].
Reputation, Performance and Formal Authority
In “Managing with Power,” Pfeffer points out that formal authority, reputation and performance represent a key source of power and are interrelated.
Reputation, in terms of peer-recognition and prestige, is one the main driving factors that motivates OSS developers to work and share their products with the community [7]. In the first place, reputation derives essentially from performance. The quantity and quality of the code produced are easily recognizable thanks to the shared on line tools of production (such as the platform GitHub), as a signal of the quality of the individual programmer [2]. As Pfeffer highlights, this is a quite rare case in which performance can be measured in a quantitative way.
Once a developer obtains enough reputation, he also gets some sort of formal authority within a specific project through direct invitation. Sack, Détienne [8] studied the existing hierarchies among Python developers. Members’ levels span from the newbies at the bottom of the pyramid to Guido Van Rossum, the developer who founded the project Python.
Figure 1 – Sociotechnical stratification of roles in the Python project
Source: Sack et al. (2006)
Pfeffer maintains that formal authority “confers control over certain resources and the ability to take certain implied or specified actions.” In fact, high-level members of the OSS community have the power to control crucial resources.
First, they control the source code. In the case of the Python project, although the source code is stored in CVS files that can be read by any member, the write privileges are given only to a subset of developers, with evident asymmetries in power relations [5]. Second, high-level members of the community can monitor and sanction members behavior. For example, they can “ban” or “mute” a member due to “flaming discussions” or “trolling” [9]. Third, even though the discussion on software development is open to anyone, Sack, Détienne [8] found that some members – especially those with formal authority – can influence the discussions on specific topics and so have an impact on the decisions on product development. The sequence of public messages in the Python forum and the links between them suggested that influencing people can deviate the course of a discussion and focus on specific arguments and line of work.
Location in the Communication Networks
“Managing with Power” includes a chapter on the role of communication networks and the individual position in the communication structure. According to Pfeffer, “People who are well placed in the communication network also tend to be central players in terms of power and influence.” Information and knowledge are therefore crucial sources of power, deriving, among other things, from social relations and connections.
In particular, network centrality can measure the degree of influence that an individual can exert over the structured tasks of a project. In the case of Python, Ducheneaut [10] looked at the evolution of the network position of the developer “Fred” from January to October 2002.
Figure 2 – Developer “Fred” position in the communication network of a Python project
Source: Ducheneaut (2005)
Fred is presented as a case of “successful socialization,” since he could manage to gain a central position in a specific project within the Python community in less than a year. At the beginning, although he has a strong background in Phython development deriving from professional experience in a software company, Fred does not know how the community works and starts asking questions. Then “By making connections with some of the project’s participants, Fred is trying to make the structure of this network more visible to himself […] discovering in the process which parts of the network relate to his work” [10]. Once he gets the reputation of a good “bug fixer,” his role in the communication network is more and more crucial as other members join the project. In October 2002, he has definitively acquired enough power to influence the group decisions as soon as Fred’s proposal to introduce a new software module is approved by the community.
In conclusion, the case of the OSS community shows that power dynamics matters in a context that sometimes is seen as the panacea of distributed collaboration. According to Bergquist and Ljungberg [5], “One easily gets the impression that the sharing of gifts in online communities creates a very friendly and altruistic atmosphere. And indeed it does, to some extent. But it does not mean that social stratification and struggles over power cease to exist.” In fact, developing software is inherently a political process.
CC-BY luigireggi 10 d'octubre 2015
1. Benkler, Y., Coase’s Penguin, or, Linux and “The Nature of the Firm”. The Yale Law Journal, 2002. 112(3): p. 369-446.
2. Bonaccorsi, A. and C. Rossi, Why open source software can succeed. Research policy, 2003. 32(7): p. 1243-1258.
3. Dalle, J.-M. and N. Jullien, Windows vs. Linux: some explorations into the economics of Free Software. Advances in Complex Systems, 2000. 3(01n04): p. 399-416.
4. Von Hippel, E.A., Democratizing innovation. 2005: MIT Press.
5. Bergquist, M. and J. Ljungberg, The power of gifts: organizing social relationships in open source communities. Information Systems Journal, 2001. 11(4): p. 305-320.
5. Divitini, M., et al. Open source processes: no place for politics. in Proceedings of ICSE 2003 workshop on Open source. 2003.
7. Greiner, M.E. Leadership behavior in virtual communities. in Proceedings of the 7th Annual Conference of the Southern Association for Information Systems. 2004. Citeseer.
8. Sack, W., et al., A methodological framework for socio-cognitive analyses of collaborative design of open source software. Computer Supported Cooperative Work (CSCW), 2006. 15(2-3): p. 229-250.
9. Markus, M.L., B. Manville, and C.E. Agres, What makes a virtual organization work: Lessons from the open-source world. Image, 2014.
10. Ducheneaut, N., Socialization in an open source software community: A socio-technical analysis. Computer Supported Cooperative Work (CSCW), 2005. 14(4): p. 323-368.
0 comentarios:
Publica un comentari a l'entrada