Slashdot Mirror
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."
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.
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 :)
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.)
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).
Obviously the other posters are correct about the OSS mentality being a major, if not the major area.
However, I think perhaps if you were to take a look at some interesting open source applications, and come up with some changes you could implement (or even ask the class to implement). Showing them that with OSS they have the power (and right) to go in and change everything from an OSS, to a egg timing widget, might demonstrate the control and empowerment use of OSS can give.
We have a dedicated Software Engineering degree (not a single course) where marketing is one of the courses (1 semester only, though).
Not that there is much to be expected from it; it's the same senseless unrealistic bullshit that is common for all courses I visited so far.
Well I would tend to say this would be a topic best suited for a one-time seminar, or as one topic within a larger class. You should cover the legal, ethical, and business aspects of OSS, as well as maybe an introduction to some popular project, common tools, etc. HOWEVER, you as an instructor have a duty to present an unbiased view. To offer a class specifically about OSS is the same as offering a class on say .NET programming or on Oracle. This is a biased view of the world. Ultimately, the programming concepts should be the same, regardless of whether your source is closed. You still need a methodology, you still need well written code, you still need efficient algorithms, you still need design patterns, etc. That doesn't change. In reality, OSS is more of a business model than a particularly technical topic. Don't offer an "OSS programming class" -- that's just "programming class" with an OSS bias. Rather, discussed as a one-time topic, just to get students aware of what OSS means and how it might impact them. The programming concepts should remain independent of the business model.
-James
Each of these topics could form the basis for a semester-level class by itself. I'd do one lecture on each of the first five topics, then pick a language and toolchain and do the rest of the course in that language. Call the course "Developing OSS in C"
Are you sure he wasn't proposing a course on Operational Support Systems (OSS)? http://en.wikipedia.org/wiki/Operational_Support_S ystems.
I'm not an OSS guy, but coupled with some sort of "management of IT systems" and a more IT-oriented course, an OSS element would probably be really useful.
Contribute to the online videogame encyclopedia: GamerWiki
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
More detail:
http://washington.bizjournals.com/washington/stor
Read the best of all of Slash: seenonslash.com
Lesson 13: How to make OSS profitable.
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
Here's an overview of the topics I'm covering this semester in an OSS course I'm co-teaching. The audience is undergrads at a major university...
Note that we were also trying to improve the general technical literacy of some of the CS students.
1) Open-source Projects -- History, Present, and Future
2) Unix Philosophy -- ESR's "Art of Unix Programming" was incredibly useful here
3) Using the Unix Toolchain
4) Using the classic text editors (Vim/Emacs)
5) Learning Python / Programmatically Manipulating Text
6) Source Control Management Systems
7) Bug-tracking
8) Open-source team communication
9) Licensing your OSS (the intention is to have a working project completed by the class in Python by this point)
Right now we've just passed #4 and have settled on a simple project (a Web app) that the class can work together on in Python. That way, we can use it to demonstrate how to use the tools we talk about in topics 5-9.
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:
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.
This space intentionally left blank.
My advice: ask your students to look at one of the big OSS project its bugzilla. They all have a few bugs which have a history of YEARS. Tell them to pick such one out, and comment on its history (why, how, who, where, when).
They'll get a feeling for the complexity of software projects. As a side dish, let them fix the bug.
8 of 13 people found this answer helpful. Did you?