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.
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
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
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
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.
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.
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)
... 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.
The key to success of an OSS is how much you can get funding in VC (...)
Are you sure? How about writing good software and inspiring others to help you do so?
Couldn't that also mean your OSS project is a success?
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.
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
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.