A Developers Bill of Rights: What Open Source Developers Want in a Software License

In this paper, we study open source developers' perspectives on the nature and structure of software licenses as well as the processes through which these licenses are designed. Recent history has shown that software licensing approaches are critical to the dynamics of the software industry and the open source ecosystem, and thus of interest to the many policy makers and practitioners that follow this part of the global economy. The study is timely, since it informs the debate on the revision of the GPL license, one of the most popular licenses in use. This revision has the potential to shape the software industry for many years to come; hence it is important that the governance process for this revision reflect the needs of the broader software community. Our study employed structured interviews to capture data on open source developers' opinions about software licenses. We focused on how license choices impact the relationship that exists between open source and proprietary software. Our findings reveal that developers are primarily interested in flexibility and choice when considering a licensing approach. Most developers we interviewed used open source licenses to tap into the open source development approach. They chose this option for flexibility in developing a great product, without necessarily espousing any particular philosophy about how the software should be distributed. Developers also generally valued flexibility in the choice of business model for distributing software. The actions of the Free Software Foundation, which is revising the GPL, appear not to reflect the opinions of the broader community, but the agenda of a small minority that may represent as little as 10% of the open source developer community. Sharing data on the needs and perceived rights of developers, both open source and proprietary, will help the software community, industry experts and policymakers to champion a more flexible and responsive approach to sharing and developing software. Policy makers should work to preserve what has made the software ecosystem successful: innovation, community input and involvement, and developer freedom of choice.

Evaluating Total Cost of Ownership for Software Platforms: Comparing Apples, Oranges and Cucumbers

Alan MacCormack reports findings from a review of articles and studies that examine the Total Cost of Ownership (TCO) of different software platforms. In particular, he assesses the "state-of-practice" in measuring TCO, through a comparison of the methods employed and data provided in studies that investigate the costs of competing software operating systems. The results suggest that despite increasing interest in this method of evaluating different software platforms, many studies suffer from a lack of reliable data on which to base conclusions, as well as a lack of consistency in the approach taken to calculate TCO. Furthermore, only a handful of studies gather data from a large enough sample of firms to inspire any confidence that the results are representative of a broader population. While some organizationshave made notable efforts to overcome these problems, more work is needed to ensure greater consistency across studies.

The Alignment of Partnering Strategy, Governance and Management in R&D Projects: The Role of Contract Choice

Firms increasingly look outside their organizational boundaries to identify partners that can improve the effectiveness of R&D projects. The strategy for using partners, however, varies significantly across projects. In some, partners are used primarily to lower development costs and/or supplement development capacity; in others they are used to improve the quality of the final product. How should these variations in partnering strategy impact the governance and management choices made within projects? We examine this question, using data on 172 R&D projects from six different industries. We test hypotheses that examine first, how a firm’s choice of contract—whether fixed price, time & materials, or performance-based—is shaped by its partnering strategy; and second, how this choice subsequently affects the levels of partner integration and partner performance observed in a project. Our results indicate that the choice of contract is a function of a firm’s partnering strategy, more flexible contracts being preferred in projects that seek long-run capability-based benefits, and where partnering relationships are broader in scope. These choices, in turn, impact the benefits associated with partner integration. In particular, higher levels of partner integration are always associated with higher project costs, but are associated with higher product quality only in projects using more flexible contract types. Furthermore, major deviations from the “optimal” choice of contract increase the costs and decrease the benefits associated with partner integration. We end by discussing the implications of our findings, and suggest new directions for future research

Exploring the Duality between Product and Organizational Architectures: A Test of the Mirroring Hypothesis

A variety of academic studies argue that a relationship exists between the structure of an organization and the design of the products that this organization produces. Specifically, products tend to "mirror" the architectures of the organizations in which they are developed. This dynamic occurs because the organization's governance structures, problem solving routines and communication patterns constrain the space in which it searches for new solutions. Such a relationship is important, given that product architecture has been shown to be an important predictor of product performance, product variety, process flexibility and even the path of industry evolution. We explore this relationship in the software industry. Our research takes advantage of a natural experiment, in that we observe products that fulfill the same function being developed by very different organizational forms. At one extreme are commercial software firms, in which the organizational participants are tightly-coupled, with respect to their goals, structure and behavior. At the other, are open source software communities, in which the participants are much more loosely-coupled by comparison. The mirroring hypothesis predicts that these different organizational forms will produce products with distinctly different architectures. Specifically, loosely-coupled organizations will develop more modular designs than tightly-coupled organizations. We test this hypothesis, using a sample of matched-pair products. We find strong evidence to support the mirroring hypothesis. In all of the pairs we examine, the product developed by the loosely-coupled organization is significantly more modular than the product from the tightly-coupled organization. We measure modularity by capturing the level of coupling between a product's components. The magnitude of the differences is substantial - up to a factor of eight, in terms of the potential for a design change in one component to propagate to others. Our results have significant managerial implications, in highlighting the impact of organizational design decisions on the technical structure of the artifacts that these organizations subsequently develop.Organizational Design, Product Design, Architecture, Modularity, Open-Source Software.

The Architecture of Complex Systems: Do Core-periphery Structures Dominate?

