I see little evidence here that Collins-Sussman has finally understood DVCS as a social entity, although he certainly seems to have the technical details down. The strongest argument for DVCS--any DVCS--that I have found is the periodic fights over "committer access" or project direction generally for projects like NetBSD, XEmacs, gcc/EGCS, or glibc/eglibc disappear.

I've seen more times than I can conveniently remember a perception of a cabal of committers who communicate exclusively with each other. This looks a lot like the structure of some sort of conspiracy, even though that is rarely the purpose. Even when it is, it's usually trying to work around some productive but extremely difficult person like Ulrich Drepper or Theo de Raadt.

DVCSes have the critically important property that there is no longer any inherent technical center of development but that the social center of development is retained (usually). So while there is a technical hierarchy of git repositories that goes to Linus, if you think he's an idiot and want to take it a different direction, it's easy to do that--and if he decides you have a good idea in the end, he can merge with you without huge amounts of effort.

Collins-Sussman has been concerned, publically, that there's some splintering process that DVCSes enable and that SVN prevents. But this perception is one you can only arrive at if you are in control of the SVN repository--if you are trying to submit patches to somebody doing this, and you don't have write access on the SVN server for branches or whatever (which imposes a nontrivial amount of effort), you more or less have to do this splintering on your own, without any tool support. In my experience DVCSes don't make this any more common than it was once; it's just that now these private splinters are visible, and can be integrated.

Another secondary thing that's very convenient for me is that I can make many small changes and push them all at once when I'm happy with them--because they're small they're easier to review. But this is a workflow issue, it's not that one couldn't do this with SVN.

This is a really good point. It allows the social structure of the project to grow and change in a very natural way which makes it not only easier to adapt as committers come and go, but effortless.

With central control of a repository, you can have what amounts to an "irrigation rights empire" -- a totalitarian regime (perhaps with some democratic window dressing) based on one party's control over some sort of infrastructure.

This is part of the problem with DVCSes - you do your work off in a cave, and then when it's "perfect" you submit it for inclusion.

Note that SVN doesn't lack this problem - it can even make it worse. It's just far more common in my experience for people to do work in a cave somewhere with a DVCS and then throw it all over the wall in a huge hunk than with SVN, because it's so easy to maintain that fork off in neverland.

After all, just look at the comments (on this article no less!) about how "once I clean X up, I'll put it on {github,bitbucket,google code}." That's the kind of attitude that means it'll almost never (statistically) be seen by anyone other than the original author (which is likely true anyway, only one of my projects has ever really attracted anything resembling attention).

Note that Ben isn't convinced that this risk of DVCSes outweighs their (admittedly large) benefits. It merely aggravates a very serious problem to a point where it becomes a complete nightmare.

I especially disliked the moment when they interrupted the criticizer who was talking that there are a lot of evidences of geniuses existence and highly productive programmers in particular.

And rather than advising to learn from the best programmers, they are advising to learn from ephemeral "community" and trimming ones ego and ambitions.

I don't like the "there are no geniuses" phrase, especially since they then have to back down and say, "Well, it isn't that there are no geniuses -- just that they're extremely rare," which just obscures the point further. The point I think they're trying to make, though, is that the myth of the hero programmer who writes a perfect program and releases it to a world full of unhelpful clods is counterproductive.

If you want to dispute their point, then answer their question: What successful, widely-used project was created entirely by one lone genius?

Thats all the talk is about. And the only reason anyone is arguing with it is the very insecurity the talk seeks to address.

Have you ever seen Linus on usenet? I'd argue that his Real Programmer protective stance towards Linux was more helpful to it taking off than being a really Nice Guy.

> Have you ever seen Linus on usenet?

"Not a total dick" in Internet terms is something like "A little to the left of Mao." However, Linus is also very astute and capable. People will tolerate "does not suffer fools gladly" if they are not a fool, or if they like the person's work.

Every programmer with an ego should ask themselves, "Am I an unjustified asshole?" Consider:

    - Do a lot of people mostly like your work?
    - Does the cost/benefit of alienating people vs. 
      shutting down the fools generally work out positively?
      (For the community not just for your personal 
      gratification.)
    - Do people complain about you profusely, but for 
      some reason still grudgingly respect you?

Are you a delusional asshole?

    - Do only a select few understand your work, and do you
      think even they are all inferiors?
    - Are you *always* right?
    - Do the people who are trying to do something valuable 
      generally try to ignore you?  

This position is a little oxymoronic since anything successful and widely-used must benefit from the non-zero amount of direct and indirect community feedback. Every project exists in relation to others and if one is superior in some way it's often because the creator decided to improve on something they liked or disliked in another system.

Napster was a bad implementation at the right time.

RoR - credit should be given. Sometimes just getting off your duff and starting something is what the world needs. Motivating many others to refine code into something useful deserves credit.

