Productively Lost?

A new semester, new required texts, new team members, and the same (one and only) Dr. Jim Bowring.  This semester CSCI-462 is relying partially on an online text.  Teaching_Open_Source 0.1 - Practical Open Source Software Exploration:  How to be Productively Lost, the Open Source Way.  This text aims to teach students and self-learners the basic skills of open source development  through real involvement in meaningful projects.  Chapter 1 explains why a student/ self-learner would need this text.  David A. Patterson, a computer science pioneer, advocated for the inclusion of courses in open source software development in computer science curriculum.  Unfortunately the world of academia did not heed his advice, as the text puts it, "because it's hard".  The text stresses that "the skills required to succeed in an open source software project are the exact same skills required to succeed in any large software project."  In short, this is real world preparation folks.   The text also stresses that one of the most important skills a developer must possess is the ability to be "productively lost".  Last semester I was mostly lost, so hopefully that will be of the productive variety this time around.

And as this may show up on the ONLY test this semester as a bonus question, this handsome gentleman is David A. Patterson.

He is most known for contribution to RISC processor design and his research on RAID disks.  He was president of the Association FOR Computing Machinery from 2004-06.  He has also co-authored six books and has been recognized by about 35 awards for research, teaching, and service.

At this point I'm happy with my post and want to stop writing, but I'm 200 hundred words short so....

In Chapter 2, we get a preview of what we will learn in future chapters.  Here are some of the covered topics:  version control, build management, documentation, bug hunting, and the mechanics of fixing code.

So what is the value of sharing?  Why is FOSS valuable?

• Shared development costs- time is money and this time can be spread out over several individuals. 
• Users can fix their own bugs...OR find other people to fix their bugs for them.  This section provides a great analogy between a car fix and a bug fix.  
• Arguably better software- since there can potentially be many more people working on a FOSS project than the number of developers any company could pay.  But didn't we learn last year that more man power doesn't necessarily mean better software? I guess that's why "arguably" is the lead on this header.
• Software that outlives its creator- code that isn't shared can turn into abandonware and die with its creator, but FOSS projects have a chance to be reborn.
• The freedom to fork- ummmm, what?  Apparently this means taking a project in a new direction without asking for anyone's permission.

This semester I am on a four person team.  My other team members are Lynn Kitchner, Chris Moore, and Bobby Jenkins.  I'm pretty excited to be on a team with such cool cats.  Since we are all a little older than our other classmates- Chris suggested we call ourselves the FOSSils.  I obviously love this idea and hope that this will become our official team name, but we have yet to vote.