The presentation was "An Open Source Culture in the Undergraduate Computer Science Curriculum" by John David N. Dionisio, Assistant professor of Computer Science at Loyola Marymount University. This was a regular meeting of the Los Angeles Chapter of ACM.

Professor Dionisio is a graphics expert and has developed medical information systems. He has been on a freshly launched course funded by the National Science Foundation on Curriculum and Laboratory Development.

Professor Dionisio said there is an impedance mismatch, a disconnect between undergraduate computer science training and the expectations and skill sets required in industry. Undergraduates usually work alone on toy programs or algorithms and throw away their code after they are finished. Industry works in teams on large, modular projects and the code (for better or worse) may have a very long lifetime. Bad software is not necessarily a death sentence in industry. In the beginning software was produced as scholarly work, freely shared and published in what some call a "golden age". Software in industry became intellectual property, a product of commerce or a trade secret.

The open source culture can be considered as a return to our roots and features new development approaches and practices; better development tools, programming languages, and programming environments. The industrial world features increased software complexity and there have been many cases of decreased software quality. Commercial software remains, and probably won’t go away which Professor Dionisio doesn’t believe is a bad thing in and of itself. Open source software is gaining broader exposure and acceptance (including new business models that embrace it) and can be said to have arrived. There are thousands of people looking at open source software and trying to improve it. There are continuing improvements in software engineering methods, techniques and tools.

So how can we take this to school? The Official Open Source Definition (version 1.9) published by the Open Source Foundation, says there shall be no discrimination against fields of endeavor, licenses shall be distributed, must not be specific to a product and must not restrict other software. The license must be technology-neutral.

At LMU, the Open Source teaching framework specifies adaptation, not adoption and the goal is shifted from industries’ goal of productive software development to learning computer science. The curriculum provides team and individual term-length, focused projects. There is emphasis on concise functionality with unit tests. Students will examine sample code, test existing code, and fix bugs. All source code, by faculty or students — resides in a centralized, public repository. As much as possible, everyone’s code is visible to everyone else — sometimes in the classroom, for code review or team fixing. No code is thrown away — it remains available to future "generations". Quality is made easier to attain by inline and online documentation, automated tests, constructive code and a review give and take with collaborative communities among faculty, students, classes and projects. The process provides certain rights and requires responsibilities. Credit must be given where credit is due and people must follow appropriate access and authorization rules even though the code is open. They must acknowledge, understand, and respect privacy, confidentiality, and license provisions and be ethical. Faculty members maintain live organized, searchable, student-accessible sample libraries for their course. Students access the sample code using the same tools and processes that they would encounter outside the educational environment, there are no instructor handouts. This should be a built in notion of the students, to develop working skills and techniques that they will be using in the future.

There are "Derived Works", exercises that involve extending existing code. Student programming projects live beyond the original term and course. There is a focus on existing code and not on newly produced throwaway fragments. Students add and improve unit tests, find and fix bugs, and improve and refactor designs. In a typical sequence, the instructor specifies required functionality and the students submit unit tests. The instructor runs their tests against a library of previous implementations — some good, some bad, to see how their unit test perform. Then the students submit their own code for the instructor specified function and the students' unit tests are run against each other's code. Ground rules for student code releases are to release early, release often, and make their code releases open to everyone. For courses with term-long individual programming projects there are project milestones throughout the term with in-class code review and code sharing for common functions. Projects feed back their results and code to lower division work as examples to the less experienced students.

A hardware + software infrastructure for supporting the teaching framework called "CourseForge" is under development as certain teaching elements are impractical without some degree of automation. It is derived from open source software, and will be delivered as open source software — the system will use itself as parts of the system are implemented. There will be a department-wide source code repository. The organization will be multifaceted organization covering faculty, students, courses, projects, homework and research. It will use tags, versions, and branches and provide a release mechanism for "official" submissions. There will be read-only versions available for viewing over the Web. There will be provision for automated testing and reporting using scripted actions upon source code submission that are configurable per instructor, project, course, or assignment. There will be Web and e-mail feedback summary/reports for instructors, team leaders and individual students. There is a goal to build, test, and run against multiple architectures and operating systems; isolate specific build fixtures for particular software requirements for things like computer graphics and database management systems. Comprehensive build reports will be provided periodically.

There is an online parallel structure of source code repository with appropriate authorizations and integrated links to other Web-accessible information including source code repository, test and build reports, blogs, and community forums. There are several tiers, ranging from individuals to groups and projects that can be reached through searchable archives and contact by email.

There has been an actual exercise in a programming languages course this semester at LMU. It was done manually, there is no automated "CourseForge" available yet as it is a work in progress with more results to come. The assignment was to use JavaCC to implement a parser for a simple language. The assignment included providing a test suite for the parser that would accept strings that belong to the language and reject strings that don’t. The tests should differentiate between lexical and syntactic errors in "bad" strings. The initial "Test Shakedown" was run against the instructor's "control" implementation. This should eventually include more than one implementation, both correct and incorrect, for educational purposes. Four test suite errors were caught. The errors usually occurred because of a student misunderstanding of the requirements of the test. Finally, all of the student's parsers were run against all of their tests. Professor Dionisio presented charts of the test results and discussed the results in detail. None of the tests, including the test of the instructor, caught all of the errors which was a very interesting result. As they ran the test they fixed the code and at the end everyone's parser met everyone’s test.

The findings were that precision is a key as there is a need to ensure a consistent understanding of what is required. This parallels requirements analysis in software development. Tests must cover both commission and omission errors. Tests must be very fine-grained — otherwise a failed test may mask additional failures.

Students found the course to be more enjoyable overall than a conventional programming assignment. There was increased motivation to get things right and satisfaction with working as a team to get everyone's code to "go green". Under consideration for improving the course is improving grading and student assessment, and providing working code with comprehensive tests and full team participation. There is a need for licenses for student projects, particularly after they have graduated, as the results may be replicated at other institutions to insure proper credit is provided.

In conclusion; Adaptation of an open source culture at the curriculum level may improve undergraduate computer science education providing better computer scientists who have a better match with industry expectations. The computer scientists should have increased individual satisfaction, a sense of accomplishment, and have more of a real-world impact.

Professor Dionisio presented a well prepared and interesting talk. He used numerous charts and provided comments and explanatory information that expanded on the displayed information rather than repeating it. (A set of his charts can be viewed by clicking here.) His presentation provided an excellent example of how good Computer Science education in the area of software development should be done. He presented a considerable amount of information very clearly in a relatively short period of time. This summary leans heavily on the material presented on the charts and does not do justice to the richness of the additional details Professor Dionisio provided.

This was another of the regularly scheduled meetings of the Los Angeles Chapter of ACM. Our next regular meeting will be held in December 2005. There will be no regular meeting in November, but a 3 evening Professional Development Seminar on XML will be held on the evenings of November 8, 10 and 15, 2005 at Loyola Marymount University. Check this web site for further announcement.