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."
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.
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 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
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.
Agile Artisans
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 :)
Now is that freedom or beer?
Paul Grosfield - the quicker picker upper.
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.)
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.
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.
Acius the unfamous
What would you want to see in an OSS class?
Girls
Ignorance is not a crime; neither should it be a way of life
Congress control $ = inmates run the asylum
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.
Great ideas often receive violent opposition from mediocre minds. - Albert Einstein
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?
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.
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
Indeed, it is very important to project a professional image, especially if you're a developer who wants your project used by businesses, governments, universities and other serious users.
One important thing to do is to not insult your users/clients/customers. While it is fairly rare, thankfully, every now and then a rogue open source developer will make comments that tarnish the reputation of an open source project.
So please, consider teaching something about professionalism. It will help in many ways, be it in a marketing sense (projecting a reputable image) or in a financial sense (making your project appear financially viable).
Cyric Zndovzny at your service.
Lecture:
Microsoft is Evil(TM).
Review:
Microsoft is Evil(TM).
Test:
Microsoft is ______________.
A) Evil(TM)
B) Mostly Evil with nice pockets here and there.
C) Not very Evil.
D) All of the above.
"A microprocessor... is a terrible thing to waste." --
GeneralEmergency
Trolls 1401: How to avoid nonsensical debates, unless you don't want to.
MS Math 1402: Adding up total cost of ownership.
Zoo-ology 1301: Using O'Reilly manuals.
Photography 1501: Online Porn.
Rhetoric 1502: Comments as code.
Law 1502: Understanding Software Licenses.
Anatomy 1101: Using man pages.
Geology 1502: Unix scripting in Perl and Ruby
Here's to losing my Karma Bonus again....
When I was an undergrad -- only a couple of years ago -- we had a faculty member who was very interested in patterns, and taught a course on them under the guise of an agile class (a good way to do it, I think).
Anyway, we split up into teams and did a project (a wiki server, in our case) and we did everything in an XP-ish way: user stories, refactoring, pair programming, the whole bit. I think you could do an OSS class in much the same way; have the class decide on a couple of projects based on interest, then teach the class in a more "studio" style. That is, use about half the lecture time to teach them how various OSS projects have operated in the past, then have them do the same thing with their own projects. And, as issues arise, as they always do, spend a few minutes here and there addressing them.
Students could also choose a project they like, but is perhaps still in its infancy stage, and have them make a plan to modify and extend it. If you really want to go for realism, you should see if you can find a faculty member teaching a similar class at another university and have them get a sense of the "distributed" flavor of OSS, with some part of each team being at the others' campus. (Granted, much OSS development happens at corporations these days, but most of the really cool projects start out with a small group of folks developing something in their spare time, usually for fun and/or their own use).
I think a big part of evaluating their work would not be to determine how much code they wrote (although everyone should have to write code, if for no other reason than the experience), but rather to determine their contribution to the team. For example, if a student refactors a few Java classes or something so that other development goes a lot faster, then she should get plenty of credit for that.
The moral of this story, then, is that since people learn well by doing, they should spend most of their time doing.
If it's not one thing it's your mother.
A class on OSS is a business, legal or philosophy class, not a programming class.
...)
Perhaps. But I've seen firsthand how difficult the task can be when the "student" has never done any programming. Remember that OSS stands for "Open Source Software". How do you explain that phrase to someone who has no concept of what "source code" is?
I've tried this on occastion, typically with managers. But I've found it impossible to explain to them why I need this mysterious, incomprehensible stuff called "source code". Why can't I just examine the program itself? (Well, yes; given the right tools, I could. Given a lot of time
One of the main reasons for OSS is that if you (or your people) can't get at the source code, a program could contain anything at all, and you'd never know until it was too late. There could be spyware or some sort of time bomb hidden in there. The code could be quietly linking your machine into a network of zombies for running other people's code. There could be a routine working for a competitor, silently and subtly sabotaging your operations. Without the source code, and people who can read it, you're just volunteering to be a victim of whatever the software supplier wants (or has been paid) to foist on you.
Such considerations are not what most people would call "philosophy", of course, and you don't get much business or legal attention to this topic. But it's one of the primary things you need to get across. It's why OSS has been making inroads into Microsoft's turf in so many governments lately.
But how do you explain this to people who don't understand the phrase "source code"? About all you can do is take an authority-figure stance, and tell them that they have to accept it whether or not they understand.
This isn't likely to be very persuasive with most business or legal people. Or philosophers, for that matter.
So work on finding a way to explain "source code" to non-programmers. Good luck.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
There's not much in it. That right there may drive them right to closed source everything.
OSS is held up today as the model of what software should always and forever be. It isn't and shouldn't be. It's one tool in the box.
And it is a variable tool between the BSD, GPL, etc. license forms. Or write your own. Or go with classic freeware. Or make it shareware. Or closed altogether. Or partial. Where it ends and the rest of the box begins is and should be murky and totally dependent on what you are doing.
After all, it is the coders' time. If they don't want to write code that isn't open, they're limiting their job spread. If they're willing to do it either way depending on the requirements, that would be better.
What do they need to know technically? That using OSS' all too common attiude that "it's free, so what do you want?" with regard to quality is the sort of thing that is coming around slowly to bite it in the butt and ethical programmers will not use OSS, or anything else, to cover their backside instead of doing it right the first time.
OSS or CSS or somewhere in between, it is what is learned in the guts of the CS course that matters and how it is done and what is done is a distant third.
If my grammar and spelling are off, I am [distracted/tired/careless] (take your pick)
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
... most OSS dev's couldn't give a fuck about their users...
And that's fine! But then those same developers shouldn't wonder why their product fails to get used by governments, businesses, educators and other serious software users.
Now while a lone developer may not care if their email fetching program becomes widely used, it's often the opposite for larger projects.
It's particularly sad when one rogue developer who publically throws out insults is able to tarnish the reputation, painstakingly built up by many people over many years, of a project like KOffice or KDE.
Cyric Zndovzny at your service.
create another Slashdot.
God help us.
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
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
Show both to boss.
(YMMV according to the boss's hair pointyness...)
I'd really let them have a go at python, it's a great language and allows for RAD of pretty much any kind of application, can talk to virtually everything that talks back easily and well.. google uses it for a great amount of projects which at the moment speaks for itself.
Of those to whom much is given, much is required.
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.
You probably really want to chat with the program director about what the class is supposed to be about; it could be anything from "how to use OSS for regular computing" to "how to start a successful OSS project".
I think it would be good to have a class on how to get involved with an OSS project. There are a number of things that are a bit unexpected if you're coming from an industry development background, such as:
People are really blunt. If you do something wrong, your work will be trashed in public by someone famous. If you do something right, you'll be thanked and credited. This isn't a reflection of their opinion of you or your skills; it's directed entirely at the particular patch. The same person on the same day may praise one of your patches and insult another. You'll even get people praising your idea, insulting your implementation, and applying their own version. Don't take any of it too seriously, and judge your value to the project only over a large amount of work.
People will ask you for stuff. It's okay to not do what they want. If you'd rather do something else, do it. Doing what they want is a good way of getting nice emails, though, and it's easy to feel guilty about not doing things.
You have to figure stuff out yourself. There probably won't be instructions on how to get up to speed on the project. You have to pick something you want to do, and figure out how to do it with a lot of reading code and trial and error. Projects generally don't know what to do with people who want to be helpful without a specific goal.
You don't need permission for anything. If you want to write something, just do it, and tell people you're doing it. If you think it's going to be controversial, announce it before you get very far, in case somebody has a good fundamental objection.
The biggest need is always documentation. The best documentation comes from people who try to use the program, have a problem, get it explained, and write up the solution. The second biggest need is always testing. The best testing comes from people who try to use the program and find that it's doing something definitely wrong. Developers almost always instinctively avoid doing things that don't work, and rarely hit those cases. There's often plenty of low-hanging fruit if you want to get involved just by running the program and fixing what comes up.
OSS is about licensing. Period. While the subject may make a good topic for one class session in a larger course, an entire course devoted to it is overkill. It would be like having an entire class on "Shareware". In other words, pointless.
Instead, teach a class on Linux or BSD device drivers, or Unix system architecture, or Xorg programming, or LAMP, or Python scripting, etc., etc.
A Government Is a Body of People, Usually Notably Ungoverned
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?
You were basically spewing out unfounded claims and comments, and you didn't even bother listening to other people when they responded.
One of the refreshing things about this whole thing is that someone in that position actually spoke up against the instanit that is clueless users that want to dictate your business/project. I applaud him, and I will certainly keep a closer eye on KOffice, and I will definitely try out any Windows port made available.
Respect for users and customers is good. It's great! But when the same user keeps spreading lies and unfounded nonsense all over the place all the time, it's great that someone has the balls to cut the crap and call a spade a spade.
Your over-analysis of the "if they don't make it after all"/"it's impossible to make it" thing was just so damn annoying!
Clever signature text goes here.