I'm looking forward to meeting that's the debate right now, actually. It's a toss-up between GNOME Cheese, a Linux desktop webcam app, and Ekiga, a cross-platform softphone, and the question is which project will be most valuable for them to dive into given the limited span of a semester.

Before we all pile into IRC tomorrow morning (9:30-10:30am EST, #teachingopensource[0] on irc.freenode.net if you'd like to join us) to debate the advantages and drawbacks of looking at one project over another, I wanted to take a moment to highlight and respond to some of the things the class already noticed in their first assignments. At the request of Dr. Ellis, I've kept the student names anonymous for this round. However, CS 490 folks: you've got good things to say, and I'd strongly encourage you to get a blog and own and claim these thoughts publicly! It's a good way for prospective colleagues to see how you analyze and think about software (and life).

All right, let's begin.

Inspired by Apple’s photobooth application, [the] project came about as a result of the Google sponsored Summer of Code program in 2007.

The program is optimized to work for the GNOME desktop interface and states that the newest version of Cheese requires GNOME version 3.

All of the downloads are Linux kernel compliant only. No version of the program exists for Windows or MacOSX systems.

You've noticed a few things already. First, Cheese is a GSoC (that's how you'll often see "Google Summer of Code" abbreviated online) project, meaning it was started by a student like you -- there's nothing magical or elite about open source participation. Like anything else, you get good at it by doing it. Congratulations on starting to do it, and welcome to our world.

Second, you're looking at a potentially tiny user base. Only a small portion of the computer-using population runs Linux as an operating system, and although a large portion of that population uses GNOME as a desktop, you're still talking about a tiny number. The mention of GNOME 3 narrows the playing field even further; GNOME 2 and GNOME 3 are massively different, effectively a full-scale re-envisioning of the GNOME user experience, so a good number of GNOME 2 users haven't yet switched to GNOME 3 (which came out just last spring) and wouldn't be able to use Cheese releases going forward 'till they do.

You've inadvertently uncovered one tough choice developers often face: which platforms will they continue forward development on? Do you spend your time supporting legacy systems so that more folks can continue to use your software, or do you spend your time developing cool new things, but for a potentially smaller number of people? Sounds like the Cheese developers have picked the latter. (The former is a great way to make money, by the way: you'll be amazed at how much businesses will pay to be able to use new stuff without changing their old systems.)

My first goal was to install cheese and to get it to run to test it out from a users stand point. Before I could download Cheese, I had to get an OS that supported GNOME... Once Ubuntu was running and Cheese was installed I found out that my laptops drivers for the web-cam were not working in Linux. After sometime looking for a solution to my problem I was only able to get a black picture to be displayed in Cheese.

Yup. Learn from that experience. Frustrating, isn't it? Make sure this never happens to your users, or that if it does, they know how to get in touch with you. But remember...

[Project founder] Siegel also states in an interview (admittedly from 2007) that IRC channels and mailing lists are a good place to communicate with developers – however the IRC channel information doesn’t seem readily available unless asked for in email.

...a lot of your users may not use IRC and may not want to subscribe to your mailing list. And think about the future: you found (and relied on) a 2007 interview; what if the links and methods that interview referenced had been broken, incorrect, out of date? (Maybe they are!) Make sure legacy stuff has a trail you can follow to the up-to-date versions of things.

On a different note, I found it interesting to see how various people interpreted development trends.

The latest version (according to the [Cheese] project site) is version 3.0.1, which was released on April 26th, 2011. The release dates for the previous versions seem fairly spread out, and a new version hasn't been released for a few months. This could indicate a decline in use and development activity for the project.

Overall Cheese seems to be a project nearing the end of its development life and just needs the occasional update for minor bugs or features that get added.

Recent releases of Cheese showing that the community are showing interest in this program are growing stronger by the day. The time frame for an update was about 1 month, and now it down to 11 days.

There's no one perfect metric for the health of a community. Is a project with a smaller number of active developers "healthier" than one with larger numbers of contributors but infrequent patches and releases? You've got to think about what you're trying to do.

For what you're doing, which is "I want to get involved with my first open source project for a fairly brief period of time," you're probably looking for the project with the most responsive people. So the number of active developers may not matter, or even the frequency of patches... but perhaps it may make sense to optimize for how likely you are to get quickly mentored -- are mailing list messages being responded to quickly? Do IRC channels answer your questions? These are things you can't find out until you actually go in and try to talk with people in the project. A project may be silent but with a helpful mentor lurking in the background just waiting for new folks to help.

At the time of writing, I have been unable to access the Project's Wiki site and FAQ's where one would expect to locate developers information on how to get started and acquire the needed source code and development tools. Both sites are hosted by live.gnome.org, and as a result of this problem, I have been unable to find out more about the project from the community, or if there was an active IRC channel I could use.

