Some Simple Economics of Open Source

There has been a recent surge of interest in open source software development, which involves developers at many different locations and organizations sharing code to develop and refine programs. To an economist, the behavior of individual programmers and commercial companies engaged in open source projects is initially startling. This paper makes a preliminary exploration of the economics of open source software. We highlight the extent to which labor economics, especially the literature on 'career concerns', and industrial organization theory can explain many of these projects' features. We conclude by listing interesting research questions related to open source software.     

Network dynamics and knowledge transfer in virtual organisations

Employing a model of knowledge spillovers, we find empirical evidence consistent with both direct and indirect spillovers among open source software projects. We further find that programmers who work on many other projects have a positive effect on the success of a project beyond the effect they have on connectivity of the network. We also find that, both “modifications” and “additions” are positively associated with project success.     

状态监测软件的集成应用

利用动设备状态监测软件开放性的集成功能，进行二次开发，设计编制数据变换程序系统，将来自分散型控制系统（DCS）的温度、电流、压力等动设备的过程参数引人到状态监测软件中，使故障分析工程师能利用多种现场数据综合判定设备的故障来源，更有效地做到预测维修。     

The use and importance of external sources of knowledge in the software development process

This is an empirical study of external sources of knowledge and their relative importance in different stages of the software development process. The amount of new knowledge generated through different sources and the differences between single client, customised and packaged software, are analysed. The analysis draws on case studies of 92, mostly European, software projects, and a pilot study. It shows the length, type, and relative importance of 718 sources of external knowledge in the software development process. The data collected show that there are important differences between tangible hardware and software projects with respect to the relative importance of the various sources and the knowledge acquired from these sources; differences which in part may be derived from the special characteristics of software in contrast to hardware development projects. Frequently the customers cannot specify exactly what they want, which means that the development process must be kept open to customer influence and feedback which may result in changes in the requirements, and subsequent modifications in the software.     

Challenges of open innovation: the paradox of firm investment in open-source software

Open innovation is a powerful framework encompassing the generation, capture, and employment of intellectual property at the firm level. We identify three fundamental challenges for firms in applying the concept of open innovation: finding creative ways to exploit internal innovation, incorporating external innovation into internal development, and motivating outsiders to supply an ongoing stream of external innovations. This latter challenge involves a paradox, why would firms spend money on R&D efforts if the results of these efforts are available to rival firms? To explore these challenges, we examine the activity of firms in open‐source software to support their innovation strategies. Firms involved in open‐source software often make investments that will be shared with real and potential rivals. We identify four strategies firms employ – pooled R&D/product development, spinouts, selling complements and attracting donated complements – and discuss how they address the three key challenges of open innovation. We conclude with suggestions for how similar strategies may apply in other industries and offer some possible avenues for future research on open innovation.     

Coordination of Design Supply Chains for Bundling Physical and Software Products*

Research on product development management has concentrated on physical products or on software, but not both. This article explores a special new product development (NPD) approach in which the internal development of core physical products is augmented by bundled and largely outsourced software features. We studied a medical device producer that has established a new medical information product group (MIPG) within their NPD organization to create software features that are bundled with their core physical products. The MIPG has conceptualized these software features as multiple software development projects, and then coordinated their realization largely through the use of external software suppliers. This case study centers on the question: how can firms effectively coordinate such product development processes? Our analysis of case evidence and related literature suggests that such product bundling processes, when pursued through design supply chains (DSC), are more complex than is typical for the development of streams of either physical products or software products individually. We observe that DSC coordination transcends the requirements associated with traditional “stage‐gate” NPD processes used for physical product development. Managers in DSC settings face a tension inherent to distributed work: keeping internal and external development efforts separate to exploit the design capabilities within a network of software suppliers, while ensuring effective delivery of a stream of bundled products. Many managers face this coordination tension with little, if any, prior knowledge of how to create a streamlined and effective DSC. Our research indicates that these managers need to make a series of interrelated decisions: the number of suppliers to qualify and include in or exclude from the DSC; the basis for measuring and modifying the scope of the suppliers' work; the need to account for asymmetric cost structures and expertise across the DSC; the mechanisms for synchronizing development work across elements of the DSC; and the approaches for developing skills—both technical and administrative—that project managers need for utilizing in‐house competencies while acquiring and assimilating design know‐how from external development organizations. When managers take a flexible approach toward these decisions based on a modular set of software development projects, they can improve their NPD outcomes through technical and organizational experimentation and adjust their own resource deployment to best utilize the suppliers' capabilities within their DSC.     

