Developer > Project, or Project > Developer(s)?
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.
Trackbacks
Use the following link to trackback from your own site:
http://journal.dedasys.com/trackbacks?article_id=2129
about 1 hour later:
And how, precisely, do you propose that github arbitrate who "owns" a given project? In the end, you'll end up with exactly the same problems, if the developers who "own" the project don't correspond to the people who ought to own it. On the other hand, if you just say that developers own repositories, and ignore the concept of a "project" entirely, then whatever site runs the "project" can point to the appropriate repository and change that if needed.
Github has adopted the model that corresponds to what Linus said in his Google Tech Talk on Git: stop thinking of projects in terms of who has "commit access", and just have every repository only have one developer with commit access.
about 4 hours later:
I'm afraid that the easiness of forking is one of the things that git is making very very common, and I don't really like that myself to begin with, especially from a distribution developer point of view.
I've written something about that, too, for LWN: http://lwn.net/Articles/282261 .
It is indeed a bit of a pinch.
about 4 hours later:
P.S.: if you have seen my post double, you're probably hitting the same bug I hit with typo. If you don't often use the edit functionality of your posts you might want to take out the session handling code on articles, which solved it for me.
It also stopped my session table in the database from being filled in with data each time spammers and crawlers attacked my site.
HTH!
about 10 hours later:
Anonymous: who owns a project? Whoever registers it, same as SourceForge, Google Code, Rubyforge, and various other sites do. Sure, the 'wrong' person might register it, but that very rarely happens in practice.
Linus' model works great for Linux, but it's not the only open source governance model out there. Ultimately, it should be up to the developers of a given project to pick what style they want, and their tools should try and allow that, not enforce one way of doing things.
about 10 hours later:
Diego: thanks for the tip about Typo - did you file a bug report with them? They are working on it, so if you let them know, with time they generally manage to find and fix bugs.
1 day later:
Have a look at gitorious. They're offering the same service as github but have a project-centric view instead of a user-centric one.
What's more, their code is open source so you can run your own gitorious instance.
4 days later:
The problem is with how you look at it, not with git/github.
Nearly all development happens with "forks", even in a corporate environment. A developer downloads a copy of the source tree, works on it for a while, merges in other people's changes, then eventually sends his code to a module's "owner" (which may be either a repository or another person) to be merged. Git at least lets him make first-class commits in the meantime (without "breaking the build"), rather than relying on quilt or other hackish patch management systems.
In volunteer-run FOSS projects, you want lots of forks; It means work is getting done. Economics dictates that most of these forks will merge with each other, since maintaining a divergent fork takes a lot of work.
Git and Github help developers make more efficient use of the rights they already have under various FOSS licenses. Ever noticed how the healthiest projects tend to have the most forks? If you're so worried about people forking the code that you actually want to install barriers to prevent it, then perhaps FOSS is not for you.
4 days later:
Dwayne, what's with the snippiness? "Perhaps FOSS is not for you". If you had read anything about me, you'd realize that I've been contributing to free software for more than ten years and still do, although not as much as I'd like (due to a need to pay the bills and save for my daughter's future).
In any case, you missed the point, perhaps I didn't communicate it clearly enough. I think the fact that you can clone git repositories onto your own computer, do branches, commits, and the like, without having to deal with a central repository is a good thing, and a net gain. It's one of the reasons I'm starting to utilize it.
What I am less certain of is whether the Linux model, where Linus' tree is generally regarded as the tree, works for all projects. Many projects, such as those at the Apache Software Foundation reference a project that has numerous committers. Sure, that project can be forked, but an effort is made to include new committers and generally keep things in one place, even if some committers get bored and move on. On a very practical level, with github, if the project resides at http://github.com/davidw/foobar, gains a lot of popularity, and then I lose interest in it, there are going to be a lot of links pointing at my version as the version, even if it's no longer true. That could happen with other kinds of projects too, of course, but it's less likely with an ASF style project.
4 days later:
Alexandre: gitorious looks very cool indeed, and the fact that it's open source is a bonus. What pays their bills, though? In other words, if they suddenly get popular, will they shut down as it gets too expensive to maintain?
4 days later:
David: Sorry about the snippiness. I was in a bit of a rush this morning, and I didn't proofread as much as I probably should have.
I do mean what I said, though, that if you're so worried about people forking the code that you actually want to install barriers to prevent it, then perhaps FOSS is not for you. I get the impression now that you aren't that worried. Good.
As far as broken links are concerned, I doubt it's a serious problem. Links tend to fall into two categories:
Links to particular commits, e.g. http://github.com/madrobby/scriptaculous/commit/a20280593068c1d79a27f15a8f9f5913220dd04d These links contain the commit-id, so it doesn't really matter whose tree they point to; It could be any tree that has the same commit somewhere in its history. If one of these links breaks for some reason, all I have to do is search for the commit-id, and I'll find another copy.
Links to the project itself. e.g. http://script.aculo.us/ These links generally point to a project website, not to a repository, so the when "the" tree changes, so can the website.
In general, however, the idea of "owning" a FOSS project seems to be more of a cumbersome fiction (often used to inflate people's egos) than a useful concept. The truth is that, on the Internet, you don't know who to trust, and merely being the first person to register a name isn't a great criterion.
I think a project can gain a lot by acknowledging its lack of inherent ownership, and I know that eliminating the politics around who gets "commit access" can go a long way toward avoiding problems in the future. It's free software, and nobody has nor needs any authority over a project beyond their ability to convince others that their tree is worth using.
That said, we could use better tools to figure out how different trees relate to one another. GitHub provides a nifty graph of the commits between different trees. e.g. http://github.com/madrobby/scriptaculous/network
I think that's a start, and I am hesitant to dismiss the git/github conceptual model just because the tools aren't quite there yet.