One of the things we may want to teach you is how to get in touch with folks from a project to let them know about downtime, and to listen in on existing conversations about it. (They probably already knew, but it's fascinating to overhear a project's sysadmin teams chatter about fixing servers if you're able to find their IRC channel.)

The project doesn't specifically state the number of people working on it, but it does have a community and developer mailing list as well as a developer IRC, implying a moderate amount of people.

There is no available number of how many people are working on the project.

There usually won't be a canonical contributor count. Does that make you feel a bit uncomfortable? Why or why not? Also, many communication fora does not an active project make. Look up Potemkin Village.

Cheese homepage is very liberal that it seems more of a blog oriented homepage while Ekiga is very organized and detailed that it seems more business oriented.

Ekiga also has a well-outlined community of mailing lists, IRC, which is impressive for a relatively small project maintained by only 8 regular contributors.

Despite being a small development team, the Ekiga team seems to have their act together when it comes to open source development and documentation alike.

Next, I went to Ekiga's website to fill my curiosity on finding more about this OSS project. I was impressed with their organization and how well kept their website is while searching though it.

First impressions are important. How long do you think it took Ekiga to set up that page? An hour, maybe? Pretty much nothing compared to the hundreds and hundreds of hours spent writing code, filing bugs, and so forth. But it's a vital hour well-spent, because it opened a (nice-looking) door to you in some way.

Unlike Cheese, Ekiga is still in its development phase of creating an up to date stable application with up to date features and security.

By the appearance of the two project websites, Ekiga is more organized and well on its way to not only a stable release but to a more complete program while Cheese is hard to tell where the project currently is from the point of view of the leaders.

Do be watchful, though, of the difference between "the project looks like" and "the project is." Remember, the best-dressed person in the room isn't always the smartest; sometimes to really tell what's going on, you have to get down to the basics -- don't just look at what the website says about the people, find the people; don't just look at what the website says about the code, find the code, run the code. Things may be worse than they appear. Or they may be better; I love finding diamonds in the rough and working with them to bring their project to a wider audience.

If you haven't actually tried to install and run the product of the project you're thinking of contributing to, STOP AND DO THAT FIRST.

Both programs have easy-to-find links to their respective logs in the BugZilla tracking platform, and both have an extensive number of bugs reported in various stages of resolution. One who wanted to involve him/herself in the development of FOSS projects via working on bug fixes could easily scan through one of these lists and choose an issue to work on.

A great next step would be to look deeper at some of these bugs -- are they well-written? Can you understand the problem and how to reproduce it? Do you see why it's actually a problem that affects a lot of people and needs to be fixed, rather than a minor annoyance the reporter should just live with? Do you understand the desired behavior of the program, what it'll look like when it's working? Can you get a feel for the sort of skillset and time commitment it would take you to tackle this problem? ("Needs someone to update this code from Python 2 to Python 3" is far more specific than "Needs someone who knows Python.") Can you find resources and mentors for the bits you don't know?

Ekiga, formally known as GnomeMeeting...

[Ekiga] started around in 2001.

10 years is pretty ancient in the open source world. That's a good sign if it's still active; it means it's filling a role in the software ecology.

Projects, particularly older projects, sometimes get rebranded and renamed for various reasons. It's occasionally interesting to find out why -- maybe there was a fork, and you may end up wanting to work with the fork instead of the "original" project because the fork fits some aspect of your work better. In any case, whenever you find an alternative name, it's not a bad idea to search for things under that name as well; sometimes you'll unearth previously hidden documentation, tutorials, and people.

All of this is done using a modern day GUI [in Ekiga].

The overall design of the [Ekiga] program is very similar to Skype in many ways.

This suggests a source of interface ideas and a good comparison for both feature development and marketing. "How are we doing in area X compared to Skype?" Then again, you may not want Ekiga to be an open source Skype clone. This is the sort of design decision that plays itself out not just over mailing lists, but also in code; if you want a software project to go in a certain direction, the best way to make that happen is to just start visibly doing it.

The contrast between the next two notes (from different people) made me smile:

A the time of writing there are 261 known, unsolved bugs for Ekiga.

As a project, Ekiga does not have many known bugs with only 4 noted by Bugzilla.

I'm not saying one person is wrong and the other right -- but it's probably worth the two of you getting together and saying "well, why did we come up with two different answers here, and which one should we believe?" Conversations to explore.

Finally by Egika posting the project leader names for the individual projects, it seems like it would be easy to contact the right people for whichever project you may assist with.

...if those names are accurate and up to date. Try emailing the listed names and see.

The business model I have noticed for Ekiga is donations. There is a list of several independent individuals who have donated hardware and money to the project, as well as a list of companies that have donated money. This, along with community developers, keeps Ekiga an open source piece of software.

So let's try to take this one step further (leaving aside the question of whether "donations" is a business model -- might be interesting to ask a business major what he/she thinks about that). What, do you think, motivates those individuals and companies to make such donations? What do they get in exchange? (Yes, some people open their wallets solely out of the goodness of their hearts. Most don't.) Knowing those motivations, how would you (as an Ekiga developer) act in order to increase the amount of donations? You may also be interested in this essay by Mako Hill on the effect that funding has on a volunteer-based project.

Phew. Long braindump, I know. Thoughts? Comments? Looking forward to discussing this with folks tomorrow morning!

[0] We may not actually be in #teachingopensource tomorrow morning -- we may move to project channels, etc. for conversation -- but I (mchua) will be there, and can point anyone who pings me towards the conversation at that time.