1. Introduction 2. Open Source in Computers and Composition 3. Defining Access 4. The Access Research Agenda 5. Access and Open Source Research 6. Conclusion: Directions and Challenges 7. References 8. A Note on Webtext Design

Conclusion: Directions and Challenges In the previous section, I recommended examining where open source software might fit in with any of the questions and projects previously proposed by Moran and other scholars interested in access, as well as research into global open source education initiatives. The people who participate in these initiatives are doing important, on-the-ground work to address the inequitable distribution of technology. As the literacy narratives by Selfe, Hawisher, and their coauthors show, government policy related to technology infrastructure can have a dramatic effect on individuals' literacy at key points in their development. Where might governmental or NGO support of open source software result in improved access for particular communities and individuals? I also recommended using open source software in class as a means to facilitate knowledge transfer with regard to technology and to bring about a heightened understanding of interface design. One way to do this, perhaps as a point of entry into a research project, is by showing open source software interfaces in class. This can be as simple as bringing your laptop to class; if you have OpenOffice installed and an LCD projector is available, you can show the OpenOffice interface to students and have student volunteers come to the front of the room and try it out -- to see how they would do a typical office task using this new program: for example, creating a new file, typing in some text, formatting the text, and saving the file. The student could even do a think-aloud protocol while doing the task. Then the class could make comparisons about the interfaces of Microsoft Office and OpenOffice, elevating the discussion from the low-level institutional outcome of "students need to learn Microsoft Word, Microsoft Excel, etc." to a more sophisticated and abstract discussion about interfaces. Seeing subtle differences in interfaces can help students apply prior knowledge of one program's interface to that of a new program, which moves students toward understanding abstract principles of interface design and facilitates more knowledge transfer. I would argue that classroom research that pays attention to how students use open source technology and its effect, if any, on students' technological literacy, is much needed. From fall 2004 until recently, Purdue University taught technical writing with the Open Source Documentation and Development Project, or OSDDP. Assessments of projects such as these are needed. There are challenges involved in using open source software in schools, and these, too, need to be subjects of research. The most daunting barrier seems to be dealing with information technology staff in schools. These staff members are often suspicious of open source software applications for reasons having to do with security and support. Also on the open source research agenda, then, need to be qualitative, interview- or survey- based studies in specific institutional contexts about IT staff's reservations about open source and how those concerns might be addressed. Vendor lock, an issue raised in the 2008 CCCC resolution on open source software, is another hindrance to higher-order access. Universities' commitments to certain proprietary software companies can be seen even as universities strive to include technological literacy in their assessment efforts; one such assessment package is SimNet, an assessment instrument that essentially measures how well students can execute tasks in Microsoft Office applications. Those interested in access and open source can try designing assessments that ask students to compare a variety of interfaces, then draft outcomes that more closely align with higher-order skills associated with using technology.