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."
How to beg for money.... It will come in handy for all OSS programmers....
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.
Lectures by Mr. Thorvalds himself... and the farther you can keep RMS away from the class, the smoother it should run!
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 :)
...the fact that major companies rely on OSS to lower their costs and take advantage of others. IBM, Dell, and other major PC companies owe the OSS community a nod for providing valuable tools on servers.
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.)
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
The pros and cons of various source control platforms, such as CVS, SVN, BK, arch, and darcs would be appropriate, as well as discussing all the "free" software licensing options. This could turn out to be a rather religious class ;)
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
How about a class where the primary textbook is Google's USENET archives?
Slashdotters prove time and again that they don't use OSS, they don't read licenses, they don't develop OSS, they don't even use Linux. Why even ask slashdot, why not ask people in communities who actually use OSS rather than pseudo fanboys who spend their time playing Unreal in Windows or staring blankly at an Aqua decorated screen.
Not to scare them away, but there is an awful lot of work to do. They need to know not just the idea/conception stage, but also what kinds of talents they need to attract, and how to attract them, and how to lead them w/o the paycheck/command and control style available in traditional software houses.
A couple of case studies would be good too.
Oh, and all the goodies like readable code, Doxygen, Source Code Control (but call it "Revision Tracking"), available tools, test-driven-development and basic security.
we ended up making a gay perl phonebook script the whole course. wow i paid $200 to take such a class and realized how sysadmins/techs dont get laid then live horrible lives so i dropped out.
THANKS PROFESSOR FOR HELPING ME MAKE THE BEST DECISION EVER TO DROP OUT OF COLLEGE.
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.
Certainly go over the "Why OSS" and various licenses.
Pick a candidate solution that most people can relate to.
But since the attendees are going to be programmers, there are also possibilities of really picking an OSS product and take up an exercise for hands on involvement (a subset I suppose).
My $.02
Generally, bash is superior to python in those environments where python is not installed.
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"
Please be sure to discuss professionalism, at least to some extent. A lot of open source programmers fail to realize that professionalism is necessary when running a project that seeks to be successful. There is a far greater chance that such open source software will be adopted by businesses and other serious users if the developers put forth a good image.
For inspiration, take a look at some comments from a KOffice developer directed towards a user. Anybody who takes professionalism seriously would know that it is incorrect to insult your users in public like that. It's somewhat acceptable to point out that they might be wrong (in the KOffice developer case the user was correct, however), but it is never acceptable to resort to infantile name calling.
So please, if you do teach this course, discuss professionalism and basic customer/user/client interaction skills. It will do the open source community a lot of good, and may very well increase the usage of projects developed by your students.
Cyric Zndovzny at your service.
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
It sounds obvious, but you should cover the development process. In many CS classes students work alone, so an OSS model may be strange. How does one go about recieving code, building it, and tracking bugs? Grab some place on SourceForge and have the class run a small OSS project ...
Here's a comparison school kids might like:
There's a girl that wants to do it with you - WITHOUT protection. Would you rather...?
a) make sure she has no sexually transmitted diseases, or...
b) dive in, without worrying about the consequences?
NOTE: Assume that option a) costs no money at all.
After this example, you can mention Internet Explorer and the attack of the spyware and viruses, and compare with Mozilla Firefox as a *practical* example of Open Source programming.
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.
There is a course like this at the University of Gothenburg.
r ce.xhtml
http://www.informatik.gu.se/eng/education/opensou
Is your Program Director looking for a class on OSS development, or a class on theory of OSS? The fact that he didn't specify is a bit disappointing. It seems he doesn't understand is own question.
The theory of OSS could cover the motivations behing OSS (Cathedral and Bazaar), licensing types and options (GPL, BSD, Public Domain, shared source, closed source), and what business models are suited for each kind of license. Such a class might be better suited as a course in SW licensing and IP fundamentals. It is important to structure the class and lectures to cut down on fanboy diatribe and keep the class informative and constructive.
I don't think I can recommend a class on open source development.
Is the focus exclusively on _just_ OSS principles? If so, how can you _not_ devote a large portion of time to the methodologies, ideaologies, philosophies and political climate surrounding open source?
.. perhaps some reading such as The Cathedral and Bazaar would be a good start. Explore the benefits of OSS and use of open standards and some of the existing political climate issues (software patents, lobbying, etc..)
.. whatever.. depends on you) and open source resources (ie sourceforge, freshmeat, popular project sites, etc..)
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 "OSS" class as pertaining to a CS student:
1. Intro to OSS
2. Application design and structure (look at existing successful OSS projects and explore how the application design has allowed it to be successful in a distributed, global, Internet driven development environment)
3. Open Source tools (gcc, make, python, php, ruby
seems like that would establish a solid introduction to open source and cover many of the fundamentals necessary to get a student involved in the use and creation of open source software.
- Discuss Licenses;
- Discuss possible projects;
- Create a Source Forge Project; and
- Create Assignments for the different students, e.g., have a webmaster, coders, documenters, etc.
That would be really cool.A good programmer makes himself good and better. Teach the kids the need to share our intellect. Tell them how to help the community and hopefully, one of them would be able to create another Slashdot. Make sure your kids get how important it is to have to the freedom to read and modify the code. That should be enough motivation for the kids to make themselves better.
This actually makes some sense depending on how you approach it. While CS courses taught a lot about design and structure of programs they put zero emphasis on the real world of writing software. There was no discussion of requirements gathering, documentation, etc. There definitely wasn't a discussion of software licensing practices.
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 they have to write everything themselves, mimicking proprietary software development. Then in the second project they will be able to use any OSS resources available to them. What would be ideal is to overlap this with a business class, showing how the choices had an influence on time to market and the marketability of the product.
This sig has been temporarily disconnected or is no longer in 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
The most important thing is to avoid those stupid bloody references to "free as in ...". 1] Freedom as in speech. No there is not. Go up to the whitehouse and loudly announce you have a bomb in your backpack. 2] Freedom as in beer. No there is not. Go to the local liquor store and see how much beer you get for nothing. These two references are the dumbest things that OSS morons (especially those that believe Stallman is anything other than an idiot) spout on and on about.
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....
"My question to the slashdot crowd is: What would you want to see in an OSS class?"
An easy time savings tip would be to hand out CDs of Video Professor.
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.
You can hold down the "B" button for continuous firing.
A constructor, methods and variables.
Click here or a puppy gets stomped!
Programming language is pretty much an irrelevant topic when talking about Open Source IMHO. I think it would be to good start off by looking at the motives and philosophy behind the open source movement back to its roots (even prior to the formation of organizations like FSF). This should include business models - including success stories and failures. Also examining the development methodologies (distribution, building, code QA, versioning, testing, etc) used by large and small scale open source projects. Now that your students understand the 'why' and the 'how' of open source, you could have them pick an open source project and contribute something to it.
We are blind to the Worlds within us
waiting to be born...
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.
Make it about OSS and what it is, not programming. OSS is a philsophy, not a method.
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 don't, and talk about what is done right on the ones that work well and wrong on the ones that don't.
If you have time after that, start going in to tool and resources for developing OSS software. Introduce Sourceforge and so on. However don't make the tools the focus, make teh background the focus. Give people a good idea of what OSS is, how it compares to other kinds of software, what it's good for, and tips on how to do it right. That will probably be the most useful.
If it's just a C++ class laced with Linux pimping, it's not really going to be of much use when it comes to actually teaching people OSS.
Get into the history of how it all started. Stallmans vision of free software. The GPL and the GNU system. How Linus fit his kernel with the GNU software to form a completed system. How the term "Open Source" came about, and why it differs from "free software". The first open source support company, cygnus. Eric Raymond and his work. VA Systems and when it went public. Revolution OS is a great documentary.
The project management (if you can call it that) in the OSS world is quite different from the corporate world.
Learning to write effective bug reports, sensibly isolated code, using CVS/SVN are important.
If you are going to tech in Open Source Software. You better teach Project Management with an accentually random group of people. You will have some people who will crank out whatever code you ask out of them, but they are the rare golden types, most other people you will need to work with their quarks. Like the Guy who wants to make the application go in a different direction you do. People who say they will do some code and end up not doing anything. People who Product just pure junk but believe it is the best thing to man kind. Try to get that humble guy who feels his coding isn't up to snuff while it is is better then all those people with egos the size of the galaxy. As for programming programming an OSS program is no different then any other program, it is more about dealing with people, who are doing it out of their own free will so sum will be encouraged and others will be like well I am volunteering so I don't need to do much.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Code Reading: The Open Source Perspective by Diomidis Spinellis (previously reviewed here might be an interesting starting point.
I HAVE NOT read the other comments, so please don't flame me for redundancy.
I believe that an OSS class should consist of the following:
Start out with a bit of info (What is OSS? Why should you use this development model?) Only make that a doy or two, though, as most students will know already.
Next, go into licencing etc. explaining the positives and negatives of each model.
Bring in a guest speaker for whom Open Source has worked (if possible). Linus Torvalds, RMS, ESR, or the founders of just about any Linux-based Software corporation should work.
If it's a programming course, have the students work on the OSS project of their choice. Make it a grade, but not a big one.
And don't forget to give out the All-important Linux/Firefox/Other OSS CDs. I would suggest Ubuntu CDs since they come with The Open CD also. You can order them for free from the Ubuntu website.
DISCLAIMER: I AM NOT TRYING TO PUSH UBUNTU!!! I am using a Gentoo system at home, but I think that, for beginning Linux users, Ubuntu is a nice system.
I really wanted to change my sig to something witty, but all I could come up with is this.
Most of the posters have been looking at OSS from a political or a developer standpoint. Yet most people's experience with OSS is as a user or administrator. I think an important topic would be how to manage and administer OSS on desktop and server PCs. Discuss the tradeoffs of package systems (RedHat) versus release systems
(like BSD) versus build systems (gentoo).
I'd also like to see discussions of how to get ordinary work done with
OSS tools and apps. You'd have to spend at least a little time talking
about transitioning from commercial apps.
Actually, I was completely correct. I had the truth and facts behind me.
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 not to use an open source solution.
Open source software will never completely penetrate the corporate world if the developers go around tossing out such insults at users, customers and clients.
Cyric Zndovzny at your service.
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.
You can start off the class by telling a joke, like this one:
Q: What do you do when the OSS developer comes to your office?
A: Pay for the pizza.
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)
Easiest way to make it class work is to kill the opensource lisense crap and close it and sell it. Bam, it is now class work.
You should charge them a ton of $$. If they are willing to program for free....like PT Barnum said...
"There is a sucker born every minute"
How about picking an OSS project and contributing. This would give some hands on experience coding and introduce them to OSS. If it is a 3 credit class, it might be stretch to only talk about the philosophy of OSS. Some practical experience will keep the students interested and maybe recruit some new programmers.
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.
...document their freakin' code!
I've never seen poorer in-line and function heading documentation than open source Apache code.
In addition, the study of OSS gives insight into the development process. One can discuss the advantages of the OSS development process, the disadvantages, where OSS development can go wrong (lack of participation, fragmenting projects) and how projects learn to get around these problems.
A big first step would be to.....
endorse emacs or vi..........
Muhahaha
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.
Then there was a question about when KOffice would run on Windows, with the "troller" seeming to know more than the developers, especially considering KDE itself already runs on Windows. Imagine going in front of Bill and questioning when Longhorn will be delivered?
The nontech aspects of OSS could make for an interesting course, admittedly. But it'd be interesting on a par with philosophy 101: mind expanding but directly applicable to just a few people (people making IP license decisions) and hampered from reaching sure conclusions.
OTOH, the Tech aspects of OSS could:
At the end of a policy lecture series, all you'll give your class is a deep-seeming understanding of OSS issues (I say 'seeming' because a lack of much case law adds a lot of uncertainty).
For the Tech one, you give students enough understanding to think through OSS issues themselves, and you guided them through the toughest part (for most people, even techies) of the real OSS learning curve: where do I start and what do I do when something goes awry?
Oh, and grow a mailing list based on this... let your gung-ho OSS advocates feed off each other (and off people from previous/subsequent years) whenever they need to talk about some prickly OSS topic. Unlike pointing all them noobs at slashdot, you're giving them a security-blanket they can rely on in *really* becoming OSS users and advocates. The worst moments I've had in using Apache, Debian and a few other prickly OSS apps were times when I couldn't find online help... at times like that, a few OSS-using friends/coworkers helped me more than anything else.
But hey, if the department wants 60 hours of policy and comparative contract law analysis, use one of these outlines above. It'll be animated enough (since the only people that want an in-depth look into OSS are going to know what it is, but will disagree on the details). The idea initially sounds like a fun upper-level course, but ends up sounding like hell to me: YANAL, neither is anyone else in the room, EVERYONE has preexisting opinions, there are a thousand different motivations for loving/hating OSS, and legal precedent or case law is so far close to nonexistent. Might as well babble about Schopenhauer in Swahili.
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
As other posters have said, it's not clear if you want a "Philosophy of OSS" or "Production of OSS" class. If it's the latter, I'd take the following approach as a starting point:
:D
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 reusability, ease of comprehension etc, and shows that just having the source isn't always enough to let you do useful work.
3) *After* this, go through discussion of coding standards, commenting styles/tools, design documents and so on. This section can now be run like a regular technical class. Illustrate good and bad examples using OSS projects you're familiar with, proving that having the source even purely as a teaching aid can be helpful.
4) Now run through 1 and 2 again with more complex programs (possibly in groups). With the lessons learned in 1 & 2, and the knowledge gained from 3, any advantages and disadvantages can be discussed and expanded upon.
Not specific to OSS really, this approach was used to good effect in a few of my university classes. It certainly taught me a few lessons!
Game dev and music blog
Or "OpenOffice vs. MS Office", or "Firefox vs. IE". Be fair. Open some minds. I don't know about others, but OSS is a big part of what I do -- I use Firefox 90% of the time and IE 10% of the time; I got OpenOffice in my hard drive but rarely use it (in this case, MS Word/Works wins); I use GIMP 100% of the time (exhibit: my blog at http://sunandfun.blogspot.com/), because the price of Photoshop ($600) scares me away.
Sun and Fun
I'm a Whitespace user myself, you insensitive clod!
For the love of God, please learn to spell "ridiculous"!!!
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
Pam Samuelson, Steven Weber, and Mitch Kapor are team-teaching a course on Open Source this semester in UC Berkeley's School of Information Management Systems (SIMS). The schedule of readings is available online. In your situation, dealing with Continuing Education students, many of whom you expect to have programming experience, I would pick and choose from the readings on this syllabus and add your own components geared to your audience. Something participatory would be a good idea. If you do get all programmers, have them form teams and pick projects to contribute to and write up their experiences. If you get some non-programmers allow them to form a team working on contributions to open source-like projects such as Wikipedia or something.
Like Digital Freedoms? Then donate to EFF before they're gone.
In general, my OSS lecture is more of advanced system administration, advanced programming and advanced operating systems, pulling many things together - the tools used in open source, install mechanisms, software and package management, source code management, etc.
See the (english language) class webpage (also available in german) for more information, and feel free to send mail.
- Hubert
If I were to enroll in your class, I would hate to see you talk about licensing and PM stuff. Its for empty personalities, like Program Managers. As a student I would be more interested in being a developer on Open Source Technology. Split the class depending on their interests.
Open Source OS Development and Deployment - Develop a OS module for Linux/BSD and test it out.(Building OS is not so easy, took couple of days for me) Any one can install, set some high expectations like they implement a Cluster or something......
Tools/Product Development They can participate in development of compilers or gnutelephony or helix streaming server or embedded tools....
Web Programming LAMP is a Must. Let them Build whatever they want.
Get them involved with Open Source projects and teach them how the development process works.
Once again NO Licensing and PM stuff, pleaseeeeeeeee.
Teach them to write code that doesn't suck, first.
Those who stay will know about OSS anyways.
Those who go (because they can't code) won't need to know about OSS.
Show both to boss.
(YMMV according to the boss's hair pointyness...)
It's not only a technical process (quick patching and frequent releases) but also a social one.
One must learn to share.
In spirit of OSS, the course should be offered free and all materials related to the course, including but not limited to: Syllabus, materials, software, lecture, notes and office time should all be free.
"If you are a dreamer, a wisher, a liar, A hope-er, a pray-er, a magic bean buyer
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.
Your constraints vary a lot from languange to languange.
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.
I stole this sig from someone cleverer than me.
I find analogies with books work best for almost every sort of comparison. The best analogy, of course, is when people say, "Isn't the program finished? What do you do all day?" That easily translates to, "No, it isn't. It's a book that needs constant revisions, edits and changes. People send in typos and grammatical errors and plot suggestions and new characters, etc..." (Well, that's more of a metaphor.)
As far as "what is source code", that's somewhat comparable to a book review versus the actual book. You can't read the book review and honestly say it's a great book -- you have to go to the book itself. A better comparison, though, is translations into different languages. If you want to critique the book in the form the author intended, you need the original -- not a copy that has lost some of its meaning in the translation.
There'll be no exact comparison, simply because there's so few things that have the same relaionship. What you need is to figure out what the source code actually gives you that a proprietary product wouldn't. Many times, there's not much. For instance, if an "open document format" was required, it wouldn't much matter if the code itself was proprietary, because the goal of keeping the format open can be met.
Actually, thinking about it a bit -- a very good analogy is DNA testing. If someone mysteriously shows up and claims to be person X, you can verify that by testing DNA. If a program claims to be doing one thing, you can verify it by reading the source code.
There's tons of different analogies for each angle of "source code", none of them will always be spot-on, but depending on the situation, there's one that'll meet your needs.
"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."
Nessus
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.
I'll leave the curriculum to you, but I would suggest you teach the class from a business perspective, not as a preacher to a congregation. It's demeaning and unprofessional. It's important to make note that there are good reasons to use non-oss software, and that OSS is about the source, not the cost.
People who think they know everything really piss off those of us that actually do.
http://www.bbc.co.uk/worldservice/programmes/outlo ok.shtml
One of the biggest problems people (especially professional people) have, is interacting with the communities around the OSS software they are using. The community is not free tech support or unpaid labor, but when properly nurtured and given the right incentives can provide both technical and development support.
Maybe you could force them all to contribute to a big-ish GPLed Project? That would teach them how it actually works, not just the theory and the legal stuff.
You are correct in stating that the KOffice developer was completely wrong to throw out such insults like that in public. Like I've said before, even the janitors and burger flippers at McDonalds know not to insult the customers. I would hope that open source developers, especially those on a more widely known project like KOffice, can hold themselves to at least the same standards as the lowliest of McDonalds employees.
Cyric Zndovzny at your service.
While OSS does stand for open source software, source need not be source not be source code nor does open source necessarily need to be tied to software. Open Source is about having the method of creation of an item open for everyone to use, and furthermore to change as they may so long as they keep it open. It can apply to music, writing, board games and cola recipies just as an example.
I do believe that a class in open source should be about legal implications, philosophy, business issues, collaborative process and issues of that sort and have very little to do with writing code.
"You can now flame me, I am full of love,"
Oh, now I get it - you want to give him a blank sheet, right?
We do not live in the 21st century. We live in the 20 second century.
OSS is a geekified version of marketing. At least in marketing, there's girls!
lmstar
by following procedures
Here's a basic layout I would like to see.
* What is Open Source?
* What is the environment of Open Source today? Linux? BSD? Distros? Gnome? KDE? IBM? Novell? Redhat? Licenses and politics going on today.
* What types of roles exist within the community. Architect, Developer, bug reporter, user and zealot.
* What types of tools/apps are out there and are widely used in server rooms, developer workstations, embedded and home/office areas.
* Big issues for the future in OSS. Usability and efficiency in desktop environments, open standards, software patents etc...
The summary makes sense now.
"(programming experience) ranging from only mainframes to C++"
Aren't those the DEC guys that Microsoft hired to build NT?
This isn't about getting people to know about OSS.
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 female were, in fact, predominantly female at my college. So it would work there if nowhere else.
Mod me down and I will become more powerful than you can possibly imagine!
of course, you should cover philosophy, etc...
but when it comes to actual coding time, don't forget the most OSS of languages in existence...python!!! Php would be okay, too, perhaps...
First, the philosophical, legal and sociological issues can be covered in about a class.
Then a class on open source environments. 1 practical class being a guided tour of some kind of Debian based live distro. I'd make them spend the first quarter of the lesson on the command line before they hit X11. A further class on obtaining open source software. A tour of apt-get, sourceforge and CPAN - questions like "obtain software that can do the following?".
A lesson on Documentation. Finding it, and reading it, and knowing when to delve into the source.
Then I'd teach perl 0.101 (like ultra short 101) with an emphasis on obtaining software CPAN, and doing stuff with it. Just because there's such a rich vein of good quality CPAN modules...
"...we should just trust our president in every decision that he makes and we should just support that." B.Spears 2003
1) How to Design and Build Infrastructure you understand.
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 vendors to decide if it is economically advantageous.
3) Teach your students key refresher courses in good software engineering practices for managing source code. Using source code debuggers, and IDE's such as Eclipse and version control to track and secure auditing of the security of that source code using subversion/cvs.
Review the fundamentals in software construction and begin with William Glass, and of course Edsger Dijkstra.
4) Finally, tell them you can make millions of dollars managing and selling source code for customers who want to buy your services, labor and peace of mind.
Make them see how software constructed by an organization allows business processes and methods to be unique. Why? What you own is much more flexible per dollar, than buying whole business methods off the shelf like any of your competitors can with huge money sink holes in the existing CRM, ERP markets.
After all, if your competitor can buy the same methods of doing business simply by writing a check too, what does that buy you?
It took me 20 years to come around to seeing the errors of my ways and many millions wasted.
Don't let your students do the same.
-Hack
Got Geometrodynamics? Awe, too hard to figure out? Too bad.
UC Berkeley's School of Information Management & Systems has an excellent class on Open Source. The syllabus is available online: http://www.sims.berkeley.edu/academics/courses/is2 96a-2/f05/syllabus.html
The free pdf at this location would be a great textbook. http://www.freedomsoftware.info/book.pdf Free Software for Busy People.
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
This is a completely shameless bit of self-promotion, but:
http://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
http://www.red-bean.com/kfogel
To spread some love for OSS!
Of course you need to cover the different licences (preferably objectively), outlining the strenghts and weaknesses of each.
I think RMS is worth a mention.
Make sure you cover the free vs freedom (gratis vs libre) thing properly.
Introduce how OSS tools can make your development life easier (Flyspray, Bugzilla, gcc, gcc+, gdb etc. etc.)
Perhaps show how to make a minor change on an OSS app, and how this is good.
Maybe as an end of semester excercise, tell each group of students to find one OSS they particularly like, and submit one of the feature requests/bugs. Those whose patches get accepted get extra kudos.
Share your Knowlege - Kung-Fu Geekery
I don't know what all the fuss is about. The only tricky part about your OSS class is how strict its terms on. Some OSS classes will only have public:protected: sections. Of course, with multi-licensing, your OSS class can have both public: and protected: sections. But you have to carefully read the fine print if you want to derive any private classes from it.
JADBP
San Francisco State University is running a new course on open source. From their site:
http://is.sfsu.edu/node/29
The IS department is offering a new elective titled "Managing Open Source" in Fall 2005. Here are the details:
Detailed study of the management of open source software and related processes: open source management issues, integration of open and proprietary software, licensing, copyright and intellectual property rights. Also examines open source business models in the enterprise.
http://www.sfsu.edu/~bulletin/courses/30835.htm
Course Objectives
The student will be able to:
* understand the similarities and differences between open and proprietary software;
* evaluate licensing, copyright, intellectual property rights and business models related to open source software;
* identify issues such as standards, interoperability, and source code management in managing a heterogeneous Information Systems environment;
* describe the challenges in integrated management of open source and proprietary software in the Information Systems infrastructure;
* use Return on Investment (ROI) and Total Cost of Ownership (TCO) approaches in the acquisition and use of open source software.
For questions, contact the IS department or Dr. Sameer Verma
The single topic I had most difficulty with starting on OSS was the whole CVS business. Not so much the technical details but rather the whole human process of getting patches into code.
This is still one of the greatest bariers that stop me from contributing patches for many OSS projects; some projects require lengthy and confusing processes before one can even apply a simple fix.
I remember having an obvious fix for an obvious bug (email timestamp was encoded using locales; italians use '.' in time rather than the RFC-standard ':' so an italian localized would wrongly encode the time) in an OSS Delphi comms library (Indy). I mailed the bug and fix location several times (since, being outside the main team, my patches wouldn't be accepted) and it took over 2 years for the bug to get fixed.
This is obviously an extreme, but even getting patches in Apache or Linux is hard. So basically, an OSS course should focus on how to work in the large variety of OSS projects and how to work with the code.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
Teaching an audience about the OSS community through lectures (be it on business models, or on the collaborative tools used) may not be very easy. I have been working for a company that encourages new entrants to first start off or join or maintain an orphaned OSS project. So initially we show them where to look for licensing information and on collaborative tools, and further on mailing list etiquette. Assuming the audience/candidates have a sound theoretical background they should be able to understand and begin participating. Participation, being the best university, is what should be encouraged through the lectures. In most part, the audience/candidate has to understand the community process, the way it works. Further, this differs from one OSS project to another. Some may be purely meritocracies (when it's a small and specific product), while in the case of projects like the Linux Kernel, there may be tons of other issues affecting it. These can only be experienced, not explained. This is my point of view, others may tend to differ.
No Greater Friend, No Greater Enemy! (Lucius Cornelius Sulla)
http://www.extremeprogramming.org/
http://www.extremeprogramming.org/rules.html
Extreme Programming (or XP) is a set of values, principles and practices for rapidly developing high-quality software that provides the highest value for the customer in the fastest way possible. XP is extreme in the sense that it takes 12 well-known software development "best practices" to their logical extremes
Teacher, if your students do not excel you then you have failed.
"A class on OSS is a business, legal or philosophy class, not a programming class."
Indeed. N3P offers a new two-year college level training in how to become a successful Project Entrepreneur in Open Source. Students will learn not only the technical possibilities, but also how to exploit new business opportunities, manage profitable ideas, and create flourishing businesses.
All students are using Apple iBooks.
I'm active in two FOSS projects, both LGPL, and I think that outside of licensing and philosophy, the most important thing to teach is how one participates in these projects and how it's different from traditional models.
One of the two projects has a titular lead programmer (who started it), but the committers are all welcome to refactor heavily as long as a) they don't break the code, b) they are willing to listen to criticism and discuss their proposals and c) they maintain ownership and don't walk away before the work is finished and completely integrated.
On the other project, there is a separate "incubator" sub-project where new ideas are tested and demoed, discussion is based on that, proposals are made, and the changes then accepted into the main branch.
So how one contributes is one thing.
Another is that different from for-pay work, people may appear and disappear from the project over time, often doing a lot of work and then none for months at a time. It can be lonely--you might have a lot of energy, a lot of ideas, and almost no one to discuss them with. You may be on your own much of the time. The "community" feeling shows itself over long periods of time and during the release cycles.
There's also more direct acknowledgement of contributions by individuals than in for-pay work.
Last point would be that writing software is hard work, and if you're active on a project, you'll likely spend much time, many nights and weekends, writing code without compensation. That can lead to greater pride of ownership, but on the other hand, can lead to burnout as well.
I think the social aspects of FOSS development are some of the most interesting ones to talk about.
Patrick
"I honestly would vote libertarian if their candidates weren't usually total cooks."--slashdot poster
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?
This applies to all projects, but I think it is biggest thing to consider in open source development. Many people here have said that you need to discuss about licensing, but it is really not that important that you would use more than one or two sessions about it. It is basically a one time choice.
What you need to do is talk about how to work together in open source development. I think this is the number one thing why open software fails. Working over distance, deciding tasks, handling bug reports, designing, implementation... there are quite a bit of things to consider. When you are going to work on a open source project you are more likely to have to consider these things from the scratch than working in a company.
It would also be good to introduce services like SF.net, other open source projects and how their development works and various channels where you might get help if needed.
I demand the Cone of Silence!
Perhaps some introduction to the theory of Peer Production would be beneficial for understanding the economic foundation of Open Source. Some links: Coase's Penguin, or Linux and the Nature of the Firm, The Economics of Peer Production
The following might be of use
1 /lecture7.pdf
http://www.csc.liv.ac.uk/~sphelps/teaching/comp22
Technical folks understand the need for source code, it's the non-technicals who don't. I can explain it to them in a few sentences, at least sufficiently for them to understand the need:
Source code is how the program is written, but to run it needs to be compiled. Compiling is a one-way process, and we can't take the compiled version and make any modifications to it. Therefore in order to make the changes you're requresing, we need to get a copy of the original source before it was compiled.
That's sufficient for most people to at least understand the need, if not the technicals. And despite it being slightly inaccurate (we could, after all, reverse compile, or work on the assembly level, but short of performance tweaks, why would you ever do that if the source code was an option?), it gets the message across.
Periodically someone doesn't quite get it still, then I liken it to a Word document and a printout of that word document:
Let's say I need you to make changes to a 400 page {insert complex corporate document type here}. I could either give you a printout of all 400 pages, or I could give you the original Word document. Which is easier to make changes to? The Word doc is like my source code, and the printout is like the compiled version. Yes, we can make changes based on the printout, but it requires a tremendously larger time investment, and is prone to mistakes.
Slay a dragon... over lunch!
Maybe I'm missing something here, but last I checked, HEX was {0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F}. That's definately a subset of ASCII.
So is 0 and 1, but I doubt anyone would call binary ASCII. "Binary expressed as ASCII" perhaps, just as 0-F is "Hex expressed as ASCII". Just don't give them ASCII as ASCII. Or give them an assembler dump of the binary, will also be fun. Even "hello world" is probably quite a few pages as a win32 app.
Live today, because you never know what tomorrow brings
The thing I have had to learn for myself most painfully in open source development is a new approach to version control. In a business environment version control is essentially an archive, and what the current ruling version of any component is is a matter of management diktat. With open source, you have to let people go away on their own with a bit of code - you can't stop them - and when they come back they may well have come up with something that's genuinely better.
So a project 'owner' has got to have the humility to assess someone else's work to appreciate when it is better, and also must be able to manage branching and merging of versions effectively and smoothly which is not always straightforward. You certainly don't want to be in a position where you don't merge a really good bit of work into the project simply because the version control overhead is too great.
So teach version control; not only what systems are out there but the theory of it and how to make it work effectively in an open source environment.
Also, of course, documentation....
I'm old enough to remember when discussions on Slashdot were well informed.
I study in Anna University, India. We have electives in FOSS, for bachelor degree. I guess it might help. Have a look at it here: (PDF Link) http://www.au-kbc.org/nrcf/FOSS_Elective-I_Syllabu s_final_14July05.pdf
Some general info on FOSS in my university at http://www.au-kbc.org/nrcf/index.htm
===============
This space intentionally left blank
I do a bit of consulting work that could be termed "open source strategy", and while it's aimed at business types who need/want to better understand the world of free software, a lot of it would be applicable to a course like this.
The first big decision you have to make of course, is whether there will be a "hands on" component where people learn about actual technologies that are popular in the open source world. In that case, I would get them going with Ubuntu, show them some popular systems like Apache and Postgresql, then some programming with C and a scripting language or two (Tcl and Python, perhaps), and autotools.
The most important part of this course would be, as others have stated, concentrated on what makes open source open source.
* Philosophy.
* Licensing and its practical applications (what code can I use? in what projects?)
* Economics - how do people do this and not starve?!
* Community - this is probably the most important one, and it draws on the other points. What kinds of open source communities are there already (FSF, ASF, various *BSD's, etc...), what makes them different? What are their motivations? How can you interact with them? How to build a strong community for your own open source efforts?
* Case studies. Linux, Apache, and the other big ones, but also some smaller, successful projects that are not such statistical outliers. Most people are not going to write the next Linux or Apache, but that doesn't mean they can't have a healthy, successful open source project.
I'm kind of envious - I think it would be a lot of fun to teach a course like that!
http://www.welton.it/davidw/
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.
You have no idea how annoying your self-righteous rants are. You were spreading lies about KDE, and he kicked your ass for it. Accept it and move on.
Yes, my stance on that issue was the correct one, because my stance was backed with the truth and factual information. The claims made by the other KOffice rep were potentially misleading, and the radical outburst from that particular rogue developer dealt an ill blow to the KOffice Project's reputation. A headache is no excuse for publically tarnishing the reputation of the project you volunteer for.
At least this incident serves as a very good reminder to the open source community about what type of incidents should be avoided. Other developers can now learn from that particular developer's mistake, and hopefully the open source community will be better off for it.
Cyric Zndovzny at your service.
The trick is to get experience using FOSS and to see a great many examples of successful applications. Free Software for Busy People is full of examples. http://www.freedomsoftware.info/book.pdf
The trick is to get experience using FOSS and to see many examples of successful applications. Free Software for Busy People is full of examples. http://www.freedomsoftware.info/book.pdf
Yes, of course it's important to write good code. But in most cases, you won't be starting from scratch; you'll be working on an existing system. And I don't know about anyone else, but I find it extremely hard to get going when the source code for a big system is dumped on me. Even if it's well organised, well designed, and well coded (which few are).
So maybe the course should include something about that? How to find your way around a big system, how to work out what it's doing and how it's organised, how to decide where your changes should go, how to make them safely without screwing other things up, how to test them.
And, just as importantly, the less technical side of this: how to become involved in the open source community, how to get involved in a particular project, how to make and submit patches, how to discover and fit in with existing style/patterns/standards, how to get buy-in for big or highly-visible changes, how to explain your ideas so that they can be understood (i.e. not just "Well, it's *obvious* that my way is best!").
Most of these issues also apply to proprietary code, of course, but some are much more important when there's no company structure to resolve conflicts or direct the work.
Also, as Acius said, having a real example to wotk with may well help. Especially if it's a small one that people can actually follow and/or contribute to in a reasonable amount of time.
Ceterum censeo subscriptionem esse delendam.
It is important to know how to get involved in an OSS piece of work. Often if you want to submit code, you first need to do bug stuff (writting patches and the sort). Then developers may let you in to the code itself (note I said might). Other times you simply have to ask. Either way you need to be familure with both the ticket system the project is using, and the code control system. Licenses are always important. Users of any system also need to know how to go about sharing code between projects(dealing with incompatible licenses, dealing with multiple languages, and dealing with people). Finally it is important to be able to quickly express your ideas (otherwise you get run over by someone who is faster at expressing a different idea).
What most OSS teams need is a lesson on GUI design, documentation, and why the two of them are important.
I suggest exposing them to the kind of tools that are used to develop real open source (and closed) projects: version control, build tools, test harnesses, bug tracking, and installation tools. Even if their 5K LOC program could be compiled using a shell script, show them what they would use when it becomes 50K LOC.
There's even a new book from O'Reilly about these kinds of tools - "Practical Development Environments" (http://www.oreilly.com/catalog/practicalde). I wrote it because I couldn't find a similar book for software toolsmiths.
"I believe the students would have a programming background ranging from only mainframes to C++ to those with some Java experience."
... what the hell is this new mainframes language? Where can I get more information? Is it statically or dynamically bound? Event-driven? Compiled? Interpreted? Strongly or loosely typed? The industry is just moving soooo fast I can't keep up!
.... become an expert in the area yourself ... then, and only then, consider teaching it to others.
I can't believe it. Just when I thought I had a grasp on all the bleeding edge developments in the industry
In all seriousness, too many "teachers" miss the first step in teaching any class
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Incidentally, starting this academic year, I teach a similar course, called "Open Systems". It's also part of a one year continuing education course, specifically (but not exclusively) for graduated Bachelors Applied Informatics. The "Open Systems" course lasts one semester (about twelve weeks) and I teach it six (!) hours every week, which many would consider *waay* too long. Maybe they're right, but consider that the fact that my institution wants to organise such a course is a signal that people are starting to realise the importance of the F/OSS phenomenon...
Anyway. These are some lecture subjects that I have in mind:
As part of the course, the students have to work for an Open Source project. Either they choose one for theirselves, or I put them to work for Dokeos, an e-learning platform that is used (and actively improved and developed) at my institution. The idea is that they write a report, not only about what they've done, but also about the organisation of the project, how communication went, how conflicts are solved, etc. Most of them did an internship in a commercial development environment and they can compare both worlds, which should result in interesting reading...
Students get assignments every now and then, such as comparing an Free/Open Source application with its commercial counterpart (e.g. OpenOffice vs MS Office, the GIMP vs Photoshop,
If you want to exchange ideas, teaching materials, etc., send me an e-mail. In the spirit of Open Source, I'm happy to share my course materials with you. My address is my slashdot user name, followed by @advalvas.be.
Get over it. Stop being an ass. You are making a complete fool of yourself by acting like a clueless, pompous, self-righteous ass.
From a developer's perspective, there's also the question of how to set up a development environment consisting of open-source tools. I write software that runs on .NET on Windows, and started looking into open-source .NET tools a couple of years ago for projects outside of work. To my elation, I discovered everything necessary to set up a complete environment without spending a penny (except for the OS, of course, since it's Windows). I have links to the tools here: http://www.codenouveau.com/DevTools.aspx. I also teach a class on this now.