Time-Driven Development of Software in Manufactured Goods

Microprocessors are being incorporated into an increasingly wide range of products. However, many of the companies that manufacture such products are not effectively managing software development for these embedded systems. Despite the current focus on concurrent engineering and cross-functional teams, software engineering is often poorly integrated with the rest of the product development effort. The result is usually a costly delay in the product's introduction to the market. Tomlinson G. Rauscher and Preston G. Smith describe several practices that have proved helpful for accelerating the development of products that incorporate embedded software. Managerial and economic opportunities for accelerating development of hardware-software systems involve planning for dramatic growth in products that include embedded software, cultivating in-house software knowledge, recognizing the financial effects of project decisions, and measuring project progress. Improving time to market requires hiring and developing software engineering staff and managers with the requisite knowledge of the application, ensuring that they understand the techniques for specifying requirements and design, and providing them with clear guidelines for evaluating the trade-offs between project duration, project cost, and product performance. Progress should be measured in terms of the number of components completed, rather than the number of lines of code that are written. During the development process, emphasis should be placed on managing the scheduling links between hardware and software development, obtaining user feedback about the system as early as possible, and using a flexible, ongoing review process. Development groups should establish software requirements and design parameters before they start coding, and testing should commence early in the system design process. By creating a working prototype of the user interface, developers can obtain user feedback and thereby sharpen the design specification. Effective, timely software development requires focusing greater energy and resources on development of the requirements specification. By expending this effort in the first phase of a project, the development team can minimize its use of the time-consuming code-and-debug approach to software development. In addition to breaking down a complex system into understandable pieces, a modular design supports efforts to accelerate product development. With a modular design, work on various modules can be assigned concurrently to relatively independent teams. A modular design facilitates testing of the product as well as reuse of software that was developed and deployed in previous projects.     

Problem‐formulation and problem‐solving in self‐organized communities: How modes of communication shape project behaviors in the free open‐source software community

Research summary: Building on the problem‐solving perspective, we study behaviors related to projects and the communication‐based antecedents of such behaviors in the free open‐source software (FOSS) community. We examine two kinds of problem/project‐behaviors: Individuals can set up projects around the formulation of new problems or join existing projects and define and/or work on subproblems within an existing problem. The choice between these two behaviors is influenced by the mode of communication. A communication mode with little a priori structure is the best mode for communicating about new problems (i.e., formulating a problem); empirically, it is associated with project launching behaviors. In contrast, more structured communication fits subproblems better and is related to project joining behaviors. Our hypotheses derive support from data from the FOSS community. Managerial summary: We study how the way in which individuals communicate influence the project‐behaviors they engage in. We find that relatively unstructured communication is associated with the setting up new projects, while communication that is structured around an artifact is associated with joining projects. Our findings hold implications for understanding how management may influence project behaviors and problem‐solving: Firms that need to concentrate on more incremental problem‐solving efforts (e.g., because a sufficient number of attractive problems have already been defined) should create environments in which interaction is undertaken mainly via artifacts. On the other hand, if firms seek to generate new problems (e.g., new strategic opportunities), they should create environments in which open‐ended, verbal conversation is relatively more important than artifact‐based communication. Copyright © 2015 John Wiley & Sons, Ltd.     

IS THE GENERAL PUBLIC LICENCE A RATIONAL CHOICE?*

Open source projects are networks of developers, distributors and end‐users of non‐proprietary created knowledge goods. It has been argued that this form of organization has some advantages over the firm or market coordination. I show that for sufficiently convex and modular projects, proprietary licences are not able to sustain sequential knowledge production which, however, can be carried out if the project is run on the open source basis.     

Positional embeddedness in a community source software development project network: the importance of relationship intensity

