I just read Steve O’Grady’s 2010 post Fear of Forking and wanted to provide an update with the benefit of six years of hindsight.
Recap: The State of Version Control in 2010
Steve’s piece speaks of the “philosophical divide between those who abhor forking of code, and those who advocate it.”
2010 data from Ohloh (now Black Duck Open Hub) showed that 86% of repositories used centralized version control either via Subversion (SVN/Svnsync) or Concurrent Versioning Systems (CVS). Though there were caveats to how representative the Ohloh dataset was of the wider market, at the time centralized repositories still appeared to dominate the landscape.
Data source: Ohloh, November 2010 (see Fear of Forking for additional 2010 data)
However, Steve argued that the trend was moving strongly in favor of distributed version control (DVCS) despite the enterprise apprehension and initial discomfort around DVCS being “a fundamentally different way to develop software.”
Centralized version control is based on the fundamental concept that there is a single central version of the software, and all updates are committed to the central server. Decentralized software development works differently. Developers clone copies of entire repositories to work locally, and then merge their changes back. Steve describes the ‘fear of forking’ with the example of a conversation he had with a reluctant CTO. This executive worried that “if we had branches everywhere we’d be stepping all over each other” and didn’t appreciate DVCS’ ability for developers to iterate quickly and collaborate more efficiently.
Steve concludes:
Technology is, more often than not, a pendulum: swinging back and forth between extremes [coverage]. This is not the case with version control software. It is possible – likely, from a historical standpoint – that distributed tools such as Git will be themselves replaced by as yet unforeseen source code management tooling. But we will not be going back in the other direction. The advantages to distributed development are too profound to be abandoned. Organisms that evolve more quickly adapt more quickly, and Darwin tells us that organisms that adapt more quickly survive. Distributed source code tools are proving this true in code every day.
In other words, it might be time to get over your fear of forking.
The State of Version Control in 2016
The past six years have proved Steve entirely correct about the direction of version control; DVCS has clearly won.
The caveats from 2010 about the representational nature of Open Hub’s data continue to apply in 2016; we don’t assert that this is a reflection of all repositories or all VCS. However, it still provides a useful point of reference for version control metadata, and it’s interesting to look at the shift within Ohloh/Open Hub over time. 6 years ago centralized version control represented 86% of repositories, and now it’s just 54%.
Data source: Black Duck Open Hub, December 2016
We can also get a feel for the trends in the marketplace based on the vendors in the marketplace. GitHub tends to the most well-know code host, with 5.8M+ active users and 19.4M+ active repositories. GitHub primarily hosts Git repos but also supports Subversion. Other primary competitors also focus on DVCS support, including
– Bitbucket: Git and Mercurial
– GitLab: Git
– SourceForge: Git, Mercurial, SVN, and CVS
– Launchpad: Git and Bazaar.
While this is not an exhaustive list of code hosting services, this quick pulse of market offerings from dominant vendors indicates that DVSC – and particularly Git – is currently in highest demand in the market.
My Reaction
My first experience with version control was with Git in 2014, meaning DVCS is the only version control I’ve ever known.
"As you learn Git, try to clear your mind of the things you may know about other VCSs"
Done.
— Rachel (@rstephensme) January 27, 2014
Prior to reading Steve’s post, the predecessors to DVCS were either vaguely familiar to me as concepts (Subversion) or standards that I had never heard of at all (CVS). I had honestly never considered that people would have a fear of forking.
Steve’s post introduced me to the history of VCS, but even more importantly it served as a reminder to be more studious of history. Hindsight makes it easy to look at past debates with the an air of omniscience because we know the results; it’s important to remember that what may seem obvious now was at one time deeply contested. We would be wise to review the history of how various technologies/standards/cultural norms evolved to bring us to where we are today. As Steve notes, the technology industry has a propensity to move as a pendulum. It is important to understand the arc of this pendulum over time, but it is especially noteworthy to review the trends like DVCS that break that cycle.
Disclosure: Atlassian (Bitbucket) is a RedMonk client. Also, it should be noted that I know a lot of the fine folks over at GitHub, and I know one of them particularly well. 🙂
B. Reams says:
December 2, 2016 at 3:48 pm
Rachel,
Your last observation about looking into and learning about the history of technical tools, procedures and “norms” is sound advice. Often what is now prevalent was in competition with other approaches. Eventually today’s norm starts to fail to meet our needs. Not uncommonly, looking at what else was available when the today’s choice was not so clear opens up a path to a better solution. A recent example is the use of copper compoundsto fight infections. That went by the way side when antibiotics such as penicillin were discovered. Now, with antibiotic resistant strains of bacteria becoming more common, research is returning to the use of copper-based therapy. What’s old is new again 🙂