I DISAGREE -> "Developer-centric version control considered harmful"

Since I couldn't comment on last Martin Aspeli's blog post (couldn't login with openID, maybe its only me, but i think something is not working right there) I decided to write my response here. There are many arguments that don't hold and a lot more is not being covered and should be mentioned.

As first I'm excited that Github is becoming so popular. I'm git user and just having git in the name of Github makes me happy. No joke, really. But all of the talk Martin did in his post should go in direction of "social coding portals" like: github, bitbucket, ... and probably some more ... not only Github itself, but this you probably know.

Lets go line by line...

from Martin's blog:
Someone else forks my repository and tinkers a bit. They then email me to ask me to pull their changes into my repository. If I have the time and inclination (and read my email), that may bring us back to one canonical version. However, in time, there is a single point of failure on me as the maintainer. At some point, I may stop caring or get too busy to follow up.

I agree with this, but the same problem you will get with most of the projects out there. In Plone world we have collective where almost everybody has commit rights, so we kinda got spoiled that you can simply commit to some repository. With all other projects you still need to contact the author to get your patched in. Its been like this since ages. Just with git this is done with one or two commands, while applying patch takes a little more.

from Martin's blog:
Here, Git has an answer: anyone can fork my repository and take over ownership. This is powerful and adds fault tolerance to the "single maintainer" model. But socially, it is dubious. Who really controls development? Who has a right to publish a new release? What if I come back after a few months and decide I wanted to own the project all along? We now need to reconcile the two forks. This may be tricky. Perhaps we don't do it. People now have to figure out which one of two versions of the software to "bet" on. This is onerous, and likely to deter other contributors.

Normally you check pypi page or home page of software you want to use, there you get direction where to start looking for source code. So once you found a place, then here is where Github shines. All forks which are done through the web are considered friendly forks, since its easy to commit back. Its even possible to look the history of forks and where they split. And now the "porn" part, you can actually diff different forks in Github, to see the differences. You hate/love me already? :)

from Martin's blog: 
Let's say we bring the main line of development back to "my" repository. Once again, I have to commit a lot of time to reviewing and pulling in changes. Maybe I fall behind. So another user comes around and wants to work a bit. Which one of the two trees does he fork? Which ones does he pull in updates for?

Look the link above. With Github is easy to look friendly forks and compare changes. Its all just few clicks away.

from Martin's blog: 
Perhaps I decide to relinquish control to another developer. I let my GitHub fork die, and expect people to use another one. But how do I manage this? How do I hand over ownership to someone else's account without confusing people who've been using my repository? Or people who stumble upon it in the future?

Now for every little project you start and you start your own project in some of the tools. its kinda silly, makes its hard to maintain. since you will probably use it only you. but if the project overgrows you then best way is to create new github user as you would do with any other project oriented system out there.

from Martin's blog: 
Here's a cautionary tale that happened to me today: I've been using Soaplib, a Python library for building SOAP servers. There was a release on PyPI, but it had a bug that meant I had to get a checkout. The PyPI page listed a GitHub URL, so I used that to clone the repository. A few weeks later, all our builds suddenly broke. The remote repository was gone, deleted from GitHub. Turns out, the original maintainer had given owner responsibility to another person, who has his own GitHub repository. Development had gone on there for months, unbeknownst to me. One day, the original maintainer decided to delete his repository to not confuse people. Noble, but rather inconvenient.

This can be easily solved by you friendly forking Soaplib, for the time of development. Then in production you of-course wont use any url dependent resources, right? Then even if the project is moved you can easily friendly fork it again or just use the version. I never ran into a product that was discontinued while developing. But as also Martin said, this is rather minor thing (inconvenient).

from Martin's blog: 
Again, there are lots of solutions to this problem. However, I think that fundamentally, as a user and potential contributor to a library, I want to find "the" repository and commit my changes there. A personal fork is a good idea until I can get access, but there has to be a path for me to get repository access and become a recognised, trusted contributor. Open source projects have used this model for years, as a way to encourage, recognise and empower contributors and build a shared sense of ownership around the project. I expect the project to be bigger than any one contributor or owner, and I expect the infrastructure to be able to outlive their involvement.

I think this is a feature of Github that you missed out. Organisations. For quick example look at MongoDB.

from Martin's blog: 
This is why, for things that are a bit bigger than one person, and a bit smaller than a major open source project, I've got mixed feelings about GitHub, and even mixed feelings about Git itself. They are great tools. I find myself wanting to use them. But I also worry that they are too flexible for their own good, and that the most obvious way of using GitHub is not a good one for open source projects.

I dont see such problems there. Since others can work under your github account or you create its own project github account. Now saying that Git is "a little to much" for small projects. You can also give your contributors possibility to use Hg or Svn ... AT THE SAME TIME and commiting to the same codebase. (more in next comments)

from Martin's blog: 
I think Hanno Schlichting put it well: With Subversion, you get a development model, which, whilst not perfect, is easy to understand and has worked out very well in practice for numerous projects. With Git, you're expected to make up your own model. I don't think people are very good at that, and rarely plan ahead for when their code outgrows them.

I know it's possible to use Git like Subversion, with a central repository. But I'm also not seeing a great many people doing that. We have to remember that Git was first built for the Linux kernel, which has a development model unlike most other projects, where it really is up to a set of core maintainers to review every patch and selectively pull it in. They need the kind of flexibility and power that Git offers. For many other projects, I'm not sure this flexibility is always a good thing.