The phenomenon of Open Source Software (OSS) has been a puzzle for quite some time. People wonder why programmers spend a lot of their time creating open source code without being compensated for their efforts. It is now known that one major reason for this “free” work is that programmers learn valuable new skills. Better skills create better future opportunities, and so programmers invest their time in anticipation of these future rewards. Learning takes place through peer review, which covers the ambit of code submissions. The resulting feedback helps make the software code more efficient. Further, this process also uncovers issues others have faced and helps programmers avoid those problems. The peer review process benefits both, those who conduct the reviews and those who submit their code for evaluation.
One may wonder whether learning from OSS is any better than other modes of learning such as classroom training. While these may be effective in imparting basic skills like a new programming language, working in open source projects is better for learning advanced applications. The reason is that the nature of job content in open source is varied and provides significant new challenges to programmers. Hence, programmers are not limited to learning opportunities that arise in their jobs. Further, access to people across firm boundaries widens the numbers and knowledge profiles of peers from whom programmers can learn new knowledge. Finally, open source code can easily convey a programmer’s worth to future employers as the code is available in the public domain. Consequently, adoption of a training programme using open source work is aligned with the incentives of programmers and so is likely to be implemented easily without any resistance. Thus, learning through open source projects provides a practical approach to training programmers.
Augmenting Programmers’ Skills
Some firms already leverage open source to augment their programmers’ skills. A study sponsored by the European Union and conducted by the United Nations University at Maastricht finds that several companies in diverse businesses such as retailing, automobiles and tourism allow their programmers to do open source work during work hours. These firms are not directly in the business of software and their business models are not based on making money from servicing an OSS product. The only benefit they get is that the skills learnt by their programmers improve their productivity on the firm’s internal projects.
Classroom training methods may be effective in imparting basic skills like a new programming language, but working on open source projects is better for learning advanced applications.
projects due to absence of monitoring. This lack of control in dictating the time spent on each project may result in the programmers putting either too much or too little effort in the open source project. Since the monitoring of performance is sporadic at best, firms may not be able to discover the anomaly in effort quickly. The only way in which firms can deal with this situation is to provide incentives based on performance outcomes of programmers in the open source and the firm’s commercial projects.
Questions may arise about how skills gained from open source projects may prove useful for commercial software projects being done by firms. The answer is that firms must be careful in selecting open source projects – they should be synergistic with the firm’s commercial software projects. For example, programmers who work on commercial game software development are likely to gain significant learning advantages by working on open source game software. The learning from doing such synergistic open source projects is important as exposure to knowledge residing outside the firm in a related area of work may prove to be a new source of creative ideas and skills. In fact, experts such as Tim O’Reilly recommend that even software powerhouses such as Microsoft should let their programmers work in open source for these reasons (http://oreilley.com/news/osconint_0601.html).
Open source participation for employed programmers requires multi-tasking in open and closed source projects. This needs an organisational set-up where multi-tasking is accepted and encouraged. Recently, research has extensively documented the increasing adoption of such organisational forms. This could be due to several factors such as human capital widening (ability to acquire a variety of skills), better information and communication systems, workers’ preferences for versatile job profiles and presence of inter-task complementarities etc.
Working in OSS projects, if synergistically chosen, provides unique informal learning value for participating programmers. This value is enhanced by the fact that the cost of participating in open source is zero (except for the cost of the programmers’ time spent on these projects). However, in order to implement learning from open source projects, firms need to know how best to make this learning mechanism operational within the firms.
Open source participation for programmers requires multi-tasking in open and closed source projects. This needs an organisational set-up where multi-tasking is accepted and encouraged.
This depends closely on a firm’s organisational culture. There are firms that maintain an arm’s length distance from their programmer employees – close monitoring of programmers’ work is considered a strict “no-no.” Then there are firms that closely monitor programmers through tools such as time sheets that programmers routinely fill to indicate how much time they spent on each task/ project.
In firms that do not closely follow programmers’ work, once the flexibility to work on open source projects is given, programmers individually choose the time spent on open source and commercial projects due to absence of monitoring. This lack of control in dictating the time spent on each project may result in the programmers putting either too much or too little effort in the open source project. Since the monitoring of performance is sporadic at best, firms may not be able to discover the anomaly in effort quickly. The only way in which firms can deal with this situation is to provide incentives based on performance outcomes of programmers in the open source and the firm’s commercial projects.
Extra Incentives
An interesting finding in one of my papers is that as the learning-by-doing effects from the open source project get relatively more valuable for the firm, it must provide extra incentives to programmers by providing a bonus for good performance in open source projects. This induces programmers to increase their effort in the open source project to the required level. Left on their own, they do not exert as much effort in the open source project as the firm requires. This issue assumes a further twist if the labour market for programmers is very tight. This means the firm faces stiff competition for the programmers from other firms and must provide high wages to be able to hire the programmers. In this situation, additional bonuses must be paid to compensate the programmers at the market level. If the firm simply increases the bonuses for good performance in the open source project to provide the additional compensation, the programmers
respond by “overdoing” the open source project. To balance this, the firm must pay a bonus for good performance in the commercial project as well. Thus the bonus schemes to compensate programmers are significantly different, depending on the competition for programmers in the labour market.
In another of my papers, I study firms that closely monitor programmers. Such firms do not need any incentive mechanisms to exhort their programmers to put in the right amount of effort in the open and closed source projects. They can simply dictate this effort to their programmers and continuously verify that they are indeed following norms set by the firm. For such firms, the issue is to decide on these norms of effort allocation between the open and commercial projects in the duration of the programmers’ contract with the firm. The interesting thing I find is that the firms must “aim” to get their programmers at a threshold skill level. If their skills are too low at the time of starting the employment, the firm must expose the programmers full time to open source projects to build their skills through better learning by doing. Once the threshold skills are achieved, the firm must change its open source participation norms and split up the programmers’ time between open and closed source projects. Finally, near the end of the contract duration, the firm must make full use of the programmers’ time in its own commercial project and prohibit her from doing any work in the open source project. However, these norms must be reconsidered when the labour market situation warrants paying a high salary to programmers. One smart way to compensate programmers is by providing them higher skills at the termination of the contract. The way to do this is to allow a longer duration of time in which they do both open and closed source projects in the intermediate phase of the employment. This allows programmers to learn superior skills and they can get better opportunities at the end of the employment contract. Leveraging the future value of skills created through open source work is a less costly form of increasing compensation compared to simply increasing programmers’ wages.
To summarise, programmer participation in open source projects can provide a valuable human capital development mechanism for software firms. However, these firms need to employ different operational models to deploy this learning mechanism based on their organisational culture.