Choosing a research topic
I’ve been working in the area of libraries and technology for a while—since the late 1970s, in fact . When I was choosing a topic for my PhD, I knew I wanted to do ’something about open source software and libraries’, but turning that vague idea into a researchable topic was a challenge.
I read everything I could find about open source software and projects, and kept an eye on the fledgling research that was being done in the area, but very little of it captured my imagination. I knew that I needed to find a topic that was more than just a description of projects and how they worked. The trick that worked for me was asking myself ‘what is the most compelling aspect of open source software to me?’, while at the same time my husband (who is a contributor to one of the more active wiki projects) said to me ‘come and see what I’ve just done!’. Two things clicked then: people’s abilitity to contribute to projects in whatever way suits them, and the satisfaction they feel when using the software.
My formal research question is ‘what factors influence participant satisfaction with open source application software?’, with two sub-questions:
- what types of contributions do people make to open source application software projects? and
- Do the factors that influence satisfaction with an open source application software project differ for different roles? If they do, in what ways?
I’ve also realised that access to source code has been important in several of my previous jobs. In my first professional position after library school, I worked with a mainframe database management system called SPIRES (Stanford Public Information REtrieval System). Bo Parker’s “An Overview of SPIRES and the SPIRES Consortium.” The Public-Access Computer Systems Review 1, No. 3 (1990) has a good overview of SPIRES and its key features.
The library had commissioned a SPIRES-based application to print catalogue cards—even though this now seems an outdated concept, it eliminated a significant amount of time I spent proofreading typed cards. I only needed to proofread the electronic catalogue entries once, rather than checking every tracing on every added entry card. One of my tasks was to liaise with the developer, identifying bugs and enhancements. I don’t remember why he gave me access to the source code, but I can still remember the feeling of empowerment I got the day I phoned him and said “I think you need to change xxx to fix the problem I told you about yesterday”. He said “why don’t you change it yourself?” and I haven’t looked back since. Thanks, Ron.
That’s one of the things that led me to this topic. I’ll say more about some of the others in a future entry.
1 comment December 6th, 2006
