Talk:POSSE 2009 Sunday

From Teaching Open Source

Jump to: navigation, search
  • Re: Introductions and Icebreakers - how much pre-work do we want the profs to do? Ideally they'll already know each other via The Internets and not much icebreaking will be needed (just free food, perhaps).
  • Opportunities provided by Open Source - It seems like most of the profs are CS profs (need to have people put up bio/profile pages) but we should get more non-dev focused opportunities/benefits here as well. I've tried to add a few.
  • We will be working inside two communities, Mozilla and Fedora - when will profs have an opportunity to work on other/their own projects? (Will they? Is this going to be too distracting?) I think I understand the motivations behind this, and it makes sense, but I'd be interested to hear your rationale/plan for focusing on those two projects.
  • Installfest, for anyone interested or needing to update their laptop configuration - really, really good idea. Would a/the developer spin (or maybe a specific one for unis that they can take to students? would this be a good miniproject to learn about packaging and such?) be useful here?

Mchua 13:44, 28 May 2009 (UTC)

Contents

[edit] things OSS teaches you that school might not

(In response to being told that some students had had proprietary software development internships/work experience and could have a good comparison discussion when learning about open source)

Also keep in mind students may not even know about proprietary development. Sometimes, in school, "know how to program" means "given these numbers and that equation (or a story problem that can be turned into one), put the numbers into the equation and tell me what comes out." I utterly flailed when given the chance to do my first open-ended code project in my frosh year... I did not know how to break things down into prioritized components and features with milestones and the like.

Also, of /course/ I was going to write an instant message client from scratch in 3 weeks without looking at any implementations/architectures/protocols. I could just yell stuff at a socket... In the end, my partner and I made a really nice gui with clicky buttons that would send messages from my computer to... my computer. We were forever rewriting each other's code... every time I added a feature I rewrote the entire codebase because it wasn't flexibly designed... then she did the same, and then I did the same, and the nightmare dragged on. This was apparently my prof's way of convincing us to read software engineering books afterwards. :)

Olin is way more project based than most schools, but concepts like these were pretty foreign even when I graduated (electrical engineering, mind you - folks that actually planned on doing this as a post-college career may fare better):

  • release cycles (more than one iteration of development? feature freeze, why do you need that, can't you just... add new things as you want them? why have releases at all, can't you just use the darn software? what the heck is a release anyway? what does this whole 'candidate', 'stable', etc stuff mean? who decides what features to work on when your instructor didn't spell it out in your problem set? how do you know what your users actually do and need? what is a release manager? what is a project manager? a product manager? burn rate? can I assume that everyone on my project will have a superproductive 40h of coding a week?)
  • testing (why would you? your program gives the output the instructor wanted when fed the input the instructor gives you, isn't that enough? the whole "people... will use your product in strange ways" concept is odd. what users? why would you continue to test old stuff after you release new stuff? what's a bug report and how do you write a good one? why would you write one anyway? aren't you the only developer? can't you just fix it, or... you know, don't do that thing again that will break the program? why would you *need* testers? aren't they useless drones that tell you what to do?)
  • support (...for who, your TA who grades your programs? how do I make my error messages useful so I can debug the problems a remote nontechnical user is having? how do I remember that they're not dumb, they just chose to study Arabic or orthopedic surgery instead of CS? how do I keep them from getting frustrated, both in the design of what I make and how I talk with users when that doesn't work as expected? how will they know how to contact me? should they? should I teach others or write docs so I don't have to answer so many questions? will users really look at a .txt readme included with the source or should I have a webpage?)
  • code readability, modularity, reuse, etc (how do I find other people's modules? isn't that cheating? their code is hard to read and sucks and crashes and has no docs and I can't contact them to ask questions! (for how not to do this to other people, see above) ...but it's so much easier to write it myself! what's a patch? why would I send a patch? how? the concept of a patch is weird... why make this file, why not just... change the code? it's all on my computer anyway. why split it up into so many files when I can pile it all in one and have less to take care of? why docstring my methods? I know what they do!)
  • version control (what's that? why do I care? I have the code on my computer and it works and I can fix it...)
  • etc. Most of the things we take for granted now. And even now I scratch my head at times (a few months ago: "what's packaging? why do we have so many systems? can't everyone build from source? blah blah blah...")

>> Second, stressing how important communication is and that it will all take >> place on mailing lists and via IRC. > > +1 this is a big blocker for most college students who think that > collaboration is talking to their neighbor.

OH MAN YES. We had a rule this summer in Chicago that I now use for everything: if it isn't documented (at a public url) on $channel-of-communication, it didn't happen.* This eliminates the "nobody did X!" "I did, I told J. Random-" "-no you didn't!" "...I did! Tuesday, at lunch!" "But I never heard-" ...etc and it also means that there's a single place new people can catch up (information should not rely on having to be bosom friends with everyone and visiting them all the time).

  • $channel-of-communication = {this wiki, that mailing list, this forum, that meeting with the public notes...} (pick one, make it canonical)

[edit] from dave lang

One thing that *might* be missing (I can't tell if it's part of that first session) is, from a pragmatic standpoint, "why should I do open source"? I think there's fairly widespread understanding of some of the philosphy behind open source, but not the business pragmatics.

Consider emphasizing certain points like: 1. The open source model can accelerate innovation (look at Tiemann's arguments) 2. Reduced bug counts 3. Tends to reward value over lock-in ...etc. Explain why it's good for business and not just convenient for the developer.

I would also be interested to learn more about exactly who contributes. The general public (and many business/IT decision-makers) see open source contributors as a fickle and unruly group of independent developers that are contributing for the hell of it and could stop contributing at any moment. That makes open source software seem risky. I suspect that in reality (though I don't have any numbers to support this) a large percentage of contributors are professional developers at client-companies who are strongly motivated to continue to contribute to whatever software they are using. If your whole server architecture is managed by RH Satellite, you're not just going to stop paying attention to Satellite and risk that investment. So the contributions follow more from the "customer-driven innovation" model than from the "weird hacker in his mom's basement" model.

[edit] others

[edit] Old interview on Seneca

http://www.linux.com/archive/feature/140097 has some nice quotes from Hecker/gdk and features our instructors too.

Retrieved from "http://teachingopensource.org/index.php/Talk:POSSE_2009_Sunday"