Git Isn’t Social
I enjoy using Git for my personal projects. I’ve always been a big fan of handling changes and exploring implementation ideas in branches rather than a project’s trunk, so Git fits my personal development workflow nicely. That said, for team projects I would choose Subversion over Git in a heartbeat. Every time.
I continue to be astounded that the community believes Git to be more social than centralized VCS like Subversion. I guess the notion is that Git makes the following scenario reasonable:
Persons A, B, and C are all working on a project. Person A is the project owner and controls the official source code repository. Persons B and C are working on changes that are of interest to each other. With Git, Persons B and C can exchange updates easily without Person A’s knowledge or permission.
This is valuable in OSS development where a central official project leads to multiple, “flavored” products. RedHat and Novel each provide their own product based on the Linux kernel. IONA provides its own product derived from Apache projects for EAI/SOA. Relating this to my example above, we would expect that Persons B and C may each be releasing their own products based on Person A’s project. There exists a many-to-one relationship between products and projects.
However, most projects do not follow this pattern. Most projects—especially outside of OSS—produce a single, official product. In this scenario, Persons A, B, and C are all on a team working on the same product. Now the communication between Persons B and C no longer looks like positive community collaboration—it looks like coding in isolation. Perhaps B and C work a different office (or different time zone) than A or maybe B and C simply don’t like working with A. In any case, they aren’t collaborating with a team member on a team project. Coding in isolation and the consequent big bang integration is a long-standing and obvious software development anti-pattern. And Git encourages it.
Ben Collins-Sussman discusses this aspect of DVCS in depth several times. I should note that I acknowledge the problem I highlight as fundamentally a social problem, not a technical one, but I agree with Ben’s assessment that “even though one shouldn’t depend on technical solutions to social problems, default tool behaviors matter a lot”.
Since you linked to me, I feel the need to correct. What I said was:
“With Git, Persons A, B and C can exchange updates easily without Person A being a bottleneck”
In Apache, and many other open source projects, only a few people (A in this case) have write access to the main repository, making them a bottleneck to collaboration. No collaboration happens when A is on vacation, or just busy with other things. DVCS fixes that.
And this “off the main repository” collaboration is also great when person A is involved, because it allows other people to incrementally build new code, in public view, without having to wait on A to make the commit happens. As person A on a couple of projects, this makes my life easier.
Ironically, the people I know who like to work in the dark and make big code drops couldn’t care less for Git. They think of source control as a necessary evil, and even SVN is too much for them to learn and use.
In projects I work on, I don’t accept big code drops. I don’t care how they got there, and if necessary I just remove them.
Thankfully both SVN and Git allow you to reverse merge a commit out of trunk/head with a single command. End of story.
Doomsday scenarios are a dime a dozen, but if you manage a project for and by the community, they just don’t happen.
Assaf
July 6, 2008 at 12:46 am
Assaf,
Thank you for taking the time to read my article and share your thoughts. Since I have your ear for moment, I’d like to take the opportunity to tell you that I really enjoy reading your blog.
When I wrote my article, I chose to counter-point the notion that “Git is social” by pointing out that Git is just as easily anti-social. Rereading your post and your comments, I recognize now that my problem with the sentiment that “Git is more social” is that no version control system is inherently social or anti-social—it is the team or community around the project that enables social or anti-social developer behavior.
It was not my intent to present a hypothetical doomsday scenario. My concerns are based on my observations of attitudes among the younger developers with whom I’ve been interacting recently. (Wow. Now I feel old.)
Regards,
David
dlkinney
July 6, 2008 at 11:47 am
Thanks for the links to my blog posts. I think your post here does a much better job of explaining the nagging worry sitting at the back of my brain. :-)
Ben Collins-Sussman
July 6, 2008 at 10:58 pm
Thanks. And I just subscribed to yours, like what I’m reading so far.
I actually think it’s fair to judge software by whether or not its social. How it’s designed affects how we use it, we do gravitate towards that which is easy and rewarding.
In fact, that’s precisely why I’m trying to get people to move towards Git. In an open source project I can’t mandate a corporate policy on the community (or have any desire to do so), I can only recommend tools which I think will drive people towards more social behavior.
I’m picking Git for the same reason we use email and issue tracking and wikis and blogs, all of which allow and reward individual expression.
When you let people do whatever, they tend to organize around social circles and form communities. It’s human nature.
Communities create structure. I think Apache got it wrong, they start with structure. Before you get a Web page setup for your project that people can visit, you first have to elect leaders and write-access bureaucrats.
You set up bottlenecks and roadblocks before you open up the doors. That mentality of structure-first fits well with SVN. But to paraphrase Bruce Schneier, it’s social theater.
Git is a do-whatever-you-like and everybody can fork because forking is easy. But like I said, people are social animals and they gravitate towards communities. Git lets people choose to be there, not fenced off by write-access bureaucrats. And without barriers it does force you to pay more attention to the community and act more socially responsible.
I think SourceForge, which is all about the project, typifies CVS/SVN very well, while Github which is all about the people, is more a sign of what Git stands for.
We can worry that, when everybody gets to claim their own individual space, can be self-sustained and don’t have to go through gatekeepers, we’ll end up with isolationists and fragmentation.
Some mainstream media people still think that about bloggers.
Assaf
July 8, 2008 at 7:04 pm