What Makes an OSS Class Work?

AnimalCoward writes "I teach a Continuing Education courses in OO programming at our local state university. An email was just sent out from the program director asking if any instructors were interested in developing, and teaching, a course in OSS. My question to the slashdot crowd is: What would you want to see in an OSS class? What should be included? Should I bring up all the discussions about liability and multiple OSS licenses? The request didn't state it, but from experience I believe the students would have a programming background ranging from only mainframes to C++ to those with some Java experience."

Comments

Fundementals

[rovingeyes]

May be I am naive, but what else would you discuss in an OSS class except philosophy, legal, ethical and practicality arguments behind OSS? As far as I am concerned, it doesn't matter what programming language background the student has; because OSS class should not be about programming but every thing else surrounding it. For e.g. copyright law and how it relates to OSS, what are different OSS licenses and why are there so many? How can one create their own license and still maintain the spirit of OSS? And frankly the most important question this class should address is - WHY OSS?. I believe that between all the hoopla surrounding OSS, people have stopped asking the fundemental question.

Re:Fundementals

[chris macura]

Lecture 1: OSS. What is it, where is it, and why is it.
Lecture 2: Types of licenses, when to use which.
Lecture 3: How to modify the licenses to allow for various common changes
Lecture 4: Writing documentation: intro to man-pages (how to write them), doxygen, and latex
Lecture 5: Writing readable code: commenting, dependencies, and the merits of white-space
Lecture 6: How to use OSS in CSS (closed-source software), when it may/may not be done.
Lecture 7: How to use versioning systems: CVS, SVN, etc.
Lecture 8: -+
              9: +-- Communication Skills: technical writing (not the bullshit they teach you in english 101)
            10: -+
Lecture 11: Survey of existing projects: why they succedded or failed
Lecture 12: ditto

That should cover it. I'm guessing a one/two credit course.

Re:Fundementals

[Johnny Mnemonic]

You are obviously forgetting that a great deal of OSS software is produced for Windows and other platforms, such as OS X and etc. The first three suggestions that you have have less to do with OSS, and more to do with Linux/Unix--of which OSS is a huge component, but neither requires the other.

The cathedral and the bazaar

[jarich]

http://www.catb.org/~esr/writings/cathedral-bazaar /

Also, SourceForge

Basic tools. Source code management, build systems.

Leadership techniques about getting people to work with you when you aren't paying them and can't fire them.

Get Involved

[Acius]

If you're talking to computer science students, it might be a good idea to have them research an OSS project they like and contribute something to it. I think a lot of students are pro-OSS in theory, but haven't taken the time to actually get their hands dirty with real, live code. If you require them to find and do some work on an existing project then they get valuable experience in researching what's out there, familiarizing themselves with existing community gathering points, etc.

True, a lot of the code they contribute will suck, but that's nothing new. And if they keep trying, they'll get better at it.

A few things...

[Omega1045]

1) Info on licensing and the GPL, etc, etc at some point. Perhaps an intro to FOSS licensing at the beginning, and more details at the end.

2) Coding Standards! I think that good coding standards and commenting are especially important in an OSS project.

3) Using OSS tools: If the student is going to become as OSS programmer, then they really need to know how to use CVS, Bugzilla, etc, etc. I am sure you can come up with a good list of the things a developer needs.

4) Walk the students through setting up Linux, and using its basic functions (grep, etc) and its programming tools (gcc, make, etc). Go over the very, very basic stuff. I programmed for a while in a Wintel inviro in college before getting into an AIX system. It was a shock, and the prof seemed to think that we (me and the other students) had been programming in Unix before. It took me some time to get used to using to tools for development in Unix. Today, you probably also need to go over some command line stuff. I remember it not being that big of a deal, since I was used to DOS. I bet a lot of student today have never used DOS, or it was a long time ago.