Panel 1: Student perspective
One out of four students had no real exposure to FOSS
For non-self driven student, the partnership with Mozilla was key in motivating him to be a successful contributor
One of the students mentions that you can use other people's work in open source
- Question for professors -- How do you leverage that capability to further challenge students? If there are problems they can solve with other people's code, what problems would you prefer they solve individually?
Another student mentions that students are all working on different projects in some of the more collaborative courses
- If all the students work individually on (potentially) completely different projects, how does that affect your workload as an instructor? How does your focus shift away from comparative grading?
Possible improvements:
- Professors involved in open source should have established relationships in the FOSS community -- makes a smoother transition for students
All students indicated that not working on "toy code" was a big draw.
They actually like the fact that students are failed out of collaboration-based classes, and can't drift by under the radar.
"Open source has a much higher overhead from collaboration than organization." Ability to negotiate, communicate are far more important than simply coding skills.
Q: New people are a drain on existing community resources. What would make communities better at ramping up new contributors?
A: Need the right people assigned to help students based on individual needs (working in solitary or together, etc.). If professors have connections already to the open source community, they help minimize drain.
Q: How sticky is open source for a student?
A: One student wishes he could but open source is not part of his work or masters degree -- desire there, not the time. Setting a legacy for future students is important -- you can do that with FOSS.
See David Eaves' slidecast on community management: http://eaves.ca/2007/12/03/community-management-in-open-source-slidecast/
Panel 2: Professor perspective
Lessons:
- Becoming part of the community is important
- Don't push your pet interests, let the students choose from what the community thinks is important
- "Knowledge not shared is lost."
- Also teaching non-coders, people who will formulate, and evaluate systems based on, formal requirements
Require students to publish a 0.1, 0.2, 0.3 during the term, with the expectation that there is work still to be done. Student at this point knows the review process, answering issues/bugs, and how to progress with community-based code.
Some metrics:
- Do they keep the FOSS installed?
- Do they progress measurably in their jobs? Has their academic work affected their careers?
Already talked about how your job changes -- How can open source communities assist faculty in evangelizing FOSS to other faculty?
- For research teaching, very niche -- FOSS is broad and research contributions there may overlap a number of areas.
- Financial support is required to engage deeply in open source. Professors need to administratively justify their jobs/curricula.
- "collegiality" -- it's hard to get professors to accept FOSS when it seems like an in-crowd. Insularity is a community problem.
Identify and use opportunities to effectively engage with larger academic instructor groups. Education-oriented conferences where professors go to learn things???
Good problems for students ==> important, but iterative. Not likely to be simply "finished" and transient. Smaller codebases?
Making sure that we teach the practice of community participation
Value contributors more than contributions
Panel 3: Institutional perspective
Notion of "applied research" -- don't know exactly what it means, but FOSS seems to be a big part of it
Academic institutions help FOSS communities too -- precarious values such as QA, docs, standards propagation (Uta said this)
"patentleft" approach -- apply copyleft to patent space
- Technology that's new and patentable -- dedicate it to open source and use the patent protection to enforce it
Goal for EDU strategy should be to transform academic attitude on open source from maverick to mainstream?