Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Education Programming IT Technology

What Makes an OSS Class Work? 246

Posted by ScuttleMonkey from the knowing-is-half-the-battle dept.
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."
This discussion has been archived. No new comments can be posted.

What Makes an OSS Class Work? More

What Makes an OSS Class Work?

Comments Filter:

  • Fundementals (Score:5, Insightful)

    by rovingeyes ( 575063 ) on Monday October 10, 2005 @05:49PM (#13759747)
    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.

    • Re:Fundementals (Score:2, Insightful)

      by Anonymous Coward
      What else you ask?

      Uhhh, I just thought of an important one. What about "how to make money?"

    • Re:Fundementals (Score:5, Interesting)

      by sameb ( 532621 ) on Monday October 10, 2005 @05:58PM (#13759823) Homepage
      Indeed. A class on OSS is a business, legal or philosophy class, not a programming class. That doesn't mean CS students shouldn't have an OSS class, but if they do it certainly wouldn't be a programming one.

      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).
      • 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"

        • Re:Fundamentals (Score:2, Informative)

          by Atanamis ( 236193 )
          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) Eac

        • Re:Fundamentals (Score:4, Funny)

          by Pig Hogger ( 10379 ) <pig.hogger@g[ ]l.com ['mai' in gap]> on Monday October 10, 2005 @07:45PM (#13760452) Journal
          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?
          Simple. Write the prototypical "Hellow, orld" program in any compiled language, and print out the source code and a hex dump (sans ASCII) of the executable.

          Show both to boss.

          (YMMV according to the boss's hair pointyness...)

          • a hex dump (sans ASCII) of the executable.
            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.

            Oh, now I get it - you want to give him a blank sheet, right?
        • 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 bo
    • What else would you discuss? Well the philosophy, legal, ethical, and practical business applications are indeed some of the things to discuss. But OSS is a Development Model of sorts also. I would cover managing an OSS Project effectively and how to effectively participate in an OSS project. People think it's only a philosophy but it's also a methodology in some ways.

      Distributed collaborative development, maintaining a projects vision in a completely open system, patch management. All of these are issues t
    • I'd suggest a discussion of collaboration tools (source management, wikis, mailing lists, irc, message boards), organization structures (Foundation based, business based, person based), distribution models (distros, install packages, source only), cross platform development, funding models (support, documentation, packaging, donations, none) and cross cultural issues (language tools and internationalization, different legal environments for patents and copyright).

      LetterRip

    • Re:Fundementals (Score:5, Insightful)

      by chris macura ( 899109 ) on Monday October 10, 2005 @06:02PM (#13759852)
      Lecture 1: OSS. What is it, where is it, and why is it.
      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)

        by j1m+5n0w ( 749199 ) on Monday October 10, 2005 @06:37PM (#13760080) Homepage Journal
        To that, I might suggest adding
        • how to write portable code
        • how to use make/autoconf in a portable way
        • how to create packages (rpm, deb, tar.gz, etc)
        • how to submit your packages for inclusion in various distros, and how to make things easy for distro maintainers
        • how to obtain feedback from users (bugzilla, mailing lists, forums, wikis, etc...)

        • Re:Fundementals (Score:5, Insightful)

          by Johnny Mnemonic ( 176043 ) <mdinsmore&gmail,com> on Monday October 10, 2005 @07:12PM (#13760258) Homepage Journal

          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.
          • One could argue that OSS' goals are best served on open source operating systems. After all, if it's better, why do we give a rat's ass about those inferior closed source operating systems?
            • One could also argue that exposure to OSS, even on a closed OS, is a good thing. Especially when said closed OS has a virtually ubiquitous market share.
          • The first three? Write portable code is not tied to linux, not by definition (if code is tied to unix/linux it does not run in windows thus it is not multiplataform). Multi plataform is quite important, simply because the reason you stated. Being able to run on linux is going to make the software available to most of the comunity that will probably want, or is able, to change it and adapt it, while if there is a windows version it will be available to 90% of the world for whom linux is just another buzzword
            • Write portable code is not tied to linux, not by definition (if code is tied to unix/linux it does not run in windows thus it is not multiplataform).

              Try posix. I believe one can compile posix code on windows.
      • As happens every time we get one of these requests, I'm wondering who on earth would want to attend a class like this. Sit through a three hour lecture on whitespace usage? The week after surviving three hours on troff?

        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.

      • 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.

      • Missed one (Score:3, Interesting)

        by RingDev ( 879105 )
        Lesson 13: How to make OSS profitable.

        -Rick
      • 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.

      • Re:Fundementals (Score:4, Funny)

        by eh2o ( 471262 ) on Monday October 10, 2005 @08:46PM (#13760833)
        Lecture 1a: History of OSS ...
        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.
      • That sounds like a cool course. However I don't think it is an OSS course. Except for Lecture 1 and Lecture 6, the rest is stuff that is general stuff that applies to open and closed-source software. It sounds more like an introduction to Unix programming tools or the beginnings of a software development life-cycle course of some sort.
    • 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 t

      • 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

        • Actually I had considered that approach except for the issues of budget for a class. It's not like the average CS class has a pile of money lying around for licensing :).
    • 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.
    • It does matter perhaps what IDE, language, etc. one uses. For instance, wold one use Visual Studio to learn C++ or use Visual Basic? No. But perhaps have them use emacs and develop in C, python, etc. There's a big difference. Should they use a free toolkit or proprietary, be concerned with cross-platform issues, etc. I teach the AP Comp Sci class and I use jedit for the editor. But I also use examples from python and C for comparison. I think you cold have an OSS class that focuses on OSS technologi

    • Re:Fundementals (Score:2, Insightful)

      by OpenServe ( 885833 )
      And frankly the most important question this class should address is - WHY OSS?

      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
    • Not to pick on you, but clearly everyone has misunderstood the poster's question. If you wrote all that stuff in a class definition it still would not compile. It would just make for unreadable code and would likely just confuse people that try to make modifications later.

      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

    • 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)

    by Frogbert ( 589961 ) <frogbert@gmail . c om> on Monday October 10, 2005 @05:50PM (#13759759)
    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.

  • Other aspects (Score:4, Informative)

    by m2pc ( 546641 ) on Monday October 10, 2005 @05:51PM (#13759770) Homepage
    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.
    • Absolutely. For any specific project people will have to learn the mechanics of all the tools involved: the compiler, the source code control system, the build tool, the bug tracker, and a project newsgroup, blog, or mailing list. You should consider dropping them all in a somewhat unfamiliar environment, just so they can learn how to pick up new tools.

      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)

    by tcopeland ( 32225 ) * <tom AT thomasleecopeland DOT com> on Monday October 10, 2005 @05:52PM (#13759771) Homepage
    Their school of economics has a course on Open Source/Free Software [informatik.gu.se]. Here's the summary:
    The purpose of this course is to study the philosophical foundations and theories that have developed in the open source/free software field. Beginning with a historical view of the developments in theory and philosophy the course participants will continue their study of the phenomenon and also be given the opportunity to discuss the new issues these development philosophies have given rise to. Additionally the question of whether these same theories and philosophies can be applied in other fields of intellectual endeavour aside from programming.
    Sounds like nifty stuff, although not much in the way of actually fiddling with open source code. I guess it depends on what aspect of OSS you're trying to focus on...
    • "Additionally the question of whether these same theories and philosophies can be applied in other fields of intellectual endeavour aside from programming."

      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 :P) on progress rather than the goods that follow.

      Now befor

  • The cathedral and the bazaar (Score:5, Insightful)

    by jarich ( 733129 ) on Monday October 10, 2005 @05:52PM (#13759773) Homepage Journal
    http://www.catb.org/~esr/writings/cathedral-bazaar / [catb.org]

    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)

    by daveed ( 545432 ) on Monday October 10, 2005 @05:52PM (#13759778)
    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 :)

  • Definitely need. (Score:2, Funny)

    by mctk ( 840035 )
    Free A's!

    Now is that freedom or beer?

    • 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)

    by PDXNerd ( 654900 ) on Monday October 10, 2005 @05:55PM (#13759798)
    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.)
    • For me, continuing education translates to 'after highschool' (i.e., university level, college level, or equivilent). Have to ask the submitter, I suppose.
    • Personal Satisfaction - That would make a good way of looking at a continuing ed course. As for how to teach it, I have a three pronged approach to suggest. "I know why things are this way." One branch is simply the history of what happened, so that we can see how personalities and philosophies were cross-pollinated by different hardware and software that was available at the time. Consider the birth of Unix as one example, Microsoft as another and Linux third. "I know how to how to do it." Another wo

  • Get Involved (Score:5, Insightful)

    by Acius ( 828840 ) on Monday October 10, 2005 @05:56PM (#13759811) Homepage
    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.
    • Interesting. I wonder how much code to OSS projects is done this way. On most projects I've seen, 80-90% of the work is done by a few maintainers who have some (usually financial) interest in the project and most or all of the remaining work is done by users of that software who were pissed off about some piece of functionality.

    • Re:Get Involved (Score:4, Interesting)

      by kbielefe ( 606566 ) <karl.bielefeldt@gma[ ]com ['il.' in gap]> on Monday October 10, 2005 @08:23PM (#13760678)
      I would take this idea even further. If it is a semester-long class, I would make the term project be to get a patch accepted in an open source project. You learn a lot in the process of getting a patch accepted, most of which is not related to coding at all. You learn how to gain rapport with a community, how to find and fill a need in a way that is acceptable by all members of the community, and how to follow through. These are the aspects that are really different from closed source programming.

      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:

      • Pick a bug from the bug database. There are some bugs that get ignored because the main developers can't reproduce them.
      • Update a plugin or theme that broke when the parent package was upgraded.
      • Ask on the mailing list what needs work and would be good for a newbie to tackle. I almost guarantee they will have a list they haven't gotten around to.
      • Try out a lot of different open source applications in different ways. I once found a one-line bug in an app because I was trying to import a unique file. I was only evaluating the app for a few hours, and I decided not to use it, but my tiny fix is still in the code base.

      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)

    by pin_gween ( 870994 ) on Monday October 10, 2005 @05:56PM (#13759814)
    What would you want to see in an OSS class?

    Girls

  • A few things... (Score:5, Insightful)

    by Omega1045 ( 584264 ) on Monday October 10, 2005 @05:57PM (#13759817)
    1) Info on licensing and the GPL, etc, etc at some point. Perhaps an intro to FOSS licensing at the beginning, and more details at the end.

    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)

    by AuMatar ( 183847 ) on Monday October 10, 2005 @05:59PM (#13759834)
    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.
    • Another thought- macroeconomics of OSS. The fact that lowering the cost of software lowers the cost of doing buisness in general, and thus increases the resources available for other projects, increasing world productivity and GDP.

  • Get inside the code (Score:2, Interesting)

    by N1AK ( 864906 )
    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.
    • 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 ...

      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)

    by compupc1 ( 138208 )
    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 programmi
    • I would tend to say this would be a topic best suited for a one-time seminar

      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)

    by Anonymous Coward
    Here's a list of topics, in no particular order:
    • OSS history. Include usual suspects: RMS, Linus. Compare with proprietary software.
    • OSS licenses: GPL, LGPL, BSD / Apache / MIT
    • Installing OSS software: configure, rpm, deb.
    • OSS libraries: gettext, readline, etc.
    • OSS toolchain: make, autoconf, m4, cvs, etc.
    • Languages used in OSS development: C, Java, Perl

    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)

    by tyagiUK ( 625047 ) on Monday October 10, 2005 @06:05PM (#13759872) Homepage
    Are you sure he wasn't proposing a course on Operational Support Systems (OSS)? http://en.wikipedia.org/wiki/Operational_Support_S ystems [wikipedia.org].

    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.
  • 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?

    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
  • 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.

  • Lesson One. (Score:5, Funny)

    by GeneralEmergency ( 240687 ) on Monday October 10, 2005 @06:17PM (#13759956) Journal


    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.

  • 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
  • A constructor, methods and variables.
  • 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

  • Projects (Score:3, Insightful)

    by aduzik ( 705453 ) on Monday October 10, 2005 @06:24PM (#13759999) Homepage

    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.

  • 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 d
  • 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 t
  • Code Reading: The Open Source Perspective [amazon.com] by Diomidis Spinellis (previously reviewed here [slashdot.org] might be an interesting starting point.
  • 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

  • open source SENG (Score:3, Informative)

    by dgerman ( 78602 ) on Monday October 10, 2005 @06:58PM (#13760188) Homepage
    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 [turingmachine.org], and a presentation here: http://turingmachine.org/~dmg/temp/ossEd.pdf [turingmachine.org]

    Of course should reflect the level of the audience. My course was research oriented.

    There are, however, 4 areas that I would stress they are covered in a OS SEng course:

    * Intellectual property and licensing
    * Social aspects
        * Motivation
        * Organization..
    * SENG Issues (tools, methods, etc).
    * Economics issues
        * Why to use OSS, how to make money, etc.

    On thing that I introduced in this course was an etnographic study: students had to participate in a project, and submit a contribution. That was one of the parts that
    students liked the most because the were able to experience OSS first hand. I strongly
    recommend doing it.

    My materials are available if anybody is interested.

    dmg

  • If your students are not running Linux, and their backgrounds are in the Windows and mainframe worlds, then it might be best to approach OSS from the Windows side. This is especially true if your student's are not willing to install Linux on their own boxen or on whatever they may use at their place of employment.

    So, be sure to include Windows based OSS programs such as found on the Open CD [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

  • I've just glanced thru the comments and it seems every commenter else took a different tangent than my initial reaction. The ideas do a great job of showing the wealth of topics and issues facing anyone involved in licensing. But are you sure they're not looking for a course that explores various OSS software? Technical, not philosophical/legal/political? Or even some blend of the two?

    The nontech aspects of OSS could make for an interesting course, admittedly. But it'd be interesting on a par with phil
  • 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:

    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
  • 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/ [blogspot.com]), because the price of Photoshop ($600) scares me away.
  • 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 [berkeley.edu] 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 pro
  • I definitely go into OSS licensing in the courses I give at the University of Applied Science at Regensburg, Germany and also this fall at the Stevens Institute of Technology in Hoboken, NJ, USA - ~noone knows what's in the GPL, go through it and discusss the single points. Then go into alternative licenses from that, I show BSD as an alternative.

    In general, my OSS lecture is more of advanced system administration, advanced programming and advanced operating systems, pulling many things together - the t

  • 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.

  • python (Score:4, Insightful)

    by sniggly ( 216454 ) on Monday October 10, 2005 @07:57PM (#13760506) Journal
    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.

  • From the class I'm teaching right now... (Score:3, Interesting)

    by sailracer6 ( 262434 ) on Monday October 10, 2005 @08:01PM (#13760524) Journal
    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.

  • "How to join a project" would be interesting (Score:3, Insightful)

    by iabervon ( 1971 ) on Monday October 10, 2005 @08:15PM (#13760619) Homepage Journal
    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.
  • 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 vend

  • OSS is about licensing. Period. (Score:4, Insightful)

    by Arandir ( 19206 ) on Monday October 10, 2005 @11:34PM (#13761788) Homepage Journal
    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.
  • This is a completely shameless bit of self-promotion, but:

    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)

    by cerberusss ( 660701 ) on Tuesday October 11, 2005 @06:04AM (#13763333) Journal
    I had some irritations in using OpenOffice, logged a bug and waited two-and-a-half year before it was fixed. I wondered, why the flying fuck did it take so long? Because it's all open source, I could dive into OO.org's issuezilla and discovered it's not always plain and easy. I was amazed by the complexity.

    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.

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close