It was kind of interesting to see this the other day, on the train from Monselice to Padova:

That’s a Debian system, kernel 2.6.8.1, which appears to have some problems booting. That’s not the only problem with the train system in Italy, unfortunately:

My Padova->Monselice train, roughly a 20 minute train ride, was 65 minutes late, and would end up being nearly an hour and a half late. Ouch! To be fair, the train system in the US is actually even worse, if that can be believed. And in Austria, while they run on time, they’re so expensive and don’t run often, so that it’s often much more convenient to drive.

Since this seems to be fairly constructive, I’ll keep going. Those not interested in Github, or the dynamics of open source code creation can safely tune out. Chris, the Github dude, has some more to say:

http://ozmm.org/posts/forking_continued.html

I mentioned the Network Graph and Fork Queue but David mentioned neither. I think he doesn’t know what they are, probably because I didn’t explain what they are 🙂

I had had a look at them, and they’re handy tools (I would never accuse Github of not doing good work, that’s not the issue at all), but I would respectfully submit that perhaps Chris is looking at things from a very Github-centric perspective, in which it’s second nature to go look at those. They aren’t obvious, and certainly don’t jump out at the user to say “hey, maybe this code your looking out isn’t the latest and greatest!”. For someone just cruising around, perhaps it should be more evident who’s the ‘top dog’?

Chris then goes on with a very helpful and illustrative demo of how things work at Github, which is good stuff.

However, at the end, he says something that I don’t agree with:

It may seem strange, and perhaps even like a lot of work. “Why should I have to check to see which is the most current? In the old model, there’s always a canonical repository.”

That’s precisely the problem. It does seem like a lot of work, especially when your search space is not limited to Github, but may include other places like Sourceforge, RubyForge, Google Code, project specific sites, and so on.

In the old model, actionwebservice wouldn’t have made it past 1.2.6. Welcome to distributed version control.

Plenty of ‘old style’ projects have survived beyond their founders’ interest in the project. What happens is that you ask for permission to work on the project, and either :

1. It’s given to you, in which case you can keep working on the canonical code. For instance, someone could have asked DHH to work on the RubyForge version of actionwebservice. Did they? Did he say no? At the very least, he could have been asked to point the RubyForge actionwebservice page at some other site with a more current version of the code.

2. You have to fork the project, and in that case, sure, you might as well have been using the Github model.

I’ve often found that people are happy to let you contribute to their projects, though, and part of my original point with all of this is that if people just go spitting out forks willy-nilly, it creates a “paradox of choice” type problem, and perhaps takes something away from the community aspect of open source projects. As people are fond of saying at the Apache Software Foundation, it’s about the people, not necessarily about the code. I’m not saying that forks are always bad and that everything should be centrally done, but there’s a balance to be struck between people just working on their own, and some sort of onerous, bureaucratic Central Project Authority. It’s nice that people who want to improve the code make themselves heard on a mailing list/forum/whatever, and thus cover the “people” part of merging in new code and new ideas. More often than not, help and contributions are more than welcome. Design decisions and conversations recorded on mailing lists are available for people to peruse in the future when they have questions.

Just to repeat something that bears repeating: I am not claiming that Github will lead to social disintegration of open source projects or anything drastic like that. However, I’m a bit wary of certain patterns I’ve seen. It’s certainly possible that I’m wrong – as I mentioned, one error I might be making is that people are dumping code they simply wouldn’t have shared on Github, because Github makes it so easy. I do hope my worries are unfounded, and in any case, it’s a good thing that the Github guys are interested in the problem too, and will hopefully do things to alleviate it where possible.

Before I get started, I want to make it quite clear that I have no problems with Github – au contraire, they provide a very nice service. What my speculation centers around is the social dynamics of Github.

One of the Github guys writes a nice response to my original post, here:

http://ozmm.org/posts/linux_vs_classic_dev_style.html

First of all, apologies for the comment bug. In theory, it has been fixed by the Typo guys, I just need to find the time to upgrade.

Chris mentions that it’s possible to create a “SourceForge style” project on Github. I see that it’s possible to add collaborators, so I guess that’s what he means. I still find it a bit ugly to have things at …/davidw/… but that’s not very important if the URL is at least stable, rather than hopping around to whoever has the latest fork and updates of the code in question.

In my other post, I talked about people being less interested in doing what it takes to contribute to existing projects, rather than forking them, unless it’s really called for. Here’s a concrete example of how things might go wrong. At my current consulting gig, we were looking at utilizing actionwebservice to do some SOAP stuff. That code is not part of Rails anymore, but that’s not the problem – surely someone has decided to take up maintenance of the gem, right? Well, yes… but let’s look:

root@fortrock:~# gem1.8 search -r actionwebservice

*** REMOTE GEMS ***

