My Open Source Research Agenda (as of 2009)

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.

  1. Engineering practices. What makes an open source project succeed? What are best practices of distributed configuration management? How to prioritize feature requests in a community setting? Our engineering practices research will address these and related questions, seeking to develop a comprehensive and validated toolbox of open source best practices. The primary research approach is to generate data-driven hypotheses of how open source practices work, to develop new tools based on the newly defined practices, to experiment with these practices using a software forge, and to validate the refined practices definition. In a typical dissertation, the initially analytical hypothesis generation will be followed-up on by substantial open source software development. Examples of such publications are [1], [2], [3], [4].
  2. Single-vendor open source. As the MySQL exit illustrates, open source can be a highly effective and disruptive business strategy, even in a market as established and as conservative as relational databases. Self-sustaining open source communities can help a vendor build a superior product faster and cheaper; in turn the community receives a free-to-use open source project. Beyond engineering practices, open source vendors engage in various business practices to go to market with the open source product. We will investigate and define these business practices and the underlying open source strategies. For this research, we are likely to collaborate with industry partners as well as economics and information systems departments. An example publication is [5].
  3. Community open source. In community(-owned) open source projects, software vendors and individual developers come together alike, sometimes for altruistic reasons, sometimes driven by an indirect profit motive. How to develop software if there is no superior to tell you how it is? How much money and labor to invest into community projects like the Eclipse platform? What’s the return on investment for a strategic non-profit member? The answers to these questions mesh engineering with business practices research. They will inform public policy making as the common good created through community open source may need public seed funding. We will approach these questions in collaboration with the respective foundations, their members, and economics researchers. An example publication is [6].

In most cases, as part of a Ph.D. thesis’ validation, I will require software development. Thus, some work, certainly on engineering practices research, will entail substantial software engineering. This is not only supported but desired by the University, which would like to see research not only to be published in the best conferences and journals, but also to be of significant industrial relevance. The professorship is set up to make it easy to turn dissertation work into (open source) startups, and I’ll be actively supporting this. Application domains of immediate interest to me are software development tools, business applications in the cloud, and social software, in particular wikis. I’m also interested in mobile devices, multimedia, and medical technology.

If you are interested in these topics and would like to perform Ph.D. level work, please contact me.


[1] Dirk Riehle, John Ellenberger, Tamir Menahem, Boris Mikhailovski, Yuri Natchetoi, Barak Naveh, Thomas Odenwald. “Open Collaboration within Corporations Using Software Forges.” IEEE Software, vol. 26, no. 2 (March/April 2009). Page 52-58.

[2] Amit Deshpande, Dirk Riehle. “The Total Growth of Open Source.” In Proceedings of the Fourth Conference on Open Source Systems (OSS 2008). Springer Verlag, 2008. Page 197-209.

[3] Philipp Hofmann, Dirk Riehle. “Estimating Commit Sizes Efficiently.” In Proceedings of the 5th International Conference on Open Source Systems (OSS 2009). Springer Verlag, 2009. Page 105-115.

[4] Oliver Arafat, Dirk Riehle. “The Commit Size Distribution of Open Source Software.” In Proceedings of the 42nd Hawaiian International Conference on System Sciences (HICSS 42). IEEE Press, 2009. Page 1-8.

[5] Dirk Riehle. “The Commercial Open Source Business Model.” In Proceedings of the 15th Americas Conference on Information Systems (AMCIS 2009). AIS Electronic Library, 2009. Paper 104.

[6] Dirk Riehle. “The Economic Motivation of Open Source: Stakeholder Perspectives.” IEEE Computer, vol. 40, no. 4 (April 2007). Page 25-32.

7 Replies to “My Open Source Research Agenda (as of 2009)”

  1. I don’t understand how open source methods scale up well? OSS is not written by hundreds of people – even in large projects there are only a handful of key committers, no?

  2. That’s actually not true. Our preliminary data shows that team sizes scale up with project sizes quite well. This data needs more (presentation) work, so you’ll have to believe me until it is published 🙂

  3. You have a really interesting and relevant research agenda, Dirk. I have definitely added your feed to my reader and look forward to your future posts here.
    You have a good way of asking succinct questions. How can Agile scale like open source in enterprise domains? I come to something similar in my own explorations. For example, I compare and contrast open source from proprietary efforts at community at
    The key seems to be a hybrid approach between crowd-sourcing and traditional team organization. describes current thinking on this from such thought leaders as MIT’s Thomas Malone.
    I’m currently doing a little research of my own on the developer community side of the story. An open source project has to win users and developers. I have started a challenge at which asks what makes a project interesting to the latter.

  4. I’m not sure I’d agree with coding as part of PhD… your agenda is well suited to anthropolocial studies of “why OSS works” without producing code. I’m hoping you’ll find a way to incorporate this angle of attack into your program.

  5. Hey Alistair, thanks for the comment/critique. Programming in itself is not a research activity—it obviously has to have a purpose, like exploring a topic, codifying a practice in a software tool, and thereby ultimately validating or invalidating a thesis.
    I’m emphasizing it here for two reasons. As a trigger to attract students with substantial technical understanding (whether they’ll actually end up programming or not). That’s because in our discipline I think you cannot be a good observer/researcher/anthropologist without prior technical experience, at least for the type of research questions I intend to ask. And also, to increase chances that there are serious open source projects coming out of this research. Now I understand that I could easily defend being a professor of open source who only analyses and never develops, but that’s just not me 🙂

  6. @glenn If you are broadly interested in crowd sourcing as well as Tom Malone, please check out the upcoming WikiSym 2009 at — focus is not only on wikis (narrowly) but on the broader topic of what we ended up calling open collaboration. Also, you may like to hear that Tom Malone himself will be speaking!

  7. Congrats on the new position, Dirk.
    And thank you for banging the drum of getting researchers to produce more than pieces of paper.
    Personally, I am *so* tired of software engineering researchers never writing software, open source researchers who have never contributed to an open source project, and formal methodologists who have never written a specification.

Leave a Reply