Version Control and “the 80%”
11/17/07: Before posting an angry comment about this post, please see the follow-up post!
Disclaimer: I’m going to make some crazy sweeping generalizations — ones which are based on my 12 years of observing the software development industry. I’m aware that I’m drawing some oversimplified stereotypes, but I think most of my peers who work in this industry will nod their head at some point, able to see the grains of truth in my characterizations.
Two Types of Programmers
There are two “classes” of programmers in the world of software development: I’m going to call them the 20% and the 80%.
The 20% folks are what many would call “alpha” programmers — the leaders, trailblazers, trendsetters, the kind of folks that places like Google and Fog Creek software are obsessed with hiring. These folks were the first ones to install Linux at home in the 90’s; the people who write lisp compilers and learn Haskell on weekends “just for fun”; they actively participate in open source projects; they’re always aware of the latest, coolest new trends in programming and tools.
The 80% folks make up the bulk of the software development industry. They’re not stupid; they’re merely vocational. They went to school, learned just enough Java/C#/C++, then got a job writing internal apps for banks, governments, travel firms, law firms, etc. The world usually never sees their software. They use whatever tools Microsoft hands down to them — usally VS.NET if they’re doing C++, or maybe a GUI IDE like Eclipse or IntelliJ for Java development. They’ve never used Linux, and aren’t very interested in it anyway. Many have never even used version control. If they have, it’s only whatever tool shipped in the Microsoft box (like SourceSafe), or some ancient thing handed down to them. They know exactly enough to get their job done, then go home on the weekend and forget about computers.
Shocking statement #1: Most of the software industry is made up of 80% programmers. Yes, most of the world is small Windows development shops, or small firms hiring internal programmers. Most companies have a few 20% folks, and they’re usually the ones lobbying against pointy-haired bosses to change policies, or upgrade tools, or to use a sane version-control system.
Shocking statement #2: Most alpha-geeks forget about shocking statement #1. People who work on open source software, participate in passionate cryptography arguments on Slashdot, and download the latest GIT releases are extremely likely to lose sight of the fact that “the 80%” exists at all. They get all excited about the latest Linux distro or AJAX toolkit or distributed SCM system, spend all weekend on it, blog about it… and then are confounded about why they can’t get their office to start using it.
I will be the first to admit that I completely lost sight of the 80% as well. When I was first hired by Collabnet to “design a replacement for CVS” back in 2000, my two collaborators and I were really excited. All the 20% folks were using CVS, especially for open source projects. We viewed this as an opportunity to win the hearts and minds of the open source world, and to especially attract the attention of all those alpha-geeks. But things turned out differently. When we finally released Subversion 1.0 in early 2004, guess what happened? Did we have flocks of 20% people converting open source projects to Subversion? No, actually, just a few small projects did that. Instead, we were overwhelmed with dozens of small companies tossing out Microsoft SourceSafe, and hundreds of 80% people flocking to our user lists for tech support.
Today, Subversion has now gone from “cool subversive product” to “the default safe choice” for both 80% and 20% audiences. The 80% companies who were once using crappy version control (or no version control at all) are now blogging to one another — web developers giving “hot tips” to each other about using version control (and Subversion in particular) to manage their web sites at their small web-development shops. What was once new and hot to 20% people has finally trickled down to everyday-tool status among the 80%.
The great irony here (as Karl Fogel points out in one of his recent OSCON slides) is that Subversion was originally intended to subvert the open source world. It’s done that to a reasonable degree, but it’s proven far more subversive in the corporate world!
Enter Distributed Version Control
In 2007, Distributed Version Control Systems (DVCS) are all the range among the alpha-geeks. They’re thrilled with tools like git, mercurial, bazaar-ng, darcs, monotone… and they view Subversion as a dinosaur. Bleeding-edge open source projects are switching to DVCS. Many of these early adopters come off as either incredibly pretentious and self-righteous (like Linus Torvalds!), or are just obnoxious fanboys who love DVCS because it’s new and shiny.
And what’s not to love about DVCS? It is really cool. It liberates users, empowers them to work in disconnected situations, makes branching and merging into trivial operations.
Shocking statement #3: No matter how cool DVCS is, anyone who tells you that DVCS is perfect for everyone is completely out of touch with reality.
Why? Because (1) DVCS has tradeoffs that are not appropriate for all teams, and (2) DVCS completely blows over the head of the 80%.
Let’s talk about tradeoffs first. While DVCS dramatically lowers the bar for participation in a project (just clone the repository and start making local commits!), it also encourages anti-social behavior. I already wrote a long essay about this (see The Risks of Distributed Version Control). In a nutshell: with a centralized system, people are forced to collaborate and review each other’s work; in a decentralized system, the default behavior is for each developer to privately fork the project. They have to put in some extra effort to share code and organize themselves into some sort of collaborative structure. Yes, I’m aware that a DVCS is able to emulate a centralized system; but defaults matter. The default action is to fork, not to collaborate! This encourages people to crawl into caves and write huge new features, then “dump” these code-bombs on their peers, at which point the code is unreviewable. Yes, best practices are possible with DVCS, but they’re not encouraged. It makes me nervous about the future of open source development. (Maybe the great liberation is worth it; time will tell.)
Second, how about all those 80% folks working in small Windows development shops? How would we go about deploying DVCS to them?
- Most DVCS systems don’t run on Windows at all.
- Most DVCS have no shell or GUI tool integrations; they’re command-line only.
- Most 80% coders find TortoiseSVN full of new, challenging concepts like “update” and “commit”. They often struggle to use version control at all; are you now going to teach them the difference between “pull” and “update”, between “commit” and “push”? Look me in the eyes and say that with a straight face.
- Corporations are inherently centralized entities. Not only is their power-structure centralized, but their shared resources are centralized as well.
- Managers don’t want 20 different private forks of a codebase; they want one codebase that they can monitor all activity on.
- Cloning a repository is bad for corporate security. Most corporations have an absolute need for access control on their code; sensitive intellectual property in specific parts of the repository is only readable/writeable by certain teams. No DVCS is able to provide fine-grained access control; the entire code history is sitting on local disk.
- Cloning is often unscalable for corporations. Many companies have huge codebases — repositories which are dozens or even hundreds of gigabytes in size. When a new developer starts out, it’s simply a waste of time (and disk space) to clone a repository that big.
Again, I repeat the irony: Subversion was designed for open source geeks, but the reality is that it’s become much more of a “home run”for corporate development. Subversion is centralized. Subversion runs on Windows, both client and server. Subversion has fine-grained access control. It has an absolutely killer GUI (TortoiseSVN) that makes version control accessible to people who barely know what it is. It integrates with all the GUI IDEs like VS.NET and Eclipse. In short, it’s an absolute perfect fit for the 80%, and it’s why Collabnet is doing so well in supporting this audience.
DVCS and Subversion’s Future
Most Subversion developers are well aware of the cool new ground being broken by DVCS, and there’s already a lot of discussion out there to “evolve” Subversion 2.0 in those directions. However, as Karl Fogel pointed out in a long email, the challenge before us is to keep Subversion simple, while still co-opting many of the features of DVCS. We will not forget about the 80%!
Subversion 1.5 is getting very close to a release candidate, and this fixes the long-standing DVCS criticism that “Subversion merging is awful”. Branching is still a constant-time operation, but you can now repeatedly merge one branch to another without searching history for the exact arguments you need. Subversion automatically keeps track of which changes you’ve merged already, and which still need merging. We even allow cherry-picking of changes. We’ve also got nice interactive conflict resolution now, so you can plug in your favorite Mercurial
merging tool and away you go. A portable patch format is also coming soon.
For Subversion 2.0, a few of us are imagining a centralized system, but with certain decentralized features. We’d like to allow working copies to store “offline commits” and manage “local branches”, which can then be pushed to the central repository when you’re online again. Our prime directive is to keep the UI simple, and avoid the curse of DVCS UI (which often have 40, 50, or even 100 different commands!)
We also plan to centralize our working copy metadata into one place, which will make many client operations much faster. We may also end up stealing Mercurial’s “revlog” repository format as a replacement for the severely I/O bottlenecked FSFS format.
A Last Plea
Allow me to make a plea to all the DVCS fanatics out there: yes, it’s awesome, but please have some perspective! Understand that all tools have tradeoffs and that different teams have different needs. There is no magic bullet for version control. Anyone who argues that DVCS is “the bullet” is either selling you something or utterly forgetting about the 80%. They need to pull their head out of Slashdot and pay attention to the rest of the industry.
Update, 10/18/07: A number of comments indicate that my post should have been clearer in some ways. It was never my intent to say that “Subversion is good enough for everyone” or that “most of the world is too dumb to use DVCS, so don’t use it.” Instead, I’m simply presenting a checklist — a list of obstacles that DVCS needs to overcome in order to be accepted into mainstream corporate software development. I have no doubt that DVCS systems will get there someday, and that will be a great thing. And I’m imploring DVCS evangelists to be aware of these issues, rather than running around thoughtlessly trashing centralized systems. 🙂
One other 80/20 thing: open source projects tend to have a much higher proportion of “20%ers” than companies do. The reason should be obvious, or rather the many reasons:
– OSS communities reward merit, value of contribution, excellence — you know, the 20% stuff
– 80%ers tend not to view programming as entertainment, 20%ers do, and many work on OSS because they’re not getting enough entertainment in their day jobs
– 80%ers have a life, and, well … 😉
OSS communities are largely voluntary associations. The rewards appeal to the 20%, not to the 80%. So, OSS communities actively self-select for the 20s.
Which helps to explain why so many OSS projects are “80%er-hostile.”
Very good and insightful read – and I totally agree with you.
Borek
Brilliant as usual
Great article! Lots of good points.
I’m currently using bazaar here and there at work (locally on my PC, not officially). I have been known to mildly advocate DVCSes to my coworkers (just explaining what it is and some advantages, mainly). I have to admit that you’re right: I often get “what do I care?” looks 🙂
Hearing what’s in store for SVN, I can’t wait to see the next versions. You’re right in saying that it’s much easier to grasp for the 80% programmers, which is a great thing. I like the fact that some of the things I love about DVCSes are going to make it in SVN 🙂
In your article you mention tools having hundreds of commands. You obviously given Git a try 🙂 It also scared me away for that reason. However I strongly suggest you give a quick look at either Mercurial or Bazaar. I’ve used them both and the amount of commands for each fits on one page. They’re a breeze to use, altough yes, they are command-line for now. Although I’m aware that there is a TortoiseBzr in the works (or maybe even available, I haven’t tried it yet).
http://bazaar-vcs.org/TortoiseBzr
Oh, Mercurial and Bzr work like charms on Windows.
I thought your language was a little confusing — you seemed to be were talking about DVCSes in general (and conceptually), but many of your criticism were in fact of the current spread of DVCS technologies and systems that exist today.
Your points largely spot on, though. I do think that it’s not totally a fair comparison though — AFAIK none of the DVCS tools out there are even 1.0, and many are changing very rapidly.
I do object to one specific point though: “With a centralized system, people are forced to collaborate and review each other’s work”. No they’re not. People just check in and ignore everyone else anyway. This happens /all the time/, at least on our project, maybe we just suck (you know Augie, right? Ask him about Evan). A centralized system simply forces you to share your changes if you want to version them. You shouldn’t have to make that tradeoff.
To end on a positive note, my biggest headache right now with svn is how fuzzy the concept of “branch” is. I was just thinking how much I really wish you guys had a DAG, and then you mention adopting RevlogNG! That’d be awesome.
Hi Webmat,
The ‘hundreds of commands’ reference was actually a reference to Bitkeeper, though I heard that that Git has similar problems. 🙂
I’m already a mercurial user, and I like it a lot — very usable.
Replying to Colin:
I’m aware that I’m criticizing DVCSes which are (barely) 1.0 technologies. I have no doubt that they’ll get better over time, and that many of my criticisms will be fixed. On the other hand, I’m mainly responding the fanatical evangelists of DVCS; I’m trying to get them to be aware of these current flaws, and why DVCS is still mostly inaccessible to “the 80%”.
If you have people using a centralized repository that are blindly clobbering other people’s changes… then you have a serious social problem. 🙂 The fact that it’s centralized just makes you more acutely aware of the problem, since a few people tend to spoil the public well for everyone, rather than spoiling their own private well.
Not sure I understand your “branch” complaint… the subversion filesystem *is* DAG, in fact. That’s why copying a directory (making a tag or branch) is a constant-time operation: it’s just making a new hard-link to an existing inode in the DAG. There’s a whole layer in the repository that covers up the DAG, trying to make it look like a normal filesystem.
Responding to fanatics and such legitimizes them. Don’t let them get under your skin, or address any logical flaws in their arguments calmly. I feel your pain though (“Firefox will never look good on the Mac because it is cross platform”).
You know Augie Fackler, right? Ask him about Adium. He’ll tell you all about build breakages and stuff (people are better, but yeah…)
The problems, at least for me are (and you can see all these in the Adium repository):
– People committing to multiple branches in the same commit
– Multiple hierarchies in branches/ (ex: branches/summer_of_code_2006/student_name/)
– Copies of things other than trunk/ in branches/ (ex: branches/ChangeLog/changelog.txt)
All of this makes automated tools for looking at history go absolutely crazy. It’d be nice to enforce some invariants there :\ Again, social problems, but as you said, defaults matter.
The concept of a versioned file system is cool and all, but lets enforce some invariants here, or something…
s/skin, or/skin, and/
Great article. I recently wrote about regular VCS and DVCS systems, aimed at newbies (of which I am for DVCS). In my view, *any* VCS is a good VCS given that most people in the 80% aren’t using anything. I found the arrogant “DVCS are better, fool!” quite off-putting as well.
Keep up the good fight — introducing people to new tools is a crawl/walk/run process 🙂
Good walk through, from long time, I wanted it to say same thing to fanatics who are so obssessed with them selves that they are not even bother about others.
I fully agree with you that DVCS might be good for some project but not all, this fact has to be realized, as I use subversion I know what it is capable of and its not as bad as it was qoted by some fanatic freaks.
I gotta admit, I am in the 80% and totally agree with Shocking statement #2. I know Microsoft and nothing else — its been that way for 15 years. That goes for VSS. I just started a freelance ASP.NET gig and my DBA buddy wanted to use Suberversion. I said no f-ing way. I had to admit, I never heard of it.
But why bother? I been using version control since PVCS. And VSS is the defacto standard among the enterprisy 80%. It even shows up on job reqs.
There is no silver, no cool tool to handle a large project with a lot of developers checking stuff in. IMHO, merging and branching doesn’t work well, and exclusive checkouts are the way to go. That means you need good team leads and configuration managers to sort out the bs. Code reviews, continious integration, and discipline are what it takes.
But if it has a VisualStudio plug-in, maybe even I’ll try it. But you can have all that LAMP, Ruby, Lisp stuff — I have bills to pay.
Interesting take on the adoption of version control and an excellent summary of why large corporations will be slow to adopt DCVS, but I’m a little put off.
I am shocked by shocking statement #1. Am I that naive, or is 80% of our industry really as characterized? Just because they’re vocational (I’m willing to accept this part of the premise) doesn’t mean that they’re bad at their job — version control and a working Linux abilities are vital tools for a programmer.
And why lump Eclipse in the “bad / clueless practice” category? I run eclipse — on Linux — and am continually amazed at how much it aids my development. It’s got built-in refactoring tools, great debugging (including remote jvms), and it dramatically automates much of the boilerplate java forces you to write. If you are developing Java, you have either a) Eclipse or another IDE with the features named, b) deep, deep black magic macro skills with your text editor, or c) something wrong with you.
Yes, I’m relatively new to the field. Maybe if I had an additional decade of experience under my belt I would agree with the 80% summary, but there is no way on earth 80% of the developers where I work are so ignorant of best practice. Seeing the agreement in the comments above, I’m forced to conclude that the hiring bar is a lot higher than average where I work, because if you don’t know how to use version control and dig through a directory on Linux with your shell, you are not getting hired.
Thanks again for the interesting article.
zach
Dangit, just read the comment above mine.
Very saddened,
zach
After thinking about this for a while, I think there’s a confusion between technology and policy here. The confusion exists on both sides of the fence. Distributed version control systems are a somewhat different technology; but it’s by no means true that they require different policy.
I’d be willing to bet that among corporate software development using version control systems, there still exists one central repository that everyone thinks of as “the” code base. Certainly there is one where I work now. Similarly, I can think of no place I’ve ever worked with a traditional version control system where developers didn’t keep a working copy of the entire code base on their systems, and sync it up with the repository on occasion.
There’s a good point here. This kind of organization exists for a reason, and it’s not just because everyone has adapted to the limitations of technology. Anyone preaching the gospel that we should no longer have a centralized code base is going to hit a wall. This is all too common among the DVCS community.
Similarly, though, it’s incorrect to argue that distributed systems are not workable just because they aren’t tied to that policy decision. What needs to be said is that it’s entirely possible to reproduce that same policy decision while using darcs, for example, and everything still works fine. Sure, darcs doesn’t require that decision, but neither does darcs preclude it.
Eventually, what I’m sure will happen is that businesses will cautiously pursue incremental changes to their policy decisions. Eventually, they’ll arrive at a sort of hierarchical arrangement of code repositories for large projects, which will fit the organization’s structure a little better than current centralized systems do. It remains true that a necessary component for this migration is that they adopt “distributed” systems (perhaps after the movement changes its name), because the change relies on the simple fact that using an organization-neutral VCS makes it easier to tweak the organization. One doesn’t have to wait for the software to catch up.
While it’s fun to play with new technologies, version control seems like one of those things you’d want to make sure was really well dogfooded (and that your data was consistently backed up / secure).
One recent blog post about a startup said that they started out using git, without a central server, and started sharing the repo between two client machines. I’m sure 99.9% of the time this is perfectly alright, but for my paranoid self I prefer —
central repository on a server that’s backed up regularly
at least 2 checked out copies on different machines (at least one of which is not a laptop)
But maybe I’m just being paranoid, or not fully understanding git / DVCS.
Unfortunately I am part of third category of programmers, and now I can’t clasify myself, because there is no percentage left for me in your description. Looks like I don’t even exist.
The biggest problem in Subversion I encounter roughly weekly with the 80% crowd, is the fact that version control information is stored separately for each directory. They keep renaming (or more often, deleting) the directories and they get themselves into a mess. Git is better here because it has one directory for meta data.
git is a non-starter for them due to a complicated mental model
(index, git-commit -a, and related). Merging/distributed is not a problem since most will not use any different than subversion (update/push)
Mercurial sems nice, but seems less robust in behavior than svn.
I admit the 80% does exist – and they are not all programmers. I develop Flex and many of our assets are images, animations, movies and sounds. Plus XML configuration files. I’d love artists to use VCS but they have real trouble using SVN.
Most of the complaints I saw in the Linus git video are around merging. He’s probably never used Perforce WinGui but that is sweet (note SVN devs: If you can match Perforce’s safe merge and auto-merge behaviours your most of the way there … in fact just become an open source Perforce clone, it is really the best). Really – auto merging files with no warning is brain-dead behaviour. Notify the user a merge is pending and allow them to sort it out at their leisure.
I guess I’m in the 20% since yesterday I installed Mercurial and set up a test repository to give it a go. The merging seems similar to Perforce (warns before merge – auto merges – conflicts raised into graphic 3-pane merge app).
Your claims are both founded and unfounded. I could put together a hierarchical process using DVCS where programmers push to leads, leads push to higher leads and so forth until it hits testing/release/etc. Breaking code into modules keeps confidential stuff confidential (e.g. check-out pre-built confidential modules and source section modules). In fact, I like the idea of not having to download large 3d source files and just having a pre-built place to pull from. Leads become responsible for aggregating and reviewing. It creates a responsibility chain that a central system does not have. Code escalation.
Good comments though – SVN is the best popular free choice 😉
I totally agree about the 80/20 divide. But unfortunately the 80% guys will never read this post of yours, because the programming blogosphere is written and read only by the 20%, 😉
zach, you say “version control and a working Linux abilities are vital tools for a programmer”.
While I would tend to agree (I couldn’t develop without version control and a powerful OS at hand), most of the IT industry would have been decimated for a long time if that was even remotely true.
Most programmers probably don’t even understand the very basic notions of version control, not to speak about branching and merging, never learned regular expressions and a devent scripting language.
They (sometimes) store regular snapshots of their code on CDs, search/replace is the most complex tool they’ll ever use when it comes to automatic code change and do a lot of basic file manipulatins by hand.
Hmm. The thing that pushed me to look at git in the first place was using Subversion for a few months and seeing how unpleasant it is. The whole ‘svn copy’/trunk/tags/branches thing is hard to use and hard to understand. For the unwashed 80%, I like RCS–it’s quite simple and handles the simple cases, which, as you say, are all that the 80% really need anyway.
What f..ing planet do you come from?
“In a nutshell: with a centralized system, people are forced to collaborate and review each other’s work;…”
I have been in the IT industry for years and have _NEVER_ had a meaningful code review. Vey very rarely are people working on the kinds of projects where they need to collaborate to any great extent. A lot of businesses have a buy instead of build software mentality.
This does remind me. I was working on a very large project to redo a order entry system. If the code I had written was wrong the company would not be able to ship product. When having a casual BS session with the manager of the project I mentioned that I though code reviews were a great idea and that are company should do them. I also mentioned that I had been at the company for 3 or 4 years and we had basically never done them. Guess what? I was the first person on the project to get a code review.
I was fairly nervous and all about it. They scheduled the meeting. I printed out the 60 or 70 pages of code. They arrived at the meeting about ten minutes late. They didn’t get much past the fifth or six page. Done. Good to go. This is code that _had_ to be correct or we didn’t ship computers out the door.
The place I am out now also has code reviews and we do them before we put anything into production. Guess what, I have never had to change anything as a result of the code review. As a matter of fact fairly often they are done by a person that may not even understand the technology I am working with.
“I just started a freelance ASP.NET gig and my DBA buddy wanted to use Suberversion. I said no f-ing way. I had to admit, I never heard of it.”
What Microsoft tools are you using for Continuous Integration?
Jay: my comment about “being forced to collaborate and review work” was specifically about the impact of centralized repositories on *open source* projects. That’s a completely different culture from corporate software development, where code reviews almost never, ever happen. (You’re totally right about that — I’ve been there.)
I’m sort of one foot in, one foot out of the 80%. I do the vast majority of my programming in a platform agnostic language (Javascript.) Previously I programmed my sever side stuff in PHP, I wanted to learned Ruby but in order for me to learn Ruby I need a project to do so that is relevant to me, not just some hello world app. I’m currently in a Gig that uses vb.net as the back end. I wanted so bad to use SVN starting my project because I recognise the benefits of using a versioning system, but I’ve never used it before and when I installed it I had NO EFFIN CLUE what anything really meant. I don’t have time to read through a cryptic manual meant for the 20%, I need a simple tutorial that spoon feeds me the basics in a clear and step-by-step manner. I simply don’t have time to tinker and learn by trial and error like I used to.
And like many things open source when you go to look for help you usually just find a hostile forum, or if you’re lucky an irc channel with nothing but idlers, but more likely a cob-webbed newsgroup (which usually precludes a great majority of the 80% ever even knowing it exists,) with nothing but a slew of unanswered questions by newbies like myself. Not exactly saying this is the case with SVN, but lets just say I’ve become disillusioned when it comes to looking for support on OSS projects. More OSS startups should model their support after Mozilla in my opinion, they have such an active support userbase on mozillazine, irc and newsgroups whatever your choice you’ll find a lot of mostly friendly people looking to help.
I would say it’s more like 5% – 20% – 75%. The band in the middle are more or less competent, and may or may not actually enjoy their work. Five percent are well above competent, they are on about excellence in one way or another. Easily seventy percent are below competent, and don’t understand why the rest get so enthusiastic, and resent being treated like inferiors.
This distribution is found in all professions and trades. Medicos, financial advisers, teachers, social workers, bureaucrats, law makers. Scary when you think about it.
I remember once saying to some co-workers, while enthusing about the latest developments in interpreted languages (Python, Perl, Java, etc.), “If you don’t love the stuff, what are you doing here?” Blank looks. Left me in no doubt I was surrounded by 80%-ers.
Great essay!
I was talking about it with jackr (see first comment) and others recently. One thing we thought was that the differences between today’s centralized and decentralized systems are divisible — that is, it’s more of a feature-by-feature difference than a monolithic “fully centralized” versus “fully distributed” difference. Everyone agrees Subversion should have local commits, and “foreign branching”, for example. It just might not get those features at the same time.
There are certain features that, today, tend to be present in the distributed systems but not in centralized ones (just as there are the reverse, e.g., locking & lock notifications). Some of those features come more naturally to the distributed systems, I won’t deny that (and again, the reverse is true as well), but the point is that it’s the features users use, not the single adjective used to describe the system as a whole.
’tis the ideas that count. Next generation of version control systems will have picked the best ideas from each of the current ones.
Great article! I’m not a programmer (though I am in the website development business) but we’ve got programmers here that I’ve never really looked at in this point of view. The agents here at Agents of Value are more or less part of the 80%, although I would like to think that there’s one or two who has the potential to be one of the 20%.
TunnelRat, you might be surprised. A few years ago, I was in a shop that used TortoiseCVS. It was easier than any other tool we had tried, because it plugged straight into the shell. We didn’t have to launch a separate client as with VSS or PVCS or Perforce. Our file icons in Explorer or any file dialog were shaded red or green for “modified” or “unmodified.” All of the developers on my team were able to pick it up like (*snaps fingers*) that.
And as others have mentioned, Subversion has pretty much the same level of friendliness if you install TortoiseSVN. (And on the DVCS front, Mercurial has the young but promising TortoiseHg.)
I have bills to pay, too, and that’s why I don’t put up with crap tools that impede my ability to pay said bills.
“In a nutshell: with a centralized system, people are forced to collaborate and review each other’s work;”
This is only true for the people having commit access to the central repository.
So usually people will send patches, often against the latest release instead of trunk/HEAD/tip/whatever. Other people (which are probably those half way between the 80% and the 20%) will send tar/zip archives which contain all their changes.
“in a decentralized system, the default behavior is for each developer to privately fork the project.”
In Free Software projects using centralized systems, the default behaviour (at least for all the 80% people and most of the 20%) is to not have commit access, so the default is what I described above. For Free Software projects using a DSCM, the same is true for the described 80%, because they don’t know how to handle the SCM, so these people still can send their zip archives. For the 20% the situation is to either share their patches as before, keep their changes private as before, or (new option!) to publish their repository, so other people can benefit from this.
So, yes, there will be more “forks” than before, but now you have a chance to reintegrate these forks (i.e. merge the branch) which would have been very tedious with a centralized SCM.
Don’t forget that you still have the 80%/20% divide at both Google and FogCreek.
Not that this was your main point, but even using these two companies in your throwaway example is to overlook a point. Google is so much larger a company than FogCreek, and the work that Google does is so much more diverse, that to draw equivalence between the two of them is to invite dismissal on the grounds of hyperbole.
offline commits and local branches…THANK YOU! i’m surprised more systems don’t allow this…
“640 K should be enough for everybody!”
And you want now us to think Subversion should be enough for everybody?
Maybe DVCS is not good enough for all, but only good for the top 20%. It doesn’t matter. Linux was once good only for the top 2%. NOw we have “consumer Linuxes”, and the same I do expect in a few years for DVCS, once all the top 20% simplify and iron every wrinkle on DVCS.
— Biil.
Awwww, come on!
DVCS is not going to change the landscape on how we design and code.
Object orientation is going to change the landscape: we will stop writing software, because software will be able to write itself.
You are missing the whole point!
We need no stinking ESBs and SOAs, the software in the future will read what we have written in the past, connect to it, and ask us what we want to do. Then simply perform.
Who needs coders in such an environment?
A number of comments indicate that my post should have been clearer in some ways. It was never my intent to say that “Subversion is good enough for everyone†or that “most of the world is too dumb to use DVCS, so don’t use it.†Instead, I’m simply presenting a checklist — a list of obstacles that DVCS needs to overcome in order to be accepted into mainstream corporate software development. I have no doubt that DVCS systems will get there someday, and that will be a great thing. And I’m imploring DVCS evangelists to be aware of these issues, rather than running around thoughtlessly trashing centralized systems. 🙂
I’m not so concerned about the 20% and the 80%. I’m more concerned about the .2%, the .8% and the 99%. As far as I can tell, 99% of the world doesn’t use anything at all: not a DVCS, not Subversion, not a commonly-visible directory that things are put in; not a series of releases by some maintainer; not patches; they email their latest version of the thing they’re working on to a list of the other people they’re working with, and hope that the next version anybody produces includes their changes. It’s like they’re using “rcs”, but doing it in their heads. That’s who I’d like to reach, in part because I sit near some of them, and I can hear them trying to find current versions of things and waiting for each other to finish working on documents, and I’m always cringing at the lost work and wasted effort.
I think it’s possible, and it’s got more of a DVCS feel to it, for me. The users understand the difference between “Save As…” (commit) and “Send” (push). They know about “Check Mail” (fetch). They do merge or fast-forward by hand. They’ve got no centralization, beyond the fact that, at the end of the process, some particular person is going to issue the press release.
That’s what I want to see somebody write; unfortunately, I don’t know how to use any of the software that these users know how to use, let alone how to write such software.
Strange, I guess that either means that Catalyst is full of 20% programmers, or we must have very good internal training.
Or, of course, this argument is apologist rubbish :-).
Admit it, you’re just clinging to your old ways in exactly the same way that you accuse people using DVCS clinging to theirs. Your argument falls apart #1.
Your argument falls apart #2, when you realise that DVCS can be configured to work just like Centralized systems, because it’s more like a constraint which is removed than a different constraint. So you can benefit from the same simplicity of operation if you choose, and then people who do not need this can work without the shackles if they choose.
Yes they are not yet as integrated into things like the Windows shell. However the GUIs have already far surpassed anything you will see in the Subversion space so this is becoming less and less important.
Errr…
> o Most DVCS systems don’t run on Windows at all.
Can you cite *one* DVCS that doesn’t run on Windows?
> o Most DVCS have no shell or GUI tool integrations; they’re command-line only.
Can you cite *one* DVCS that doesn’t have a GUI and that is command-line only?
I won’t argue about the “centralized systems encourrage review” Vs “decentralized systems encourrage bad practices”, other people did so already, and you probably know it’s wrong if you already looked at a few examples in real life.
Great post. I have had more than one battle trying to introduce people to version control. I have had the most success with Subversion largely because of granular permission control, the Subversive Eclipse plugin and TortoiseSVN… and it is my VCS of choice.
I can’t even begin to describe how much I agree with the whole reality thing. People really need to come back to Earth and get and keep a solid grip on reality. I love what I do, but most people simply don’t care. I always try to keep that in mind. Introducing new tools can be less painful if it is done at the right time and with a little bit of care and understanding.
It’s a little weird to me, and I think it mostly comes from being overly enthusiastic, that the top 20% can so easily loose touch with reality and fail to view things from other peoples perspectives. Our first thoughts should be about “how will others feel about this tool”… not… “I think it rocks so I am going to try and force it on everyone else by driving them nuts pushing it every chance I get”. If a person likes a tool use it for your personal projects, you can’t expect everyone else to want to use it the way you want to. Especially in the business world. Companies tend to have very strict requirements, they don’t care about the latest trend (things come and go all the time), they care about keeping their business running, keeping customers happy and keeping the money rolling in. And nevermind government agencies… I will not even go there, if you have worked with them then you know what I am getting at. Technologies are just tools, it’s not cool to them. They most often take the… if it ain’t broken, don’t fix it approach.
I am really glad to hear about the improvements you guys are working on for the upcoming releases of SVN. Can’t wait to use the new and improved features. Thanks! and… keep up the great work!
And even if it is broken they still don’t want to fix/improve it unless it is costing them money or lost revenue.
Thanks for the interesting story.