August 14, 2006
Open Source Software
Academy of Management
Professional Development Workshops
August 13, 2006
This is a summary of the discussion in both of the workshops related to improving papers and getting work published. See also the presentation slides from Part 2.
Part 1: Research Development Workshop
The authors of the research papers were grouped into six tables with six discussion leaders. Below are the summaries of each of the discussion leaders
- Be clear in thinking about and selecting the level of analysis for what you are doing.
- Seek consistency of the research question and contribution. Carry the thread through the paper, show how you’ve addressed the questions you’ve said you’ve tried to do.
- What’s different about open source rather than just testing an existing theory?
- Key issues of operationalizing constructs.
- Watch the scope of the research — (as elsewhere) might be too large.
- What’s the best theoretical perspective on the phenomenon you are looking at?
- Work through the analysis issues: push the analysis further given existing data, or decide what new data you will need.
Open source is many different things, whether Red Hat Linux or an early beta from SourceForge. When you are studying “open source,” define what you’re talking about.
Georg von Krogh
- Leverage the phenomenon in criticizing existing theory, to open new debates.
- Or, push the application of existing theories forward. For example, apply social network to open source.
- How do you get these papers through the review process? What community are you writing for?
We all have different perspectives on open source. Step back from your paper — don’t assume the reader knows what you’re doing:
- Make it clear what you are trying to accomplish in the paper
- Explicitly define your terms because similar terms may have different means.
Part 2: Bridging Theoretical and Methodological Perspectives
Co-chair Kevin Crowston synthesized the discussion in the panels:
As Siobhan [O’Mahony said], you have to decide what to put in the foreground — and what in the background:
- Often it’s theory in the foreground. But if so, [as Joachim said] “open source” is too broad a concept to encompass an homogeneous phenomenon: Linux is different from a brand new project on SourceForge. And there are 450 empirical papers there you could be asked to cite
- Foreground could instead be a practical problem in open source [such as licensing].
- Whatever you do, don’t put the data in the foreground.
In the end, you need to answer a key question: what’s surprising?
James Howison presented a series of websites with OSS data: