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

License and patent issues

[Frogbert]

Well you could go over the differences in GPL and BSD as opposed to other licenses and have them find out what effects patents have on software.

IT Law

[daveed]

OSS isn't strictly an IT issue. It's a rights issue. Who owns software? software design? concepts? ideas? thoughts? This sounds like what I should have been taught in our semester of IT Law (As apposed to the far too specific individual legal cases to do with Data Protection Act (still very interesting though)). If you were to take this class. A major part of the course would have to be the GPL. This has to be the most clear cut academic outline of OSS. In short... Very good idea :)

Is this for Continuing Education?

[PDXNerd]

You said "Continuing Education" which I translate as "Not-for-credit", or in other words, a class one takes in ones own time which does not count towards anything other than personal satisfaction or career enrichment.

Look at your target audience: beginning to mid-level programmers with no real-world experience. Adults, probably older than college-age, who have families and careers (or not) and are looking to learn. If they take an OSS course, they are interested.

Don't scare them off by jumping straight into philosophy and legalities - explain the history of OSS by exploring what is GNU, why they existed, talk about the split between ATT UNIX/BSD/etc. Introduce Linux. Introduce the wide-range of programming tools available. THEN, and ONLY THEN talk about the details. If you don't pique their interest right off, you are liable to scare them off. Most programmers I know aren't too keen on using their free time to discuss legalities and philosophies. (I know you exist out there, but you are not the majority.)

Re:Fundementals

[sameb]

Indeed. A class on OSS is a business, legal or philosophy class, not a programming class. That doesn't mean CS students shouldn't have an OSS class, but if they do it certainly wouldn't be a programming one.

If you want to do a programming class, use whatever code makes sense in teaching kids how to program. If you want to teach about how to use existing libraries while programming, make that an assignment -- ie, have an assignment that requires building a servlet, or making an http connection, or using various collection utilities.

One problem with many college CS classes is that they ignore existing libraries. Yes, students need to learn how to do a bubble sort and build a linked list and prevent collisions in hash maps... but, students should realize and understand that it is often counter-productive to build these utilities themselves, especially when the existing ones are so widely used (meaning they're heavily documented and debugged).

Re:Fundementals

[greginnj]

What else you ask?
Uhhh, I just thought of an important one. What about "how to make money?"

On this point, I think the example of Zope is illustrative. Investor Hadar Pedhazur was willing to pony up venture capital to fund Zope Corporation, on the condition that they open-source Zope. I'm not really a Zope fan, but the idea of an investor requiring a company to open-source their principal asset struck me as a hard-dollar vote for the value of OSS.

See this for refs:

http://www.faqs.org/docs/ZopeBook/IntroducingZope. html ("Zope History" section)

More detail:

http://washington.bizjournals.com/washington/stori es/1999/05/24/focus4.html

Re:Get Involved

[kbielefe]

I would take this idea even further. If it is a semester-long class, I would make the term project be to get a patch accepted in an open source project. You learn a lot in the process of getting a patch accepted, most of which is not related to coding at all. You learn how to gain rapport with a community, how to find and fill a need in a way that is acceptable by all members of the community, and how to follow through. These are the aspects that are really different from closed source programming.

The patches don't have to be huge leaps in usability in order to be useful. There is a lot of stuff to do if a reasonable effort is made to look. Some suggestions:

• Pick a bug from the bug database. There are some bugs that get ignored because the main developers can't reproduce them.
• Update a plugin or theme that broke when the parent package was upgraded.
• Ask on the mailing list what needs work and would be good for a newbie to tackle. I almost guarantee they will have a list they haven't gotten around to.
• Try out a lot of different open source applications in different ways. I once found a one-line bug in an app because I was trying to import a unique file. I was only evaluating the app for a few hours, and I decided not to use it, but my tiny fix is still in the code base.

This might even work for classes with non-coders. Updated documentation is sorely needed for many projects and the process of getting it accepted is similar. Submitting a unique and useful bug report might be another acceptable project for non-coders. Correctly answering 10 questions in a support forum might be another.