My FOSS Preferences

The class teams are to choose three open-source projects that we would like to participate in.  The tricky part is that we need to choose projects that have active communities.  So TeamFOSSil's prerequisites for the team project are as follows:  the open source project has to be written in python (member preference) and has to have an active community.  This shouldn't be too hard to find, right?!

Number One Choice:  Django 

The "D" is silent- pronounced "Jang-oh"

It was suggested by Lynn that we look into Django.  I had no idea what Django was in regards to open software.  The first thing that popped into my head was Jamie Foxx in that Quentin Tarantino movie- EXCELLENT movie by the way.  "Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design."  In a nutshell, it allows you to quickly build high-performing Web applications.  It was originally developed to manage several news-oriented sites for The World Company  of Lawrence, Kansas.  The framework was named after guitarist Django Reinhardt who is often regarded as one of the greatest guitar players of all time. Django has some bragging rights.  Here are a few sites that use Django- Instagram, OpenStack, Mozilla,  and (my personal favorite) Pinterest. Django is written in Python and has a VERY active community making it my favorite choice for this semester's project.  It also seems very newbie friendly- another bonus.

Choice Number Two:  SaltStack

Bobby vaguely remembers hearing about this choice at some CSCI talk.  SaltStack is a new approach to infrastructure management- it runs within seconds, scalable enough to manage tens of thousands of servers, and can communicate with these servers within milliseconds.  For newbies, the Saltstack site says- "There is no need to introduce yourself, or ask permission to join in.  Just help and be helped."  I like it.  There is a lot of documentation, an active community, and even a YouTube channel!  Plus it meets all of our prerequisites because it is indeed written in Python.  Oh snap.

Choice Number Three:  Gramps

This choice started off as a joke since it would fit perfectly with our FOSSils team name- Gramps just goes so well with our old team member theme, but it could in actuality be a decent choice.  This is free and open source genealogy software.  This is software for genealogists or genealogist hobbyists- a way to keep them organized.  Now the community for this choice is a little lacking- definitely nothing like the community for Django.  The site says that the filing and tracking of bugs has low traffic, but that discussions on using Gramps and issues relating to software development have medium traffic.  It is written in Python as well- but we have two much much better choices above.

The preface of the book reiterates why participating in FOSS is advantageous.  Alright. You've convinced me.  The preface also goes over class organization, a sample syllabi, and other support and guidance.  

Chapter 1 gets more interesting.  From last semester's readings, I was aware that software failures do happen, but for some reason I was still a little shocked to read that according to the 2009 CHAOS Report, only THIRTY-TWO percent of all software projects were completed on time, on budget, and with full functionality.  The text lists many reasons for these software failures, but it singles out "improper choice and deployment of an effective development methodology" as the main culprit.  

I will sign off with the

Four Freedoms of FOSS: 

1. Freedom to use
2. Freedom to modify
3. Freedom to distribute
4. Freedom to improve

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.

LAST BLOG POSSSSSST OF THE SEMESTER!

We had another team meeting yesterday.  We are planning to meet on Wednesday once again to practice our presentation.  Diana and I talked to Professor Bowring about our deliverable thus far.  It needed a lot of work.  I spent most of last night polishing it up even more.  We still have some loose ends to tie up, but we should be well prepared for Thursday!

Reflections

Not as prepared as I would like to be for this practice presentation.  Thought we would have all 25 test cases ready, BUT that is not the case.  Hopefully people prepare ahead of time next time.

Progress Yet Again!

We have come a long way since our last presentation.  Our framework is in good shape and our main script and helper scripts work well together to produce a test report.  We hope to be prepared for the presentation on Thursday.

Stress.

Thanksgiving is right around the corner as are due dates for projects and...dun dun duuunnnn FINALS.  To say that I'm stressed is an understatement.  Thankfully I'm not alone.  I've gotten a good start on the deliverable, it now has a lengthy introduction, a detailed framework description, and I've started writing a detailed description of Weka.  I still have a long way to go and the goal is to get that accomplished over the weekend.

Deliverable

Our deliverable needs a lot of work.  We got ours back with comments last week.  "How many pages should we have?"  We asked.  "Around 50 pages."  He replied.  Our response: ?!?!?!?!  I'm now in charge of making the deliverable more "verbagey".  Be prepared to be awestruck by the verbage.