UCOSP & Freeseer

This fall term, I have the opportunity to join the Undergraduate Capstone Open Source Project (UCOSP). Like traditional Capstone-like courses, the goal of this is to undertake a large term-long project usually as part of a team. Unlike Capstone (usually), UCOSP brings students from various schools together to work on one of several open source projects.

For a while, I have been trying to join the open source community. Surprisingly, I had issues. I realized early on that I didn't really know what it is I wanted to work on. I knew I wanted to contribute, but the overwhelming thought of trying to do something useful for the Chrome or Firefox projects kept me away. On top of that, even with a few years of development experience and the drive to learn programming languages used in project of interest, I simply didn't have time to learn them.

Alas, after seeing a post about UCOSP, I decided that was my ticket in. Without a second thought, I enrolled. Of all the available projects, I chose the Freeseer project. I should note that the others were interesting as well, but Freeseer was a cool idea because I have tons of Python experience, I've never worked on a multimedia tool and the code base was small and young which makes it easier to contribute great ideas. Anything we add at this stage is revolutionary for Freeseer and will affect its growth. On the other hand, working on a huge and widely developed project, contributions are just as important, but on a much smaller scale. Really, I feel this is true for code bases in general, not just open source.

Freeseer is an open source screencasting application suite. It records audio, it records video from the desktop or a vga source and it does so using a simple easy to comprehend user interface. If you haven't played with it, know that it is as simple as "push to record, push to stop". It like an old VCR unit (if you have one lying around) which is why the makers of Freeseer pronounce it "Free-C-R".

From a user point of view, the application installs rather easily. Simply download the installer for your platform and once the install completes, you're good to go. For developers, it's not quite as simple. In its current state,  it's easiest to develop for Freeseer on a Linux box - actually, Windows didn't turn out THAT bad for some.

For UCOSP, we met for a weekend "first sprint" and students from all the UCOSP projects traveled (some cross country) to meet up in Kitchener. We met each other, our team mates and project mentors. We received a tour of the Google office, had a lunch in their cafeteria and heard them talk about Open Source - after all, Google did support UCOSP this term and Facebook is doing the next one.

Once we broke into our teams, we got to know each other more. This term, according to the mentors, the Freeseer team is larger than usual. I suppose this is a good sign as there is plenty to do in Freeseer and the team is eager to contribute. We spent the weekend discussing Freeseer: our mentor Andrew Ross spent a good deal of time explaining why he started Freeseer. In short, there was a need for a simple and free solution to recording conferences.

Freeseer is written in Python and is easiest to develop for on the Linux platform. We spent most of Saturday realizing it wasn't that simple. If you use a fresh Ubuntu 12.04 install, Freeseer takes about an hour to install and works mostly well (some things were broken). I'm pretty sure those developing on Windows got it in about that much time as well. Once finally installed, each member was to decide how they would contribute to Freeseer and write a proposal for a term-long project around it. Some have opted to add a new feature - like a YouTube uploader, a YouTube streamer, while others are stabilizing existing features - like alerting the recorder when microphone volume is low.

For my project, I am working on the testing area. Currently, Freeseer has no unit test suite, no use cases and a lot of new code which needs to be refactored and reviewed. My proposal is to investigate and suggest a method of integrating unit tests into Freeseer. Once the community agrees on the design, I'll move forward and implement some unit tests. In addition, I'll be taking an in-depth look at some modules in Freeseer to determine how to stabilize some components, essentially refactoring. I feel that stabilizing Freeseer and ensuring that future contributions are also stable will make Freeseer a more adoptable tool.

Blog entries will document the process I will follow to select a test framework, add it to Freeseer, implement unit tests and overall ensure that future contributors will be adding to a solid, stable and bug-free open source project!