It is difficult for many closed source software vendors to embrace open source. Why is this so? After all, over the last years we have come to understand the many business benefits of employing open source as part of a software vendor’s strategy toolbox. In this presentation, I make a first attempt at answering this question (and also include a few remedies). In a nutshell,
open source is hard for closed source vendors, (1) because they have a different risk/reward profile than startups and have a higher fear around legal uncertainties, (2) because they would have to undergo substantial and painful organizational change, easily involving lay-offs, and (3) because current sales incentives are not set up to support cross-selling open source.
This presentation is an alpha release, which is to say, I doubt I’ve nailed it all. Please tell me what you think I’ve missed or where you dis/agree with my thoughts! Because of this, I maintain full copyright of the presentation. Later revisions will hopefully include your feedback (and give proper credits) and will be released under the Creative Commons BY-SA 3.0 license.
As you may seen in an earlier blog post, I’m starting in a new position as a professor of software engineering focussing on open source software at the University of Erlangen. In this post, I’m laying out my abbreviated research agenda as of September 2009.
The overarching goal of my group’s research is to comprehensively define “the next big” software development method. To that end, we will work to unify agile software development methods with open source software development. Agile methods can cope with changing requirements but don’t scale up well. Open source methods can cope with changing requirements and also scale up well. However, open source remains poorly understood as a development method and practices vary significantly from project to project. Agile methods are increasingly being adopted in the enterprise, but it is open source methods that innovate intra- and inter-company collaboration as well as vendor-customer relationships. Given prior significant research on agile methods, the focus of my group’s work will be on understanding open source methods and practices in both an engineering and a business context.
The professorship is well-funded and I’ll be seeking to hire Ph.D. students right away. For my research plans, please see the upcoming blog post. For now, I’ll let my favorite (ex-)Stanford comic strip do the talking. If you aren’t reading Ph.D. comics yet, check it out.
For now, the final paper in this sequence of short publications of how open source software projects document their code. The paper is basically a more comprehensive summary of prior articles, with a bit more of data. Here the abstract and reference:
Abstract: The development processes of open source software are different from traditional closed source development processes. Still, open source software is frequently of high quality. This raises the question of how and why open source software creates high quality and whether it can maintain this quality for ever larger project sizes. In this paper, we look at one particular quality indicator, the density of comments in open source software code. We find that successful open source projects follow a consistent practice of documenting their source code, and we find that the comment density is independent of team and project size.
Reference: Oliver Arafat, Dirk Riehle. “The Commenting Practice of Open Source.” In Companion to the Proceedings of the 22nd Conference on Object Oriented Programming Systems, Languages, and Application(OOPSLA Onward! 2009). ACM Press, 2009. Page 857-864.
My collaborators on the Enterprise Micro-blogging Adoption study at the Humboldt University of Berlin are at it again. In this second step, we are working to refine our understanding of what drives micro-blogging adoption in the enterprise. For this, we are looking for participants in a short pre-test survey. Here the survey summary:
You are using Twitter. We would like you to imagine the use of a Twitter-like system for internal collaboration and communication within your enterprise. We are interested in how, why, or why not you would use such a system on the job. We know that your time is very valuable. However, we hope that you can find 10 minutes to complete our survey. As a thank-you every second participant receives a $5 Amazon.com gift card.
Please help out by taking the survey! You input is much appreciated, and if we get enough contributors, you will certainly read about the results of the survey and the adoption model on this blog.
For my AMCIS 2009 talk on the single-vendor commercial open source business model, first the abstract, then the slides:
Commercial open source software projects are open source software projects that are owned by a single firm that derives a direct and significant revenue stream from the software. Commercial open source at first glance represents an economic paradox: How can a firm earn money if it is making its product available for free as open source? This paper presents the core properties of commercial open source business models and discusses how they work… [more]
Abstract: Design pattern density is a metric that measures how much of an object-oriented design can be understood and represented as instances of design patterns. Expert developers have long believed that a high design pattern density implies a high maturity of the design under inspection. This paper presents a quantifiable and observable definition of this metric. The metric is illustrated and qualitatively validated using four real-world case studies. We present several hypotheses of the metric’s meaning and their implications, including the one about design maturity. We propose that the design pattern density of a maturing framework has a fixed point and we show that if software design patterns make learning frameworks easier, a framework’s design pattern density is a measure of how much easier it will become.
Reference: Dirk Riehle. “Design Pattern Density Defined.” In Proceedings of the 2009 Conference on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA Onward! ’09). ACM Press, 2009. Page 469-480.
You may have noticed the recent discussion about which open source license a single-vendor commercial open source firm should choose for its community offering. In this blog post I’ll argue that this choice depends on the state and speed of the firm.