Project Report and Ideas for Contribution

As far as the project report, the ITK site contains detailed descriptions of the project, it's functionality, and history of development, as well as a list of core members.  Writing up the report is as simple as annotating these sections of the website.

After signing up for the ITK development mailing list, I sent out an email to the team introducing myself.  Additionally, I provided background information on the intentions of our Software Engineering Practicum class, and asked for any feedback on ideas for contribution.  Within the day, I had heard back from 3 separate members welcoming us to the community and directing us to their bug tracker and ideas wiki.

The welcoming responses produced a sense of acceptance that I had not experienced in the past working on OpenSource projects.  Although project ITK is still somewhat intimidating of a project, I am now even more glad that our team has chosen this project.

Along with being greeted by these 3 developers, several ideas for contribution were also provided.  The ideas included tackling bugs from the bug tracker, working through some small problems found on their ideas wiki, as well as a larger and more indepth mentored focus idea.  It was suggested that we start off by working through some bugs on the bug tracker so that we can become aquainted with the submission process, as well as allow the community to assess our capabilities.  Several problems on the ideas wiki, specifically the "wish list" and "small problems" section also sound promising for potential focuses.  As far as the specific mentored project, it is great to have someone already volunteering to mentor us, but the application seems to be a lot more intense, and it would behove us to start with smaller tasks first, in my opinion.  Regardless, it is nice to have somewhat of a sense of direction in the project.

The Cathedral and the Bazaar, Mailing Lists, and IRC

In The Cathedral and the Bazaar, Eric Raymond discusses his approach to initiating and developing an OpenSource project.  His strategy and process was based around the success of the Linux OS.  The paper is a recount on the step by step thought process of development.  Throughout the paper, he conveys his strategies through 19 'lessons' that developers should ponder.


Towards the end of the paper, he contrasts his experiences with the ClosedSource program manager's functions.  He then goes on to argue the restrictiveness of the ClosedSource process by showing how none of the functions are applicable to OpenSource methodology.


The key concepts that I've taken away from this paper are that designers should follow their hearts and design to achieve personal goals.  Also, as a designer, you will know when an approach is correct because it will be simple and provide a cohesive set of functionalities true to the identity of the project entity.


After reading the paper, I'm further convinced of the effectiveness and inherent beauty in OpenSource development.


In addition to readin "The Cathedral and the Bazaar", I registered for ITK's mailing list, and spent a good deal of time fully examining their website.  I also started to read the ITK Software Development Handbook, which covers everything about development for the toolkit (includes architecture, class and function documentation, etc.).


On a side note, I emailed the ITK development team introducing myself, our team's intentions, and asking for any initial direction.


As far as an IRC channel, I am familiar with mIRC, but I don't believe that the ITK development uses an IRC.  In the email to the developers, I asked if they used any sort of real-time communication tool.  Hopefully I will get a response...

Picking Projects

I was unable to join the rest of my group for Thursday's in class meeting, so I did some project research on my own and emailed them a list of projects that I found interesting as my contribution.

After reading the project descriptions, the three that I initially found the most interesting were STEM, GeoChat, and Helios.  However, upon further inspection, I realised that GeoChat had a broken link, and the other two were poorly documented and didn't have clear methods of contribution.

The four that our team eventually decided on were ITK, Plone, Tor, and VuFind.  After researching all of them further, I have really become interested in ITK.  Not only is the topic fascinating, but the documentation is good, and they seem to have well defined methods of contribution.  Plone and VuFind were also interesting, but ITK is the winner in my mind.

We plan on meeting again before class, and hopefully we will all be able to agree on a project that we all like.

Blog, Wiki, and POSSCON

In class, we formed into teams for the semester-long OpenSource project.  My teammates include myself, Andrew Bissada, Glenn Faken, and Matt Lyons.  We also established group roles and named the group "Work Without Pay."

After class, I created a blog space using Blogger called "Perry's 462 Blog", registered on the student Wiki, and created a link from there to my blog.  I also registered for POSSCON using "student" as the discount code.  I wasn't sure which day to attend, so I marked them all, and will decide when to go once my schedule is more finalized.

In addition, I read chapters 1 and 2 of "Teaching Open Source".  These chapters contained mostly background information on FOSS and OpenSource projects in general.  I found the Contributor Mountain pyramid model particularly interesting (found in chapter 2).  In this hierarchical model, we all start as users, and progress to seekers, collaborators, and then contributors.  Climbing the ranks take place as one becomes more involved in a project.

Also, my teammates and I decided to get a head start on choosing a project, so I read through the summaries of each project.