ken@campus

"Open source better prepares students for the business world by exposing them to real-world problems and encouraging learning through the completion of real tasks. Open source amplifies a “hands-on” approach to learning by connecting students to a community of users in an effort to solve problems."

Jim Whitehurst, CEO of Red Hat

In a generation that is growing up with Facebook, Orkut, Wikipedia, Youtube; openness, transparency and collaboration are a way of life. Compare that to open source communities which thrive on being open. Even companies today are no longer restricted to a geography or organization boundary but morphing into consortium that thrive on collaboration and participation. And yet how do we engage our students in classrooms? How different is it from the time when Wikipedia and the likes were not around?

Collaborative learning in academia is not new at all. Research students have been exchanging notes, publications for a long time. However, classroom academics hasn’t seen the kind of collaboration yet, baring a few initiatives such as Seneca, Oregon State University (OSU), North Carolina State University (NCSU) and a handful of others. Google Summer of Code showed very clearly that students are capable and interested in collaborative learning, across geography and campus boundaries. The program also shows the role open source project communities can play in supporting such learning and of course grow contributors. Isn’t is time for this phenomenon to scale? As Chris Taylor of Seneca College highlights in his paper “A Model for Sustainable Student Involvement in Community Open Source”, there are some challenges, notably

• Student’s ability to make sense of code base several order of magnitude larger than what they have encountered before.
• Faculty and institutions figuring out how to structure courses in a continuously changing environment where developers don’t rely on textbooks
• Communities themselves are perhaps over-whelmed by lots of questions from novice members while lacking clarity on whether it is worthwhile in terms of contributions they can expect.
• Student projects and courses are time-boxed (start and end date) with crisp evaluation criteria while open source projects in general are driven by goals

ken@campus program is a platform for open source mentors/contributors, students and faculty to take on these challenges. The platform facilitates faculty and mentors to collaborate and structure focused learning around open source and for students to pick up real life problem solving skills and share their development work back with the community under the guidance of mentors. To organize the learning into academic sessions here are a few suggested models.

Electives designed by faculty, projects suggested by participating mentors.

Most technical education curriculum include a combination of ‘core courses’ that drive the fundamentals and ‘electives’ which build on the fundamentals and are often offered as options. Students enroll based on their interest. While some electives are advanced courses, typically electives also have a flavor of ‘application of the fundamentals’ and targeted to help students develop skills required in the real world. Such electives are ideal for open source projects to further classroom learning. These can be application courses such as data warehousing, mobile applications or say software testing as examples, where classroom teaching would cover the introduction and overview which students are expected leverage for hands on projects. The figure below provides high level overview of engagement steps.

1. Faculty member designs elective & lessons
2. Offers elective course to students for a term
3. Student registers and enrolls
4. Faculty member collaborates with open source project mentors to offer projects related to course.
5. Students pick projects (individually or as a group)
6. Student completes classroom lessons & assignments administered by faculty
7. Student also starts working on the project in parallel. During this time students maintains progress under the guidance of mentor.
8. Towards the end of the term student submits project contribution to mentor for evaluation
9. Student also completes evaluation by faculty.
10. Mentor provides evaluation feedback to faculty for final grades
11. Mentor reviews and recommends contribution back to the open source project

Courseware and project co-designed by faculty and mentors

“Open source is an increasingly important skill set that many of today's computer science graduates are lacking. This is not because students aren't interested in open source, but because very few colleges and universities currently offer open-source classes. In addition to eager students, there are many professors who are very interested in teaching open source in their classrooms and labs.”

Jim Whitehurst, CEO of Red Hat

Quite clearly a case for enabling more colleges and universities through co-development of open courseware that would help drop the barriers. Ideal starting point for open source mentors to collaborate with faculty (even better with faculty from multiple institutions participating together) and develop course structure and content with hands on projects for students. Such collaboration not only is packed with efficiency and agility, but also provide the seed for many projects around the core concepts. Kenfuse provides the supporting platform modeled on the lines of MIT open courseware. The suggested engagement steps are highlighted below

1. Open source community represented by mentor(s) and faculty collaborate to develop courseware structure and content (lessons & assignments)
2. Faculty offers course for a term
3. Mentor organization offers project options for course
4. Student registers and enrolls
5. Students pick projects and get assignment to specific mentor
6. Faculty facilitates classroom course delivery
7. Student completes assignments
8. Assignments evaluated by mentor/faculty
9. Student completes project tasks and submits to mentor
10. Mentor(s) evaluate and provide feedback to faculty for final grading
11. Mentor forwards project contribution to project community

Project lifecycle & Project Management

Project lifecycles are expected to be within the duration of a term. The term duration may vary. Students are expected to pick the projects at the beginning of the term and come up with a delivery plan in consultation with faculty and mentor. To facilitate initial learning it may be useful for mentors to use the project documentation page to capture details of setup, coding guidelines, source control systems, community best practices, user groups etc. Since students would be setting out with huge code bases for the first time, it may also be useful to share some details of reference design and code with tutorials or exercise such that students find it easy to get a foot hold.

To track progress on a regular basis students are expected to create issues with specific tasks/assignments and assign to themselves. Of course mentors can also create issues and assign to specific students. Standard project management issue states can be used here to provide students a real life experience to project tracking. Of course for general communication project forums, issue tracker, private messages can be used besides mailing list, user groups etc of the participating project community.

Towards the end of the term students are expected to consolidate their tasks and prepare final submissions. Submissions would be evaluated by mentors and feedback (related to grading) would be communicated to faculty. Optionally mentor can provide subjective inputs to students on their contributions.

Needless to mention, beyond the term students are encouraged to continue following the project and contribute as effectively as possible. After all open source is what it is today due to such voluntary contributions.