This study examines those job and relationship characteristics that explain the positional embeddedness of individuals working in a multi‐organization project network. The analysis focuses differentially on three levels of relationship intensiveness: communication, coordination, and collaboration. Data were collected on the work relationships of 46 technical and administrative personnel involved in the Kuali Financial System, a community source software development project involving 12 organizations, 10 of which were colleges and universities, spread across the United States. Results were generally supportive of the hypotheses. Specifically, positional embeddedness was explained by characteristics of the project worker including the task performed, time spent on the task, and influence, as well as the ease of access to others. There was, however, little consistency in the explanatory power of these factors when comparing across levels of relationship intensity. Findings have implications for design of complex research and development projects that involve interactions across multiple organizations.     

Extending private‐collective innovation: a case study

The private‐collective innovation model proposes incentives for individuals and firms to privately invest resources to create public goods innovations. Such innovations are characterized by non‐rivalry and non‐exclusivity in consumption. Examples include open source software, user‐generated media products, drug formulas, and sport equipment designs. There is still limited empirical research on private‐collective innovation. We present a case study to (1) provide empirical evidence of a case of private‐collective innovation, showing specific benefits, and (2) to extend the private‐collective innovation model by analyzing the hidden costs for the company involved. We examine the development of the Nokia Internet Tablet, which builds on both proprietary and open source software development, and that involves both Nokia developers and volunteers who are not employed by the company. Seven benefits for Nokia are identified, as are five hidden costs: difficulty to differentiate, guarding business secrets, reducing community entry barriers, giving up control, and organizational inertia. We examine the actions taken by the management to mitigate these costs throughout the development period.     

Write Code,Save Lives: How a Community Uses Open Innovation to Address a Societal Challenge

This study explores how a community uses open innovation over time to tackle a global societal challenge. we conduct an in‐depth case study of OpenMRS, an open‐source software community providing affordable medical record‐keeping software in developing nations. We develop a process model that describes how inbound, outbound, and coupled open innovation influenced the community through four discrete phases of community development. We explain how the founders’ vision led to the creation of the community, and how increasing community participation and community governance facilitated its growth. Interestingly, we found that economic opportunities made possible by open innovation may paradoxically create challenges to community sustainability. Ultimately, this study expands our understanding of open innovation communities in different settings, and their role in addressing societal challenges.     

Management of development projects: how to meet corporate business goals?

Two contradictory elements affect development projects in the modern era. New advanced development projects require huge resources and long schedules. On the other hand, the resources available for development projects are decreasing, and intensive competition between companies results in increased required performance and new products which must be developed with short schedules. Development projects have a significant effect on a company's business goals, and therefore attract the attention of corporate managers. A significant part of managers' time is devoted to the control of development projects. Support tools are therefore developed and used to assist managers in controlling their projects. This paper describes a control tool to help managers make decisions on development projects. The tool described is based on Microsoft's 'Project' software package, and was developed in-house. The package performs real-time calculations and simultaneously presents several control parameters. These parameters provide a comprehensive picture of project status. The major benefits of the control tools described are: (1) The 'Project' package provides the ability to work with small and combined work packages. It allows attention to be focused on small programs as well as on entire programs. (2) It complies fully with modern decentralised computer systems consisting of a central computer, local computerised networks, parallel PCs and work stations. It provides an interactive quick response ability to follow changes in project status, which result from design changes or progress updates. The control system was implemented by RAFAEL's Missiles Division two years ago, and impressive results in terms of project efficiency were achieved. These achievements play a major role in meeting the Division's business goals. The control tools described are general and can fit a large variety of projects and companies.     

Influence of task type on the relationship between communication and performance: the case of software development

The relationships between communication patterns and performance of software development projects mostly resemble those of technical services, and not development projects, in hardware R&D. The local focus of software development projects in their information requirements is emphasized by the positive influence only of the informal and mostly internal literature, while external contacts, participation in conferences, and formal and external literature were inconsequential. The implications are two-fold: a) on the conceptual level they suggest that a trade-off between coordination and innovation requirements of the task might be an important determinant of optimal communication patterns; b) on the practical level it suggests that 'software development' consists of 'software engineering' and 'software production'. Consequently, it should be recognized that as such, these activities should be managed differently—the former as R&D, the latter as manufacturing.     

Managing the Sources of Uncertainty: Matching Process and Context in Software Development