actionwebservice (1.2.6)
datanoise-actionwebservice (2.2.2)
dougbarth-actionwebservice (2.1.1)
nmeans-actionwebservice (2.1.1)

So we have the original, clearly out of date, and three others. Yuck… I guess we’ll use the 2.2.2 one, but who knows if perhaps the others contain some good stuff too? Let’s Google it.

http://www.google.com/search?hl=en&q=actionwebservice

The first link is to a RubyForge project, which is basically dead. A few links down, there is a link talking about a more recent version, at the Datanoise site. However, it’s one of many. Confusing. If you go to the github page for the datanoise version of actionwebservice, the README has this:

The latest Action Web Service version can be downloaded from
http://rubyforge.org/projects/actionservice

Hrm. We were just there and that doesn’t seem quite right… Sure, it’s an easy enough oversight to ignore, but it adds to the confusion.

Now, this is not really a serious problem, but do you see how it could get worse over time, as various people fork the code, write blog entries, and so on? It would get harder for someone interested in utilizing the code in question to ascertain which is “the” version. It’s not hard to imagine situations where two forks add different bits of useful code. Typically, in situations like this, new users, those who don’t know the code at all, are also the people least able to look through all the diffs and changes and log entries and what not in an attempt to merge any changes that might be useful. This leads to a “paradox of choice” type of problem.

Another consideration, this one more positive, is that perhaps people are putting code in Github that, in the past, might have simply remained on their own computers, with no effort whatsoever to share it, so in that sense, Github might be doing people a service by at least making the code public.

However, even in that case, if the service fills up with code that people have simply “thrown over the wall”, rather than creating a genuine open source project, with a community, communication channels, and so on, it could get a reputation for having code that you have to handle with care, as a lot of is just stuff slapped up there without much thought to quality or continuity.

Anyway, the Github guys have done a nice job with the service, and I’m sure they’ll continue to improve it. Who knows, perhaps they have some good ideas about mitigating some of these potential problems that they’ll be rolling out soon.

I’m terrified of flying (actually heights more than flying, but planes tend to go pretty high), and seeing all the images of Flight 1549 floating down the river didn’t help things. I’m glad everyone got out ok.

An interesting detail about the whole story though, from my point of view at least, is all the press hits that Karl Lehenbauer‘s http://flightaware.com/ got – it was mentioned on CNN and a number of other places, and seemed to handle the traffic ok. A little known fact is that, as can be seen from the HTTP headers, FlightAware is built on Apache Rivet, which was one of my first serious open source projects. It’s good to see them doing well, although it’d be nice to see them help out a bit more with Rivet. It’s still good code, and does what it does quite well, but needs some love.

I’ve been fooling around with “git” lately – it’s useful for local projects where I don’t want to have to set up a remote server, and it also seems to be “the way the wind is blowing” – lots of open source projects are starting to use it, so I might as well familiarize myself with how it works.

The github service seems to be very popular at the moment, and it’s not hard to see why. They’ve created a very useful service, and give it away completely free for open source use. That’s a pretty good deal! It’s also an easy to use site that’s well integrated with git, so you can see lots of stuff graphically instead of fooling around with command line tools.

However, I have a nagging doubt. Github apparently bases everything around the developer. In other words, projects hosted there are mostly attached to a developer who ‘owns’ the project, rather than existing on their own. There are a few exceptions – there seems to be a ‘rails’ role account to manage Rails, rather than having it belong to, say, DHH, so it’s not impossible to do something in a project-centric fashion, but it doesn’t seem to be very common either.

What I’m wondering is what sort of effects this might have in the long term. Github, and git itself, make it very easy to ‘fork’ projects. Could, or will this lead to a situation where people don’t try so hard to get their code in the ‘official’ branch? What happens when someone loses interest in their project? Sure, someone else can fork their repository, but if all the links were pointing to the first guy, because he was the main hacker on a project for X years, they’re not going to switch overnight even if guy B takes over maintanance. And in the meantime, casual searchers might turn up the ‘dead’ branch, or simply be confused as to who’s doing what. This could make things confusing for someone who just wants to check out some code and start using it…. trying to sort out various revisions and ancestry of a project could be quite discouraging.

At the Apache Software Foundation, on the other hand, people are obviously very important, but projects are the organizational unit that people get involved with, and a lot of emphasis is placed on not having one big benevolent dictator, but on having a group of people who make decisions and act as arbiters of what goes into the project. People can come and go as they please, but the project, and, importantly, the links to it, remain the same over time (barring any big, unforeseen blowups).

As far as I can tell, this is not a git problem, but something related to how github organizes their site. And, of course, it’s possible that I have simply missed something due to my lack of knowledge of git, and not being more than superficially familiar with github. Even if I’m right, it shouldn’t take that much effort for github to create a system where it’s possible for multiple people to ‘own’ a project.