Any complex technological system can be decomposed into a number of subsystems and associated components, some of which are core to system function while others are only peripheral. The dynamics of how such “core-periphery” structures evolve and become embedded in a firm’s innovation routines has been shown to be a major factor in predicting survival, especially in turbulent technology-based industries. To date however, there has been little empirical evidence on the propensity with which coreperiphery structures are observed in practice, the factors that explain differences in the design of such structures, or the manner in which these structures evolve over time. We address this gap by analyzing a large number of systems in the software industry. Our sample includes 1,286 software releases taken from 19 distinct applications. We find that 75-80% of systems possess a core-periphery structure. However, the number of components in the core varies widely, even for systems that perform the same function. These differences appear to be associated with different models of development – open, distributed organizations developing systems with smaller cores. We find that core components are often dispersed throughout a system, making their detection and management difficult for a system architect. And we show that systems evolve in different ways – in some, the core is stable, whereas in others, it grows in proportion to the system, challenging the ability of an architect to understand all possible component interactions. Our findings represent a first step in establishing some stylized facts about the structure of real world systems

Hidden Structure: Using Network Methods to Map Product Architecture

In this paper, we describe an operational methodology for characterizing the architecture of complex technical systems and demonstrate its application to a large sample of software releases. Our methodology is based upon directed network graphs, which allows us to identify all of the direct and indirect linkages between the components in a system. We use this approach to define three fundamental architectural patterns, which we label Core—periphery, multi-core, and hierarchical. Applying our methodology to a sample of 1,286 software releases from 17 applications, we find that the majority of releases possess a "core-periphery" structure. This architecture is characterized by a single dominant cyclic group of components (the "Core") that is large relative to the system as a whole as well as to other cyclic groups in the system. We show that the size of the Core varies widely, even for systems that perform the same function. These differences appear to be associated with different models of development—open, distributed organizations develop systems with smaller Cores, while closed, co-located organizations develop systems with larger Cores. Our findings establish some "stylized facts" about the fine-grained structure of large, real-world technical systems, serving as a point of departure for future empirical work

A Methodology for Operationalizing Enterprise Architecture and Evaluating Enterprise IT Flexibility

We propose a network-based methodology for analyzing a firm’s enterprise architecture. Our methodology uses “Design Structure Matrices” (DSMs) to capture the coupling between components in the architecture, including both business and technology-related elements. It addresses the limitations of prior work, in that it i) is based upon the actual architecture “in-use” as opposed to planned or “idealized” versions; ii) identifies discrete layers in a firm’s architecture associated with different technologies (e.g., applications, servers and databases); iii) reveals the main “flow of control” within an architecture (i.e., the set of inter-connected components); and iv) generates measures of architecture that can be used to predict performance. We demonstrate the application of our methodology using a novel dataset developed with the division of a large pharmaceutical firm. The dataset consists of all components in the enterprise architecture, the observed dependencies between them, and estimated costs of change for software applications within this architecture. We show that measures of the architecture derived from a DSM predict the cost of change for software applications. In particular, applications that are tightly coupled to other components in the architecture cost more to change. The analysis also shows that the measure of coupling that best predicts the cost of change is one that captures all direct and indirect connections between components (i.e., it captures the potential for changes to propagate via all possible paths between components). Our work represents an important step in making the concept of enterprise architecture more operational, thereby improving a firm’s ability to understand and improve its architecture over time

Visualizing and Measuring Enterprise Application Architecture: An Exploratory Telecom Case

We test a method for visualizing and measuring enterprise application architectures. The method was designed and previously used to reveal the hidden internal architectural structure of software applications. The focus of this paper is to test if it can also uncover new facts about the applications and their relationships in an enterprise architecture, i.e., if the method can reveal the hidden external structure between software applications. Our test uses data from a large international telecom company. In total, we analyzed 103 applications and 243 dependencies. Results show that the enterprise application structure can be classified as a core-periphery architecture with a propagation cost of 25%, core size of 34%, and architecture flow through of 64%. These findings suggest that the method could be effective in uncovering the hidden structure of an enterprise application architecture

Visualizing and Measuring Enterprise Architecture: An Exploratory BioPharma Case

We test a method that was designed and used previously to reveal the hidden internal architectural structure of software systems. The focus of this paper is to test if it can also uncover new facts about the components and their relationships in an enterprise architecture, i.e., if the method can reveal the hidden external structure between architectural components. Our test uses data from a biopharmaceutical company. In total, we analyzed 407 components and 1,157 dependencies. Results show that the enterprise structure can be classified as a core-periphery architecture with a propagation cost of 23%, core size of 32%, and architecture flow through of 67%. We also found that business components can be classified as control elements, infrastructure components as shared, and software applications as belonging to the core. These findings suggest that the method could be effective in uncovering the hidden structure of an enterprise architecture

Multivariate Unsupervised Machine Learning for Anomaly Detection in Enterprise Applications

Existing application performance management (APM) solutions lack robust anomaly detection capabilities and root cause analysis techniques, that do not require manual efforts and domain knowledge. In this paper, we develop a density-based unsupervised machine learning model to detect anomalies within an enterprise application, based upon data from multiple APM systems. The research was conducted in collaboration with a European automotive company, using two months of live application data. We show that our model detects abnormal system behavior more reliably than a commonly used outlier detection technique and provides information for detecting root causes