There is increasing interest in the literature about the notion of a contingent approach to product development process design. This interest stems from the realization that different types of projects carried out in different environments are likely to require quite different development processes if they are to be successful. Stated more formally, a contingent view implies that the performance impact of different development practices is likely to be mediated by the context in which those practices operate. This article provides evidence to support such a view. Our work examines whether projects in which the development process matches the context achieve superior performance. We focus on two sources of uncertainty that generate challenges for project teams: platform uncertainty, reflecting the uncertainty generated by the amount of new design work that must be undertaken in a project; and market uncertainty, reflecting the uncertainty faced in determining customer requirements for the product under development. We develop hypotheses for how these sources of uncertainty are likely to influence the relationships between a number of specific development practices and performance. We then test these hypotheses using data from a sample of 29 Internet software development projects. Our results provide evidence to support a contingent view of development process design. We show that in projects facing greater uncertainty, investments in architectural design, early technical feedback, and early market feedback have a stronger association with performance. The latter relationships are influenced by the specific sources from which this uncertainty stems: platform uncertainty mediating the impact of early technical feedback and market uncertainty mediating the impact of early market feedback. Our results also indicate that while greater uncertainty is associated with making later changes to a product's design, this practice is not associated with performance. Our findings suggest that managers carefully must evaluate both the levels and sources of uncertainty facing a project before designing the most appropriate process for its execution. In particular, they should explore the use of specific development practices based upon their usefulness in resolving the specific types of uncertainty faced. Importantly, these decisions must be made at the start of a project, with purposeful investments to create a process that best matches the context. Reacting to uncertainty ex‐post, without such investments in place, is unlikely to prove a successful strategy.     

Valuation of Learning Options in Software Development Under Private and Market Risk

Commercial software development is an inherently uncertain activity. Private risk is high, schedule and cost overruns are common, and market success is elusive. Such circumstances call for a disciplined project evaluation approach. This paper addresses the use of market and earned value management data in assessing the economic value of commercial software development projects that are simultaneously subject to schedule, development cost, and market risk. The assessment is based on real options analysis, a financial valuation technique that can tackle dynamic investment decisions under uncertainty. The paper demonstrates the application of real options analysis to a development scenario that consists of two consecutive stages: a mandatory prototyping stage and an optional full-development stage. The full-development stage is undertaken only if the prototype is successful and the market outlook is sufficiently positive at the end of the prototyping stage, thus giving the full-development stage the flavor of an option. The project's staged design increases its value. Real options analyses capture the extra value due to optionality.     

关于提高基于OpenSSL软件性能的研究

OpenSSL是用来开发网络安全软件的一个开源软件包,使用OpenSSL可以缩短软件开发周期,提高软件的运行效率和稳定性。但是目前大部分基于OpenSSL开发的软件并不能完全发挥这个开源软件包所具有的高效率和高稳定性的特点。原因在于这些软件的开发人员对OpenSSL的高级应用所知甚少。从提高软件运行效率及稳定性的角度对OpenSSL的高级应用进行论述,提出了2种用来提高软件运行效率和稳定性的解决方法。     

Why makers make what they make: motivations to contribute to open source hardware development

Open source software (OSS) and hardware (OSH) are two expressions of one broader concept and its related movement. One of the most fundamental questions relating to these phenomena is why developers contribute their private resources to these public goods. While this question has been discussed, theorized, and empirically investigated in the context of OSS, there has been no research so far in the context of OSH. Can we really assume the motivations behind the development of the OSH to be the same as those behind OSS? Based on the self-determination theory (SDT), we provide original insights into the motivations behind contributions to OSH development. We collected data from the most common and active 3D printing communities, which are the main loci of OSH development. We thus have a unique cross-sectional data set with participants from over 30 different countries using all kinds of different OSH platforms. Our analysis reveals several important findings: firstly, the motivations are in some aspects very similar to those in open source software notwithstanding different possibilities, hurdles, and incentives regarding the OSS and OSH. Above all, enjoyment-based intrinsic motivation is a major factor affecting contribution levels. Secondly, among internalized extrinsic motivations, expected private benefits through improving own skills stands out. Thirdly, different factors of internalized extrinsic motivations can have different moderating effects on the effect of enjoyment-based intrinsic motivation. Given the imminent changes in business models throughout manufacturing industries in order to adapt to the challenge that OSH will increasingly pose, our findings have important implications not only for OSH communities and 3D development platforms, but also for businesses that want and probably soon have to engage in open innovation.