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."
It would be nice to cover the aspects mentioned in the previous replies, but having some instruction on how to get started with OSS (SourceForge, using CVS, etc.) would also be helpful.
The Army reading list
Even though you are trying to sound funny, I think two sections - "How to sell an idea" and "How to develop a business plan" will probably be invaluable. The key to success of an OSS is how much you can get funding in VC and how long you can keep them happy. Obviously this means profiting from the business model surrounding the product. So not only do you have to be a good at marketing yourself or the product, but you should have some business sense to make that project a success.
It seems there's a lot of amll 1 lecture topics, but not many big huge things
*philosophy of OSS, and OSS vs Free Software
*Differences between the major licenses (GPL, LGPL, BSD)
*Major OSS successes
*OSS development tools (sourceforge, gcc, ddd, etc)
*A project where they fix a bug in an open source program of their choice (or add a feature), and submit it to the maintainer.
*OSS buisness models
Other than actually coding some open source software, there's really not much I can see teaching to make it a whole class.
I still have more fans than freaks. WTF is wrong with you people?
I recently taught a course in OSS at the graduate level. I wrote a small summary which is available here: http://turingmachine.org/~dmg/temp/ossEd.pdf, and a presentation here: http://turingmachine.org/~dmg/temp/ossEd.pdf
Of course should reflect the level of the audience. My course was research oriented.
There are, however, 4 areas that I would stress they are covered in a OS SEng course:
* Intellectual property and licensing
* Social aspects
* Motivation
* Organization..
* SENG Issues (tools, methods, etc).
* Economics issues
* Why to use OSS, how to make money, etc.
On thing that I introduced in this course was an etnographic study: students had to participate in a project, and submit a contribution. That was one of the parts that
students liked the most because the were able to experience OSS first hand. I strongly
recommend doing it.
My materials are available if anybody is interested.
dmg
If your students are not running Linux, and their backgrounds are in the Windows and mainframe worlds, then it might be best to approach OSS from the Windows side. This is especially true if your student's are not willing to install Linux on their own boxen or on whatever they may use at their place of employment.
So, be sure to include Windows based OSS programs such as found on the Open CD and check out the the source forge osswin site at http://osswin.sourceforge.net/.
You need to give them a flavor of what Linux is like to be sure, so include Knoppix in the mix somewhere.
It sounds like your course will be for programmers. If so, then introducing them to Cygwin would be a good idea. You may even wish to run KDE under cygwin on Windows (see http://kde-cygwin.sourceforge.net/
For development tools you should cover the creating programs from the command line using make, etc., but also cover OSS IDE's -- Eclipse in particular would be a good one. And of course use g++ for C++ and Sun's java (I am not a purist so I think Java's Sun will suffice but Sun's Java is not regarded as true OSS, so you may need to find something else for Java.)
If you use g++ with cygwin on windows, then also consider introducing them to minGW so they can make their programs run natively on windows.
I run both windows and Linux at home, and prefer Linux. But at work I have to use a window box. I have cygwin with X installed and use both firefox and OpenOffice as replacements with no problems. I am posting to let you know about the windows possibilities because I beleive that you may encounter some resistance if you require your student's to run Linux. OSS on windows is a good way to introduce those who are new to OSS and Unix like file systems and tools to newbies.
So work on finding a way to explain "source code" to non-programmers. Good luck.
I've actually had little difficulty explaining "source code" to people. It takes me about 20 minutes, and contains the following content:
1) The computer can only understand 1's and 0's. This is how you instruct it how to do at a low level. It is possible to make an "executable" file using only 1's and 0's, but this takes a long time and is pretty hard to do. Most programmers can't even understand what the 1's and 0's mean.
2) Each kind of computer has an "assembly language". This is basically using short cryptic words to represent the commands you make using 1's and 0's. It makes it easier to program, but is still really hard. You use a special program called an "assembler" to make an "executable" program. (An executable program being one you can click on to run.)
3) Most programmers use a "higher level" programming language, which also allows them to structure and comment their instructions for the computer. While it is still hard to understand, it is much, much easier than either "machine code" (1's and 0's) or "assembly language" (short cryptic words).
4) Being able to see the language that the program was written in makes it much easier to understand what the program is doing. This is called looking at the "source code". "Source" because this is the words that the program was written in, and "Code" because it is still a tricky language you need a programmer to understand. A programmer looking at the "source code" though can figure out how the program works and even make improvements. If they don't have the "source code", it is really hard to tell what the program is designed to do by looking only at the "machine code".
The only people I have ever found to have difficulty understanding this are those with an attention span under 20 minutes. Unfornately, this may include many managers. Hopefully it does not include the students taking a class on Open Source Software (whom one might suspect might be familiar with what "Code" means).
Atanamis