... and decided to align just for me.
Last week I had a discussion with a friend. We have a small pet-project growing between us, and I suggested using free accounts at GitHub to collaborate. A couple of days, I got a call asking "But how can I hide the project?". It was mostly a WTF-moment for me. The concept of developing this in a closed environment wouldn't even register with my conscious thought. Eventually I talked about GitHub private repositories and the fact they are a paid-for-feature.
It was a wake up call, I guess. I've started mirroring my personal projects to GitHub some time ago, and I haven't completed any of them. I've recently upgraded my account at GitHub, not because I'll use the private repository feature, but because hosting my free stuff also costs them money (and I like the HTTPS protection everywhere).
At the same time, a online thread developed about programmer insecurity that fits like a glove to this situation. It started with Ben Collins-Sussman and a couple of replies I found interesting:
The personal experience above, reading through these articles and their comments, and my own "push everything" current frame of mind, all three are having a big discussion inside my head right now.
I don't believe hg is more prone to sharing than git as Ben suggests because its not the tool that makes it happen. Tools are not trend setters, they just make them easier to set. There where a lot of projects very successful and with a lot of developers and collaborators working only with CVS, so git and hg (to name just two) are not magic wands that make your project a success in that department. I believe they will make them easier to collaborate on but that's it.
I've also don't agree with Ben statement that DVCS make going dark easier. Again, its not the tool, its the mentality of the programmer. Sure, the argument that creating a branch and working alone in the dark with git/hg is much easier than Subversion, but this is the first time I see someone sell this as a positive thing. Putting artificial barriers to collaboration is just duct-tape over bad social skills.
But programmer insecurity is a fact, not fiction, and it must be dealt with properly, or we risk antagonizing a lot of them. Funny that Ben says that hg is more share-friendly be default. We could argue that git is more protective of each collaborator insecurity because they get to choose which branchs are sharable-quality, they don't automatically share every branch, and so, the programmer is free to fail in his topic branches and push only is trunk/master branch with the cleaned up work.
I've also read over those articles that the rebase feature of git is destructive and allows one to hide our bad code. Well, I want my code reviewers to have a good understanding of the feature I'm sending them, and sometimes, my reasoning is best explained by a sequence of three patches and not the nine it took me to get there. Having said that, I would like very much the ability to duplicate a branch and rebase in a single operation, to keep my personal path to the final set of patches intact, as a parallel branch. Knowing how you got to your three commits is very helpful sometimes.
And speaking of git missing features, I like to have lots of branches, and I would prefer not to delete them when I don't need them anymore. I would love to have a branch annotate feature, to write a small text associated with which branch: why it was created, what was it trying to achieve. I should be able to hide those branches, not delete them. This could be done at hosting sites like GitHub though, with a motto: GutHub, where your old branches go to sleep.
Bottom line is: tools don't make decisions for a programmer. They don't turn a project in a community success or failure. They only make the process harder or easier. Code sharing, open-source collaboration, it will always be a people-problem, requiring social skills.
Update: fixed links, thanks Nuno.