(EDIT: I am not saying anything was/wasn't a work of genius. I'm just saying it's truly creditable, whatever it was.)

I definitely agree with you on Napster. I am less sure about RoR. It was a a very nice improvement over existing systems, but how much of that was DHH genius and how much was simply due to Ruby providing a better platform upon which to build this particular framework I do not know. It was definitely better than existing alternatives in other scripting languages, but I was not a part of the Ruby world at the time and have no idea where the initial RoR work fit in to the whole Ruby ecosystem at the time.

Why do some people/code get attention and accolades, while others, equally deserving, do not? Timing? Personality? Bluster?

Nitro, another MVC-ish Ruby Web framework released at the same time as Rails, always stuck me as being a much better approach to the same problem, and better engineered (thread safe, less "magic" and munging of core Ruby classes, a form of pipeline transformations somewhat similar to Rack middleware today), but for whatever reasons Rails managed to capture far more attention.

The big win for Rails was not the initial code itself, but in capturing attention and motivating people to contribute, to fix it up, and make it better.

Yup. They wrote Subversion and continue to encourage people to use it.

Perhaps they should tone down their egos and realize that Subversion was not really that great of an idea, and there are now several competing tools that do everything Subversion does, but better.

Subversion is much simpler for people to "get" than other systems. I've been a heavy evangelist of DVCS tools and workflows for a while at work, and it's taken since October (8 months) to get any critical mass behind actually even investigating switching to those from SVN.

Let's face it: Subversion is many many times better than nothing, which is what a ton of people do. Most college graduates in CS or CSE come out of school never having touched version control in my experience, and the ones that have seen it were exposed via open source, not their coursework. Evangelizing Subversion is (really lousy analogy warning!) like convincing people to smoke cigarettes instead of doing illegal drugs. At least it's less bad for them, and the barrier to entry might be a bit lower. When we had a poll of the local Python users group one meeting, "email" was the most popular version control solution, followed by a basic dead heat between svn/bzr/git/hg. The fact that people still view email as a valid answer is far more troubling to me than evangelizing an old and very mature tool instead of one of the new upstarts.

I am glad that CVS died, but it was "replaced" with something not-much-better.

Berkeley DB was certainly old when it was adopted by the SVN project. It's not like the NFS issues with BDB were unknown.

That's why I am suspicious anyone who ever worked for Microsoft, specially when you talk about open-source. You never know when they will send a saboteur.

"The Linux kernel source code used to be maintained without the help of an automated source code management system, mostly because of Linus Torvalds' dislike of centralized SCM systems.

In 2002, Linux kernel development switched to BitKeeper, a SCM system which satisfied Linus Torvalds' technical requirements."

Nearly a decade without a revision control system?

http://en.wikipedia.org/wiki/Linux_kernel#Revision_control

I get where they're coming from. I have several projects that I really need to polish up and upload, and I want them to feel presentable; I don't really understand how people get used to working in public (on github, for example). I also do a fair amount of maintenance programming, and ... I want to make sure my code is better than that. Just because I change my mind, make mistakes, etc., it doesn't mean I need to publish sloppy code.

* Look at the comments in any discussion on Reddit. About anything. People get nasty, often just because they can.

I think one of the key lessons for me, which is very easy to grasp intellectually but much harder to internalize, is that any nastiness you receive in the short term doesn't really matter (and often comes from people who don't really matter). If you succeed in the long-term, that's what you will be known for, and all of the scorn directed at your early works will seem irrelevant. You should therefore do whatever maximizes your chances at long-term success, which includes taking the risk of exposing yourself to humiliation so that you can get better faster.

It's one of the things I really admire about, say, Jeff Atwood. He's consistently bashed here and elsewhere for being incompetent, and it's not undeserved: even though I consider myself a pretty poor programmer at the moment, I can often tell when he says things that are fallacious or ignorant. And yet, with Stack Overflow he has been involved in a project more successful than most people's projects here. I would never mistake him for the mythical genius programmer, and I may be puzzled at the attention he receives or his persistence about writing topics he doesn't know much about, but when I see how he keeps writing and keeps building useful things even when everyone is publicly explaining to him all the ways he sucks, I wish I had his cojones.

It's easy. Until your code is good, no one gives a damn about it. Even if it's good, you'll still have to shove it down people's throats before they care. So don't worry that "someone might see your bad code". They won't. Nobody cares.

So make it public.

With this attitude* , only criticism about how the code is serving its purpose is relevant. If someone criticizes it (or I imagine they will) because it's Lisp (or because isn't), or because it uses design patterns (or because it doesn't) and the criticism doesn't seem to make a difference to its purpose - it's just kind of bemusing.

* Hard to do.

EDIT ah... having now read the slides, this is one of the things they're saying.

I find it an interesting point of view, since I'm a total noob when it comes to programming - first year CS student, only done a few tiny VB projects before that. However, I really enjoy programming, work on a few projects in my spare time, and plan to get some decent languages (a scripting language (Perl/Python/Ruby), and maybe a functional language (Clojure?) under my belt soon. I've used OO in class projects, but I want to figure out how to use it in my own projects. I want to learn software engineering practices. I want to learn graphics programming. That's just over the next couple of years! In 10, 20 years time, who knows?

The appeal to me is that I can never peak in programming, their will always be new stuff to learn. Anyway, where was I? Oh yeah, my point was that I'm a noob now, I'm very willing to be modest and learn from others, but the hope of becoming a genius programmer I find very motivating.