Ohloh Blog

Almost anyone I know who's deployed a rails app has, at some point, cursed at the mysteries that lie behind FastCGI. Once it's setup properly it works very well, but debugging the interim steps is a painful rite of passage for rails developers. It's not so much that any aspect is too tricky - it simply takes way longer to get working than you'd think.

Well, as I browsed around tonight, lo and behold, I stumbled on this:

Caveat: yes - I realize their site might be suffering from a different problem than failed FastCGI processes- but it gave me a chuckle anyway.

I read this post by Seth Gottlieb. Just came across it today.

Seth addresses how folks can evaluate open source communities. According to him, one can look at general activity, bug lists, leadership, execution, participation and an economic ecosystem.

At first glance that all seems to make sense, especially to a guy who has been involved in proprietary software development. But the more I think about it, the more I wonder if all these observations are really germane to open source development.

Certainly general activity is the first thing that anybody should look at. Is there anybody developing the software? If so, how many people are working on the project?

As for bug lists, I wonder how effective bug tracking for open source projects can be since so many of them use mail lists for ad hoc bug tracking. We considered adding bug information, but rapidly determined that many (if not most) open source projects do not use bug tracking systems as in proprietary software development. We are considering tracking mail lists as a way of viewing community activity on a project instead of bug tracking.

I also wonder about his comments on "economic ecosystem." He writes, "Are people making money off this project? If there is no money to be made, people will gravitate to other interests that pay the mortgage." I'm not sure this is true. While making money off one's open source work is a fine thing, I don't think this is everybody's motivation. Just look at GCC, a monster effort which is arguably one of the most significant open source projects out there! Like GCC, there appear to be plenty of projects on our system that are labors of love rather then money making exercises.

I would also add a category to Seth's list called "Use and Satisfaction." We find it interesting to see how many people actually use an app. Further, it is interesting for us to see what other apps they use with it. That is the goal of our "Stack It" feature. We also have a new feature. As of today, users can rate a project and review it. I really hope these two features take off, since the information they yield will be super useful for any prospective open source user.

As always feedback is appreciated.

Thanks,

--Scott

I read this post on Matt Asay's Blog this weekend on a new company called SourceKibitzer that collects metrics on about 60 popular open source projects written in Java.

This is great news for open source users, as there appears to be more services coming online that aim to make it easier for open source users to find, evaluate and produce open source software.

I would be curious to see what folks think of SourceKibitzer's relatively deep metrics, as we have made the trade off to pursue more projects across more languages with fewer metrics. Also, I would be interested in whether our users would like to see their private projects indexed in the same way that we index open source projects.

On a slightly different note Matt writes: "What I don't understand is why the company doesn't simply sniff out Java projects on Sourceforge and do the analysis on a proactive basis."

The thing is, as we found out here at Ohloh, many of the most popular open source projects in Java (and this holds true for other languages) were developed on other forges or they were migrated off SourceForge.net long ago. We collected project metrics from SourceForge only to find that many of the projects were dead or had been moved. That's why it's a challenge to be comprehensive in scope, i.e. because many important open source projects are not on SourceForge.net.

If you have any thoughts please mail me at scott@ohloh.net.

--s.

Robin and I have a recurring debate regarding projects without source control systems. But before I explain the debate, a little background is required (ok, skip the next 2 paragraphs if you must).

Ohloh only offers development metrics to projects with openly-accessible source control systems. That way our analyses can go back in time and get a clear picture of how the project was built. Even with only CVS, Subversion and Git source control system support, we get pretty good coverage. However, it's not universal.

A major hurdle are projects that don't expose their source control system at all. They typically offer up a snapshot of their source code instead. We've been considering adding support for Ohloh analyses for this specific case. Of course, the analysis would be downgraded: no contributor information or timelines could be determined. However, we could still detect source code licenses, languages and overall codebase costs.

This is where the debate comes in: Robin argues that projects that don't make their source code repositories public are highly suspect and Ohloh shouldn't bother trying to provide degraded analyses. In other words, if you're considering using such a project, the sheer fact that they don't make their source code control system public should be enough of a warning for you to reconsider.

My position is slightly more conciliatory. I agree in spirit with Robin but realize that there are probably too many special cases for us to generalize this way. A good counter-example is PCRE. It's written by a single developer who doesn't bother using source control (why? see below). However, it's a well written, very useful library. Right now the Ohloh project page for PCRE is very empty. Ohloh can't connect to his repository -- he doesn't have one, remember?

Shouldn't we at least provide some basic info instead of nothing?

Well, here's Robin's summarized position: there are 3 possible reasons projects don't expose source control systems:

1. they don't use one
2. they are too lazy to expose it
3. they have something to hide

When it comes to picking an open source app/library, none of these reasons instill much confidence. So in the end I have admit: I agree with Robin.

Given our limited development resources, we'll skip supporting non-repository projects for now.

jay

Periodically, I review the top Ohloh searches to see how we're doing in terms of covering the projects people are most interested in. [Incidentally, last month's top searches were for "linux", "mozilla", and "drupal"]. We're doing pretty well, and have managed to cover almost all of the popular projects.

One prominent omission is the GNOME desktop environment. I thought it curious that no one had added it yet, so I quickly made a project page for it, and was happy to find that they have an easy-to-access CVS repository.

Then came the surprising news: the GNOME CVS repository has over 600 modules!

I found myself faced with the daunting task of manually entering 616 module names, and was completely unsure of which modules are really necessary, which are deprecated, which are duplicates, and which might better be counted as separate projects.... In other words, I needed an expert's help.

Let's get the ball rolling. This post is a call to action -- if you're involved with GNOME or have some idea how the code is laid out, drop us a line or start working on the project pages.

If it turns out that I really just need to add all 616 modules, well, I guess that's what scripting languages were invented for :-)