Team Linux’s Lessons Learned

In undertaking a project like this, there are two key areas where learning takes place: the community and the lab.  The relationships we formed with our community partners and within our group became opportunities for discussion, discovery, and further partnerships.  In the lab, we learned a great deal about technology through frustrations and successes.

Community

First and foremost, we found that building a relationship with our community partner was essential to the process.  Without this, any discussion about technical issues was very difficult.  When entering a new community, listening is often more valuable than speaking, and we found this to be especially true in our project–from the initial communication we had with Pastor Kaitroy to our user testing, we attempted to listen as much as possible to the needs of our users and provide the best solutions available to their specific situation.

Setting up a computer in a community with little access to human capital, technical knowledge, funding, and buildings equipped to house technology (in terms of networking and power infrastructure) was an exercise in the efficient and strategic use of resources. We were able to put the lab together with preexisting equipment provided by MSMBC and the equipment donated to GSLIS.  The challenges we faced required a great deal of teamwork and reliance on the relationship we had established with our community partner.

As a group we feel that seeing the rest of the community and having that larger context for our project immensely added to our experience of the class.  It is important to have a sense of what it mean to have a CTC in East St. Louis.  From our tour of the other sites and our interactions with community leaders, we found that the purpose and intent of the community technology center greatly determines the outcome for the user. There were sites that focused more on the development of functional literacy (i.e. finding a job, using email, learning word processing, surfing the web) as well as sites that emphasized more complex literacy and asked for computer labs with the capability to encourage learning of a sophisticated skill set.  These site coordinators were interested in software that related to sound and video editing, web development, programming, and other creative uses of technology.  This realization suggests that not only do different sites have different technical needs, but that there is a potential for partnership and resource sharing between them.  Moreover, there is a need for flexibility in the implementation plan because there is a wide variety of community needs and interests.  Flexibility can take many forms in the installation of the lab.  Our site in particular wished to use an Open Source operating system because of the wide array of programs and learning opportunities available to them, as well as a desire to avoid the potential of licensing problems across a network. Additionally, Pastor Kaitroy was interested in having a lab that also supported a Windows machine so that children and young adults at the church could continue playing the games and using the programs they had found valuable in the past.  We also attempted to make the network as flexible as possible so that more computers could be added to the lab if it became necessary to do so.

Additionally, we found that the East St. Louis community action efforts occur largely on a micro-level and are not well connected.  We talked with Pastor Kaitroy at length about CTCs linking together and becoming something more powerful for and with greater impact on the community.  MSMBC has already worked with DigitalESL and New Life Christian Center to expand the scope of their small computer lab, but these efforts should be expanded throughout the city.  We recognize that community leaders are dedicated but overwhelmed and often find it difficult to enact real change, but feel that community partnerships and broad-based sharing of resources can alleviate some of this burden while accomplishing true gains.

We would like to see the customized distribution spread elsewhere.  We deliberately made the install disk easy to use and propagate because of MSMBC’s partnerships with other community organizations and interest in giving their older machines to members of the congregation and other sites for whom such machines would be an upgrade.  In the future, we hope to see the MSMBC Linux become a template for an East St. Louis city-wide Linux distribution.  Accomplishing such broad dissemination would be as simple as giving install media to the CTCs, libraries, and other interested organizations.

Technology

We learned to appreciate that technical problems are intimately related to social and economic problems. Throughout the course of our project, we found open source software to be a powerful, if not daunting, set of resources. The free license associated with open source spoke to many of the intertwined social and economic problems experienced in East St. Louis. The concept that software can represent high ideals was new to many of us, though we quickly appreciated how customizable and robust open source software can be.

As a group, we were especially alert to the importance of understanding use cases for CTCs. We used focus groups and user surveys to try to evaluate what the probable use cases are for Morning Star Baptist Church. Afterwards, we strove to synthesize our findings into a coherent picture of the ideal operating system for our site. This picture informed our design process, and gave impetus to our exploration of open source software.

We implemented a patch prototyping methodology, which mainly utilized existing, mature software projects. This allowed us to gain familiarity with major trends in open source development, and broadened our technological horizons considerably. The customization work that we did was also an opportunity to explore operating systems in a more detailed way; we quickly discovered the ‘anatomy’ of a Linux distribution, while simultaneously learning how to shape software for our sites practical needs.

Along the way, we discovered some unique technical challenges in East St. Louis. We had opportunity to hear about how issues like terrain affect community wireless projects. We were all surprised to learn about the important role of security for CTCs. We took away a special appreciation for our community partners, who, while being dedicated leaders, also often work fulltime jobs. This realization alerted us to the need to design sustainable systems that require a minimum of administrative intervention. We particularly garnered an appreciation for simplicity; we tried, wherever possible, to remove as many layers of complexity as possible. Throughout the project, we paid attention to the problem of complexity and entropy, and tried to strike a balance between features and ease of management.

The framework of observing, thinking, planning and acting guided us throughout the project. Our user testing process is a specific instance of trying to apply this model. Of course, we also applied this model in solving other challenges, like networking and software problems. On balance, we tried to deepen our appreciation for technology by conceptualizing it as a tool, rather than an adversary. Open source particularly helped to teach us that computers can be modified, hacked, re-imagined and re-purposed in nearly infinite ways.

Other Lessons

We visited other labs throughout first two trips, including some that had been around for years. Because of this, we designed our site to prevent problems we saw in other older CTCs.  However, we still don’t know the problems that may arise in ours and wish we could go back in a year or two to find out.

In the future, it would be a valuable learning experience for groups to go back to CTC sites that have been built by other 451 classes and work to bring them back up.  This would enable them to see diversity of sites and CTCs further along in their life span, and be aware of potential problems so they can address them at their sites. This could perhaps be a more practical use of time that would accomplish the same purpose as having the entire class visit every group’s current site.

To do what we did takes a significant amount of time (3 trips: acquaint, test, deploy) and accrues significant cost which may or not be sustainable for future classes.  For our particular site it was necessary to make three trips, but this was quite expensive for ESLARP and may not be feasibly in the future considering the current economic crisis.  We’ve been trying to brainstorm ways around this obstacle (day trips instead of overnights, for instance), and would be open to a discussion on the topic in the future.