What Makes an OSS Class Work? 246
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."
Fundementals (Score:5, Insightful)
Re:Fundementals (Score:2, Insightful)
Uhhh, I just thought of an important one. What about "how to make money?"
Re:Fundementals (Score:2)
Re:Fundementals (Score:5, Interesting)
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
Re:Fundementals (Score:5, Interesting)
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:Fundamentals (Score:3)
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"
Re:Fundamentals (Score:2, Informative)
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) Eac
Re:Fundamentals (Score:4, Funny)
Show both to boss.
(YMMV according to the boss's hair pointyness...)
Re:Fundamentals (Score:2)
Oh, now I get it - you want to give him a blank sheet, right?
Re:Fundamentals (Score:2)
As far as "what is source code", that's somewhat comparable to a book review versus the actual bo
Re:Fundementals (Score:2)
Distributed collaborative development, maintaining a projects vision in a completely open system, patch management. All of these are issues t
Re:Fundementals (Score:2)
LetterRip
Re:Fundementals (Score:5, Insightful)
Lecture 2: Types of licenses, when to use which.
Lecture 3: How to modify the licenses to allow for various common changes
Lecture 4: Writing documentation: intro to man-pages (how to write them), doxygen, and latex
Lecture 5: Writing readable code: commenting, dependencies, and the merits of white-space
Lecture 6: How to use OSS in CSS (closed-source software), when it may/may not be done.
Lecture 7: How to use versioning systems: CVS, SVN, etc.
Lecture 8: -+
9: +-- Communication Skills: technical writing (not the bullshit they teach you in english 101)
10: -+
Lecture 11: Survey of existing projects: why they succedded or failed
Lecture 12: ditto
That should cover it. I'm guessing a one/two credit course.
Re:Fundementals (Score:5, Informative)
Re:Fundementals (Score:5, Insightful)
You are obviously forgetting that a great deal of OSS software is produced for Windows and other platforms, such as OS X and etc. The first three suggestions that you have have less to do with OSS, and more to do with Linux/Unix--of which OSS is a huge component, but neither requires the other.
Re:Fundementals (Score:2)
Re:Fundementals (Score:2)
Re:Fundementals (Score:2)
Re:Fundementals (Score:2)
Try posix. I believe one can compile posix code on windows.
Re:Fundementals (Score:2)
Sorry, I can see the value of devoting one week of lecture(s) to open source/free software: history, philosophy, licenses, examples as part of a larger course. I just can't see it filling a semester. When people need to learn CVS, they can pick it up from the documentation in 15 minutes.
Gah (Score:2)
Software Development Process (Score:2)
Missed one (Score:3, Interesting)
-Rick
Depends a lot on the language (Score:2)
But any class needs to start with a good, solid constructor. It's your foundation.
After that, correctly-privileged members, comprehensible method names, and solid documentation will ensure that you're well on your way to a solid class.
Re:Fundementals (Score:4, Funny)
Lecture 3b: Why SCO sucks.
Lecture 3c: Implications of forking.
Lecture 9a; How to use IRC
Could be interesting for people who don't already know these things.
Re:Fundementals (Score:2)
Computer Law (Score:2)
I would argue though that there's an excellent overlap between CS curriculum and discussions of licensing, OSS, etc. What I imagine is two class projects. In one project t
Re:Computer Law (Score:2)
Much as I love OSS there is a problem with your comparison- if you're comparing a closed-source team vs. an Open Source team then the closed-source should really have a budget to buy-in a certain quantity of third-party libraries and utilities which they see fit. Very little proprietary software development is from the ground up, and there are a lot of very strong closed-source libraries out there.
In any circumstance it's true that any development team asked to develop something large and scary (as in "Th
Re:Computer Law (Score:2)
Distributed Project Managment (Score:2)
Learning to write effective bug reports, sensibly isolated code, using CVS/SVN are important.
Re:Fundementals (Score:2)
Re:Fundementals (Score:2, Insightful)
Absolutely! If people can't answer this question properly, they won't be able to run successful Open Source projects or contribute most effectively to existing ones. Don't forget the biggies:
- Motivations for OSS. Make sure you provide plenty of business cases and not just the standard fare philosophical / idealist fluff. Open Source is like the invention of the assembly line; it's a new way of doing the same thing, only more
Re:Fundementals (Score:2)
What would you want to see in an OSS class?
I like to see a constructor, a destructor (if applicable), and some methods that do something understandable. And some comments are nice, for instance stating what OSS license you're using, bu
Re:Fundementals (Score:2)
Yep yep.
OSS as a "movement" has nothing to do with programming per se, and everything to do with who owns the software and what rights others have to it.
If this class were offered at a school I were attending, I would expect it to be a "topics" type class, not a programming class where we sat in front of a computer, but a lecture based class where we talked about issues.
License and patent issues (Score:4, Interesting)
Other aspects (Score:4, Informative)
Re:Other aspects (Score:2)
You might explore the differences you'll encounter developing an OSS project on an OSS platform vs. building an OSS project on a closed platform with co
Göteborg University course (Score:5, Informative)
Re:Göteborg University course (Score:2)
That's an interesting sentence. I've always thought that the success of OSS owes much to the fact that it follows a similar process to that of academic research. You do your work, then publish it for others to review, criticize, improve and build on. In both the focus is always (in theory anyway
Now befor
The cathedral and the bazaar (Score:5, Insightful)
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.
IT Law (Score:5, Interesting)
Definitely need. (Score:2, Funny)
Now is that freedom or beer?
I sincerely hope it's freedom. (Score:2)
Unless he wishes to live in some sort of cardboard box (or gets the rent from Paypal or something) I sincerely hope he's getting some dinero from his work.
It's a lot better than another *vomits* PowerPoint class.
Is this for Continuing Education? (Score:5, Interesting)
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:Is this for Continuing Education? (Score:2)
Re:Is this for Continuing Education? (Score:3, Interesting)
Get Involved (Score:5, Insightful)
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.
Re:Get Involved (Score:2)
Re:Get Involved (Score:4, Interesting)
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.
Ernest T Bass Quote (Score:5, Funny)
Girls
Re:Ernest T Bass Quote (Score:2)
A few things... (Score:5, Insightful)
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.
A lot of small topics (Score:5, Informative)
*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.
Re:A lot of small topics (Score:2)
Get inside the code (Score:2, Interesting)
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.
Re:Get inside the code (Score:2)
Strictly speaking, OSS gives you the power to change things, but not the right. That's where you need Free Software.
After all, Microsoft has their version of Open Source, in which you sign an NDA and can read the source, but you have no right to do anything else such as make changes.
Of course, freedom to cha
One-time seminar (Score:2, Interesting)
Re:One-time seminar (Score:2)
Wow, that's exactly the opposite of how I saw it. As I was going through the list in my mind I was thinking there's no way this could be taught in a one-credit course -- there is so much to cover that three or four credits would likely be required to explore everything to a useful level. And then I went back and read some of the other poster's suggestions, and started wondering how it could all be taught in less than a dozen cre
Topics (Score:2, Interesting)
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 toolc
OSS (Operational Support Systems) (Score:3, Interesting)
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.
Scope? (Score:2)
If it is not really about OSS per-say but using OSS tools to achieve a goal (ie a programming class.. with open source! or sys admin calss.. with open source!) then it seems like it woudl follow the basic course structure of what it is trying to emulate but with the use of open source tools.
My thoughts of a "O
Teach them to be good programmers (Score:2)
Re:Teach them to be good programmers (Score:4, Funny)
God help us.
Lesson One. (Score:5, Funny)
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.
Some OSS class ideas (Score:2, Funny)
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
It's really simple (Score:2)
Process and Philosphy (Score:2)
Projects (Score:3, Insightful)
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.
Well if you want it to be useful (Score:2)
So I'd start off with what OSS is, what the ideals are. I'd contrast it to commercial software. I'd also contrast it to public domain. Make sure to define and discuss the different kinds of freedom, monetary and code. I would give a run down of the positives and the negatives of OSS, the thigns people argue for it and the things they argue against it. I would present examples of OSS projects that work well and of ones that d
Project Management on a disjunct group of people. (Score:2)
Code Reading (Score:2)
Starting off (Score:2)
Q: What do you do when the OSS developer comes to your office?
A: Pay for the pizza.
Important thing: money (Score:2, Insightful)
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
open source SENG (Score:3, Informative)
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
Include Windows OSS, Cygwin, Knoppix & Eclipse (Score:2, Informative)
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 [theopencd.org] and check out the the source forge osswin site [sourceforge.net] at http://osswin.sourceforge.net/ [sourceforge.net].
You need to give them a flavor o
Go back for clarification (Score:2)
The nontech aspects of OSS could make for an interesting course, admittedly. But it'd be interesting on a par with phil
OSS Programming? (Score:2)
1) Using a simple (scripting maybe) language, get the students to write a simple program, for evaluation purposes.
2) Randomly assign each student's program to a different student. Ask them to extend the program in a to perform a given additional task. This'll be a good example of how different coding styles etc impact on reusabilit
Use Examples Like "GIMP vs. Photoshop" (Score:2)
I'm in an OSS class at UC Berkeley (Score:2)
Stevens & FH Regensburg classes (Score:2)
In general, my OSS lecture is more of advanced system administration, advanced programming and advanced operating systems, pulling many things together - the t
Re:Stevens & FH Regensburg classes (Score:2)
- Hubert
Make it Free (Score:2)
python (Score:4, Insightful)
From the class I'm teaching right now... (Score:3, Interesting)
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.
"How to join a project" would be interesting (Score:3, Insightful)
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.
Dont Preach (Score:2)
a ukelele (Score:2)
OSS Class Wish List (Score:2)
Teach your students that building computing infrastructure through source code, instead of hitting clicking on the setup button.
2) Attack security and loopholes all software has by teaching your students to own the infrastructure they build, through the use of source code and the GPL IP way.
Teach your students the that if you understand your infrastructure, you can correct its problems in a proactive way, if you have the source. Not, waiting for vend
OSS is about licensing. Period. (Score:4, Insightful)
Instead, teach a class on Linux or BSD device drivers, or Unix system architecture, or Xorg programming, or LAMP, or Python scripting, etc., etc.
This free (online) book might be useful. (Score:2)
http://producingoss.com/ [producingoss.com]
That's the web site for the new O'Reilly book "Producing Open Source Software: How to Manage a Successful Free Software Project". The book's content is all there online, under an open copyright. Even when I was writing it, I was thinking of the classroom as one place where the book might be useful. Have a look and see what you think.
Best,
-Karl Fogel
Teach them bug tracking (Score:3, Interesting)
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.
Re:Be sure to include..... (Score:5, Informative)
Professionalism is a must. (Score:3, Insightful)
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 [slashdot.org] that tarnish the reputation of an open source project.
So please, consider teaching something about professionalism. It will help in many ways, be
Successful projects require professionalism. (Score:3, Insightful)
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 m
Nah, forget all that. (Score:2)
Its about filling the seats. You know what you need for that? Women.
Get the babes in there, and the programmers will be all about it. Just combine it with another class. Perhaps the open source software and women's studies, or open source software and elementary education. If you're really bold do open source software and cheerleading practice.* Then teach it on whatever you want.
*All of these classes, which I am clearly stereotyping as predominantly f
Re:Why not do a class project? (Score:2)
1) there usually not enough time to finish it correctly
2) forcing people's different interest into one is not a good idea (well remember they are paying you to teach them and not being paid to do a project)
Bad things about opening a new project, OSS is not a junk yard to be pushed out and not worried about. It has to be maintained.
What should be done instead, let them find an already open/free source project which they can join and let them work on th
Re:Why not do a class project? (Score:2)
Professionalism can make or break a project. (Score:2)
What bothers me is that the image of the KOffice and KDE projects were tarnished by that rogue developer. As a long time KDE user, I wish nothing but the best for the project. That is why it bothers me so much when members of the development team working on KDE-related projects show a lack of professionalism.
I sure hope that any executives from large corporations did not see that post of his, especially if they have to decide whether or
Re:How to deal with flamebaiters (Score:2)
Indeed, the KDE project has suffered. (Score:2)