At last Friday's meeting, we had a brief discussion of what does an open source project give up by not having a project manager? My mind fills with thoughts regarding this question and I need to capture them since I intend to dig into this question at some point.
For me, a project manager, like any manager, certainly does provide some planning and coordination for the team members. But I think the more important contribution is the leadership she provides. The question has the assumption built in that open source projects do not have project managers. I will comment on this before I consider other aspects of this question.
Any human group will have a leader. As social animals, we will spontaneously put someone into that role or the group is likely to never be productive. The old chestnut from sociology is forming, storming, norming and performing (with mourning a newer addition). The group formed around some shared vision, cause, or need. Often, but not always, one of the chief founders of the group will remain as the leader. Sometimes this will be shared or will pass between people. This brings up new research questions. In an open source software development effort, how can the leader be recognized? Will the topology of communications reveal this relationship? or must more sophisticated analysis be performed? Does the power to make decisions flow to the leader? You might assume it does but it would be interesting to verify that with research.
In the discussion, my primary reaction was that open source software development is different and limited in some way. My comment was that for open source the consumers of the product and the producers of the product are the same. Others disagreed and suggested that it was an overly broad generalization. I can see their point but I still maintain that there is an inherent difference that pervades these projects.
Most open source projects are for products that only an engineer can love. What end user cares whether their web site is hosted on an Apache server? or cares about Eclipse? Most of these projects focus on products that are used by developers or IT. The one exception that comes to mind, perhaps, is Linux. But even there its halting acceptance as a consumer platform reinforces my belief that it is only slightly more sophisticated than a roll-your-own kind of OS that engineers love simply because it is not controlled by a mega-corporation and allows them the ability to play with the insides in a way that other OSs will not. This appeal is unique to the engineers that can appreciate what this openness brings and have the skills to make those tweaks. In short, I believe that open source projects depend upon a subject matter expertise that limits the products that are developed.
One big advantage of this self-selection is the depth of knowledge that can accumulate in an open-source project. Its as if you were a 4 star chef and had to eat at a diner. But instead of being forced to eat what the cook was serving, you were suddenly given kitchen privileges and you started making gourmet meals for yourself and your friends. You know what you want and trying to explain that to someone else who does not know it themselves and to do that with the impediment of required skills is too frustrating. Open source eliminates those barriers.
If I investigated the development of an open source project from its inception, I would expect to see some evidence of storming, the inevitable sorting out of mission and purpose that is needed to motivate everyone. While the original vision might be sufficient to attract one or more people into the project, the mission will continue to be elaborated as the project grows. Like the splintering of Christianity into innumerable splinter groups, open source projects can potentially continue to fork whenever there is a disagreement about either purpose or some other divisive issue like trade-offs or design. What issues precipitate forks? Is there evidence in the project logs which can indicate an increased chance of a fork? What is the success of forks? How often do both branches continue long term?
The discussion on Friday touched on the success of an open source project and what it means for an open source project to be successful. Several of my friends immediately took a commercial oriented outlook focusing on corporate sponsorship, downloads or some other economic metric. But in our discussion, my colleague suggested that some open source projects are motivated by non-economic interests such as the exploration of a new design or product idea that has no obvious economic benefit. I must allow that people can be motivated to participate in an academic project that inspires the sense of exploration. After all, we have had explorers throughout time and the world of cyberspace is certainly rich with unexplored areas.
Young, talented engineers are not necessarily any less altruistic than the people who join peace corps. But unlike engineers who volunteer to install a drinking water system in an African village, a software engineer can make a contribution from the comfort of her easy chair. It lacks the direct reward of the happy people who benefit. Yet there must be intrinsic rewards to the work. Economic theory suggests that if there were no reward for the work, it would not happen.
We briefly touched on intrinsic rewards on Friday but I would be interested to understand the personal rewards gained by these engineers. It is easy to make up stories that may, or may not, be true. Certainly the Hollywood version is some cheetos eating, game playing, socially awkward, post-adolescent who has developed formidable skills at coding who is gratified by the online attention his (and lets face it, its almost always a him) garnered. Among his peer group, he revels in being the best. Competition is fierce among some coders to be the best at what they do. It is reasonable to assume that this is one source of gratification for their work. But would questionnaires support this? How many contributors are supported by corporations like IBM? What influence does this economic support have on the motivations for the other project team members? Does this change the dynamics? Are some of these people working on the project to get hired? Are they doing it to develop new skills? Be mentored by experience coders?
During norming, the project team must decide on pragmatic matters like how decisions will be made and the nature of the license, or lack thereof, for the final product. How new members will be admitted. What type of artifacts beyond the code must be produced? These concerns may have been addressed already but if not, they will surface once the work begins.
My going in position is that the guidance and leadership emerges spontaneously within the group. If the expertise is not there in the beginning, someone will grow into the role making mistakes as they learn. Someone who has prior experience with an open source project may be the natural leader.
If there is to be any vital difference between manager led groups and self-organizing groups, I believe it will be in the area of coercing team members to take on tasks they are not intrinsically drawn to. I believe I heard D call this out as an issue. Staff engineers are hired to develop systems for someone else and not for themselves. This work for pay requires management to adjust performance and reward to ensure that sufficient labor of the correct kinds are available and are properly motivated to do the work. As I suggested above, there is a type of product that seems to naturally gain open source support. If I am right, there are other products that are unlikely to gain this kind of spontaneous open source support. How could these products be categorized? This seems to be a continuum with many models of organization and support available. Can any conclusions be drawn regarding the type of support, or level of support, and the type of product? Am I correct when I assert that tools gain the most support for open source with consumer products generally garnering less?
Finally there is the fact that companies can find ways to contribute to more open source projects. Software may, or may not, bring a competitive advantage to a company. Most of the software companies use is commodity that lends no competitive advantage. A company that insists on having custom software for all automated functions should find itself at a competitive disadvantage as the costs of these custom systems will exceed commodity software over the long-term. This suggests that cooperative efforts, such as open-source software, can lead to lower cost software. The company could still customize some features off the main trunk of the development by lobbying for the sorts of hooks and interfaces that enable their customizations. Having staff members contribute to the project ensures they get the software they want and maintain the skills needed to customize the product for any unique needs they have.
I used the term locus of control in the title. This is a reference to a psychological theory talking about whether a person feels they control their destiny or whether they feel controlled by someone, or something else. A commonality I feel in this discussion of open source software is the sense of internal locus of control they feel. The employee/employer relationship certainly has its good and bad. But it rarely instills a sense of internal locus of control. In the end, perhaps this is the trait that most powerfully motivates the team.
No comments:
Post a Comment