<strong>Time Elapsed: 58 min.</strong>
							FIXME: er moeten 13 minuten af.

							<strong>Time Elapsed: 54 min.</strong>
							FIXME: er moeten nog 9 minuten af.

*Voorbereidingen*:
* Start Spectacle.
* Verbind Spotlight.
* Eerste scherm:
  * Speaker notes
* Tweede scherm:
  * Slides

Now, everything you've heard about my country is probably true:

Now, everything you've heard about my country is probably true.
I mean:

* We never drive cars to work; no, we ride our bikes.
  * And we **never** wear a biking helmet.

* Also, we never drive cars to work, no! We ride our bikes.

I actually brought some stroopwafels with me, because in my country we have plenty of them.

note:
Who has heard about stroopwafels already?
If you haven't: a stroopwafel is the best cookie in the world.
And of course I brought some with me, because in my country we have plenty of them.

I didn't say WHEN you get bored, mind you!

Mind you, I didn't say WHEN you get bored!

Or at least I hope there is.

Besides doing consultancy work, I also teach a few courses.
Now at Info Support we offer a wide range of courses, which exist mainly to get our junior colleagues up to speed with important concepts or products they'll need for their daily work.

Now besides doing consultancy work, I also teach a few courses.
At my company Info Support, we offer a wide range of courses.
And they exist mainly to get our junior colleagues up to speed with important concepts or products they'll need for their daily work.
They address base software development topics such as object-orientation, automated testing, continuous delivery, containerisation and so on. 

One of the courses I teach is called 'Git for Developers'.
It's a one-day course where I teach the students how to use Git as a developer (none of that GUI stuff of course; command-line For The Win!).
Besides doing the practical stuff we also discuss the pros and cons of distributed version control systems and how they compare to the earlier VCS's, like CVS and Subversion. 

And one of the courses I teach is called 'Git for Developers'.
It's a one-day course where I teach the students how to use Git **as a developer**.
That means **none** of that GUI stuff; I promote using the command-line as much as possible.
Because using the command-line **rocks**!
Besides practical stuff like this, we also discuss the pros and cons of distributed version control systems and how they compare to the earlier version control system, like CVS and Subversion. 

It displays which version control systems have emerged until now, and when they became available.

And it displays which version control systems have emerged until now, and when they became available.

So, Subversion relates to the Nokia 3210, for example. (*point*)

So, for example, Subversion relates to the Nokia 3210. (*point*)

Both are obviously **ancient**.

Both are obviously **ancient**!

To put things in perspective, before 2005, it had taken **nine** years for five version control systems to emerge.
(Starting with VSS in 1994, and ending with BitKeeper in 2003.)
And in 2005, it all happened within a few months!

To put things in perspective, before 2005, it had taken **nine** years for five version control systems to appear.
Starting with VSS in 1994, and ending with BitKeeper in 2003.
And in 2005, it all happened within a few months.
Now that's remarkable!

So, does anyone know why things happened like this?

So, does anyone happen to know why things happened like this?

They went from open-source to proprietary just like **that**.

BitKeeper went from an open-source license to a proprietary license, just like **that**.

He had been using BitKeeper for the Linux kernel, but was now in need of a new system.

Mr. Torvalds had been using BitKeeper for the Linux kernel, but was now suddenly in need of a new version control system!

And because BitKeeper was the only distributed version control system at the time, which was now no longer freely available, a lot of similar products were developed in a short amount of time.
Including Mr. Torvalds' own rendition of distributed version control, which later became Git.

And what do you do when the only distributed version control system is no longer freely available?
Well, you create a new one, of course!
So in the aftermath of BitKeeper's licensing change, a lot of similar products were developed in a short amount of time.
Including Mr. Torvalds' own rendition of distributed version control, which later would become 'Git'.

Now just because I thought the year 2005 really stood out in this graphic, doesn't necessarily mean it was like that for everyone.
In fact, at the end of one particular course day a student came to me with a question.
And his question proved that he had noticed an **entirely** different thing than I had noticed.

So **I** thought the year 2005 really stood out in this graphic.
Of course, that doesn't necessarily mean everyone thought so.
In fact, at the end of one particular course day, a student came to me with a question.
And his question proved that he had noticed an **entirely** different thing than I had.

So I told him I was quite sure distributed version control systems like Git and Mercurial would be around for a while longer.
But this wasn't the right answer, really.
Because **I didn't know** what was gonna be the next big thing.
So it was a great question, actually.
And he was right in asking the question, of course.
Because if you look at the chart and you look beyond what you've already seen (the year 2005), then it becomes painfully obvious...
That in version control land, nothing seems to have happened after 2006.

So I turned around and looked at the chart for a while, thinking "Huh!" 
"Funny how it seems we can't look any further, after we think we've got it all figured out."
Because if you look at the chart and you look beyond what you've already seen (the year 2005), then it becomes painfully obvious -- that in version control land, **nothing** seems to have happened after 2006.

FIXME: het volgende verhaaltje vloeiender, natuurlijker laten lopen.
En het kan ook best wat korter.

Now I turned to the student and told him everything I knew.
That I was quite sure that distributed version control systems like Git and Mercurial would be around for a while longer.
But this wasn't a proper answer at all!
Because **I didn't know** what was gonna be the next big thing.

Now I kind of felt bad that I had dodged my student's question a bit by telling him distributed version control was the present **and** the future.
I had effectively told him that "Git will probably be around forever", even if I didn't phrase it exactly like that.
And I really hated the fact that I couldn't tell him more on the subject, so I decided to research the matter a bit further.

Now afterwards, I really felt bad about not being able to answer his question directly.
I had effectively told the guy that "Git will probably be around forever", even if I didn't phrase it exactly like that.
So I decided to research the matter a bit further.

I'm going to assume that you are all more or less like the student I told you about.
He just couldn't believe that everything in version control land would stay the same for a long period of time.
And I hope you're also a little bit like me, because you probably also can't stand not being able to know the answer to a question.
So, let's see if we can find the answer together, shall we?

And let's see if we can find the answer to the student's question together, shall we?
And after we find out, I'll make sure that he gets the answer as soon as possible.
OK? I promise.

Now, whenever I hear somebody say that [insert-product-name-here] "will probably be around forever", it immediately reminds me of...

Now, whenever I hear somebody say that some product "will probably be around forever", it immediately reminds me of...

* Browser behaviours change.
Agile was invented for a reason! To be able to cope with CHANGE.
Because in our industry, change is the only constant
And it has been like that for a long time.
---
<!-- .slide: data-background="img/background/what-goes-up-must-come-down.jpg" --->
[Photo credit: Quang Le](https://quotefancy.com/quote/833239/Isaac-Newton-What-goes-up-must-come-down) <!-- .element: class="attribution" -->
note:
Now if the idea of "Change is the only constant" is valid in our industry, then so is the idea of "What goes up, must come down".
And although Newton (*point*) probably talked about an apple here, his quote can be applied to a lot of things, including:
* airplanes;
* Bitcoin prices;
* browser market shares;
* and maybe even version control system market shares.
FINAL: wanneer voorbereidingstijd over, gebruik hier dan meer slides met plaatjes van de voorbeelden.
---
<!-- .slide: data-background="img/background/crystal-ball.jpg" data-background-color="black" data-background-opacity="0.5" --->

* Or if you work in front-end: browser behaviours change.

## What goes up must come down.
<blockquote class="explanation">
    <code>prediction variable</code>
</blockquote>
<https://www.pexels.com/photo/photo-displays-person-holding-ball-with-reflection-of-horizon-940880> <!-- .element: class="attribution" -->
note:
FIXME: leg het idee van 'prediction variable' wat beter uit.
Throughout this talk, we will discover several ideas that I will use as input variables for the final prediction.
At the moment we're far from it.
But we'll get there in the end, by identifying more prediction variables.
The idea of "What's goes up..." is actually the first variable that we'll use.
Because...? FIXME

To me, this proves that in our industry, change is the only constant.
So no, Git *won't* be around forever.
Eventually, there will be a successor.

# Why has Git become so popular?

# Why did Git become so popular?

**Time Elapsed:** 11 min.

**Time Elapsed:** 10 min.

So, it's great that now we know 'what goes up, must come down'.
But it's not enough to make a sound prediction.

The question remains: which one will it be?
Which one will be the successor?

FIXME: regel wat meer aansluiting met vorige onderwerp.

Now in finding the answer to this question, we obviously have to make a prediction.
We have to predict which version control system will be popular in, say, ten years.
And throughout this talk, we will discover several ideas that can be useful to our prediction. 
I call these ideas 'prediction variables'.
At the end of the talk, we will use these 'variables' to make the final prediction.

Now if we want to be able to predict 'the next big thing' in version control, surely some information on the 'current big thing' is very relevant to our quest.
Moreover, it could be useful to understand how 'the current big thing' became 'the big thing' in the first place.

And I think we can discover them quickly by gathering information on the 'current big thing'.
And how 'the current big thing' became 'the big thing' in the first place.
So, why *did* Git become so popular?

## Features of Git

## Main features of Git

FIXME: leg wat verder uit waarom deze features - of liever gezegd: deze combinatie van features - baanbrekend waren in die tijd.

Well, as you may already know, these are Git's main features:

  * **Unlike** BitKeeper

  * **Unlike** BitKeeper, obviously!

 * Linus said "everything you ever do on a daily basis should take less than a second".

  * Linus said "everything you ever do on a daily basis should take less than a second".

> "First Linux, now Git"

<blockquote class="fragment">
    "I'm an egotistical bastard, so I name all my projects after myself. First Linux, now git."
</blockquote>

When asked why he called the new software, "git," British slang meaning "a rotten person," he said. "I'm an egotistical bastard, so I name all my projects after myself. First Linux, now git."

When Linus Torvalds was asked why he called the new software, "git," British slang meaning "a rotten person," he said:
[slide] 
"I'm an egotistical bastard, so I name all my projects after myself. First Linux, now git."

When Linus Torvalds was developing Git, one of his guiding principles was WWCVSND, or “What Would CVS Not Do.” Take CVS as an example of what not to do; if in doubt, make the exact opposite decision.

When Linus Torvalds was developing Git, one of his guiding principles was WWCVSND, or “What Would CVS Not Do.” 
Which means: 
Take CVS as an example of what not to do; and if in doubt, make the exact opposite decision.

    <code>prediction variable</code>

    <code>prediction variable #1</code>

FIXME: Introduceer deze variable wat beter.

Now I think 'Killer features' should be our first *prediction variable*.

Killer features are new features (that have never been seen) or different features (where a similar feature has been implemented in a radically different way, to distinguish it from the competitors).

And by 'Killer features' I mean two things:
* new features (that have never been seen); or 
* similar features, implemented differently (where a similar feature has been implemented in a radically different way, to distinguish it from any competitors).

* Surprising name
* Opposite of CVS in many aspects
* ...

Git is a great example of 'Killer features', because it was designed to be the opposite of CVS in many aspects.
And it went and got popular, so lots of reasons to use 'Killer features' as a prediction variable.

[https://blog.gitprime.com/git-didnt-beat-svn-github-did/](https://blog.gitprime.com/git-didnt-beat-svn-github-did/) <!-- .element: class="attribution" -->

<https://blog.gitprime.com/git-didnt-beat-svn-github-did> <!-- .element: class="attribution" -->

Here is some information on how 'the current big thing' - which is Git - became 'the big thing'.

Here is some information on how Git became 'the big thing'.

There's a lot of significant information in this chart: (*point*)
* Git's growth increased rapidly after it was supported by Github (2008), Bitbucket (2012) and Gitlab (2013).

Now there's a lot of significant information in this chart: (*point*)
* For example, Git's growth increased rapidly after it was supported by Github (2008), Bitbucket (2012) and Gitlab (2013).

* The numbers we see here are based on *relative search volume*. It is not the **actual** usage of the products. Version control system popularity is actually quite hard to measure! (more on this later)

FIXME: meer verhaaltje hier.

I would like to point out that all data that's displayed here is an approximation of the real usage. 
It is not the **actual** usage of the products.
Version control popularity can't be *measured* like with browsers, for example.
These data were acquired by combining usage statistics from various sources.
Sources like Google Trends, GitHub, Atlassian and GitLab.
So any prediction based on these estimates will also be an estimate. 

--- 
## Influence of source code hosting on popularity
<https://en.wikipedia.org/wiki/Comparison_of_source-code-hosting_facilities#Version_control_systems>

    <code>prediction variable</code>

    <code>prediction variable #2</code>

FIXME: Introduceer deze variable.

So it seems that the available source code hosting for a particular version control system has quite some influence on its popularity!
Which is why I think "Hosting platform support" should be our second 'prediction variable'.

FIXME: Introduceer de PV "Open-source community support."

<!-- .slide: data-background="img/background/crystal-ball.jpg" data-background-color="black" data-background-opacity="0.5" --->

---

## Open-source community support.

<!-- .slide: data-background-color="#f9f9f9" data-background="img/background/vcs-popularity-graph.png" data-background-size="60%" --->

<blockquote class="explanation">
    <code>prediction variable #3</code>
</blockquote>

[https://blog.gitprime.com/git-didnt-beat-svn-github-did/](https://blog.gitprime.com/git-didnt-beat-svn-github-did/) <!-- .element: class="attribution" -->

<https://www.pexels.com/photo/photo-displays-person-holding-ball-with-reflection-of-horizon-940880> <!-- .element: class="attribution" -->

Let's return to this chart one more time and allow me to address a final point:

Let's introduce another one, while we`re at it!
Your version control system may be supported by a hosting provider, but that doesn't necessarily mean that said hosting provider supports the open-source community.
Lots of hosting providers primarily offer private repositories.
Also, not all version control systems focus as much on open-source develoment as Git does, for example.
So, here's prediction variable number three: "Open-source community support."

* The numbers we see here are based on *relative search volume*. It is not the **actual** usage of the products. Version control system popularity is actually quite hard to measure! (more on this later)

That's enough about prediction variables, for now.
Let's try and make a first prediction.
Which at this early stage can only be done by using one approach:
"Extrapolate from incomplete data"

## Measuring Version Control System Popularity

<!-- .slide: data-background="img/background/there-are-two-types-of-people.png" data-background-size="cover" --->

* This is very hard.

<https://bingeprints.com/products/there-are-two-types-of-people-those-who-can-extrapolate-from-incomplete-data-mug-funny-statistics-math-coffee-cup-1> <!-- .element: class="attribution" -->

FIXME: dit verhaaltje kan beter. 
En schrijf wat naar het Google Trends-voorbeeld toe.

After all, we all know there are only two types of people in the world.
1. Those who can extrapolate from incomplete data.

In Stack Overflow’s 2015 developer survey, 69.3% of respondents used Git, almost twice as many as used the second-most-popular version control system, Subversion. After 2015, Stack Overflow stopped asking developers about the version control systems they use, perhaps because Git had become so popular that the question had become uninteresting.

So, let's take some existing data and extrapolate it!

<https://trends.google.nl/trends/explore?date=today%205-y&q=git,subversion,mercurial> <!-- .element: target="_blank" -->

<!-- .slide: data-background-color="#f9f9f9" data-background="img/background/vcs-popularity-graph.png" data-background-size="60%" --->
<https://blog.gitprime.com/git-didnt-beat-svn-github-did> <!-- .element: class="attribution" -->

<!-- .slide: data-background-video="video/programming-language-popularity-stack-overflow.mp4" data-background-video-muted="true" data-background-size="contain" -->

## First Prediction

<https://www.globalapptesting.com/blog/picking-apart-stackoverflow-what-bugs-developers-the-most> <!-- .element: class="attribution" -->

<table>
    <thead>
        <tr>
            <th/>
            <th>2009</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <th align="right">Subversion</th>
            <td align="right">43%</td>
        </tr>
        <tr>
            <th align="right">Git</th>
            <td align="right">19%</td>
        </tr>
        <tr>
            <th align="right">Mercurial</th>
            <td align="right">16%</td>
        </tr>  
        <tr>
            <th align="right">TFS</th>
            <td align="right">6%</td>
        </tr>
        <tr>
            <th align="right">CVS</th>
            <td align="right">5%</td>
        </tr>      
    </tbody>
</table>

note:
FIXME: leg uit waarom dit niet de metriek is die je wilt. :-)

---
<!-- .slide: data-background-color="#f9f9f9" data-background="img/background/vcs-popularity-graph.png" data-background-size="60%" --->

Wat betekent het als er veel vragen worden gesteld?
* veel gebruikers van de taal?
* veel onervaren gebruikers?
* de taal is moeilijk te leren / niet intuïtief?

<https://blog.gitprime.com/git-didnt-beat-svn-github-did> <!-- .element: class="attribution" -->

## First Prediction

<!-- .slide: data-background="img/background/there-are-two-types-of-people.png" data-background-size="cover" --->

<table>
    <thead>
        <tr>
            <th/>
            <th>2009</th>
            <th>2019</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <th align="right">Subversion</th>
            <td align="right">43%</td>
            <td align="right">8%</td>
        </tr>
        <tr>
            <th align="right">Git</th>
            <td align="right">19%</td>
            <td align="right">73%</td>
        </tr>
        <tr>
            <th align="right">Mercurial</th>
            <td align="right">16%</td>
            <td align="right">12%</td>
        </tr>  
        <tr>
            <th align="right">TFS</th>
            <td align="right">6%</td>
            <td align="right">7%</td>
        </tr>
        <tr>
            <th align="right">CVS</th>
            <td align="right">5%</td>
            <td align="right">&lt;1%</td>
        </tr>      
    </tbody>
</table>

<https://bingeprints.com/products/there-are-two-types-of-people-those-who-can-extrapolate-from-incomplete-data-mug-funny-statistics-math-coffee-cup-1> <!-- .element: class="attribution" -->

---

note:
Of course, this shouldn't stop us from making a first prediction!
After all, we all know there are only two types of people in the world.
1. Those who can extrapolate from incomplete data.

<!-- .slide: data-background-color="#f9f9f9" data-background="img/background/vcs-popularity-graph.png" data-background-size="60%" --->

FIXME: meer verhaaltje.

<https://blog.gitprime.com/git-didnt-beat-svn-github-did> <!-- .element: class="attribution" -->

            <th class="fragment" data-fragment-index="1">2019</th>
            <th class="fragment" data-fragment-index="2">2029</th>

            <th>2019</th>
            <th>2029</th>

            <td align="right">45%</td>
            <td align="right" class="fragment" data-fragment-index="1">8%</td>
            <td align="right" class="fragment" data-fragment-index="2">4%</td>

            <td align="right">43%</td>
            <td align="right">8%</td>
            <td align="right">4%</td>

            <td align="right">20%</td>
            <td align="right" class="fragment" data-fragment-index="1">73%</td>
            <td align="right" class="fragment" data-fragment-index="2">80%</td>

            <td align="right">19%</td>
            <td align="right">73%</td>
            <td align="right">80%</td>

            <td align="right">17%</td>
            <td align="right" class="fragment" data-fragment-index="1">12%</td>
            <td align="right" class="fragment" data-fragment-index="2">9%</td>

            <td align="right">16%</td>
            <td align="right">12%</td>
            <td align="right">9%</td>

            <td align="right">11%</td>
            <td align="right" class="fragment" data-fragment-index="1">7%</td>
            <td align="right" class="fragment" data-fragment-index="2">7%</td>

            <td align="right">6%</td>
            <td align="right">7%</td>
            <td align="right">7%</td>

            <td align="right">7%</td>
            <td align="right" class="fragment" data-fragment-index="1">&lt;1%</td>
            <td align="right" class="fragment" data-fragment-index="2">&lt;1%</td>

            <td align="right">5%</td>
            <td align="right">&lt;1%</td>
            <td align="right">&lt;1%</td>

note:
FIXME: leg deze voorspellingen uit aan de hand van de populariteitsgrafiek.

FIXME: vind een manier om hier snel te kunnen wisselen naar de populariteitsgrafiek, *zonder dat de fragment state verandert*. 
Een optie: open het plaatje als voorbereiding en zet deze direct op het tweede scherm neer. 
Dan moet ik die voorbereiding wel ergens vastleggen (bij voorkeur op de titelslide in de notities).

Yeah, one problem though.
We haven't included *any* new products.

---
<!-- .slide: data-background="img/background/usb-sticks.jpg" data-background-color="black" data-background-opacity="0.3"-->
## Version Control 'By USB Stick'
<https://pxhere.com/en/photo/652221> <!-- .element: class="attribution" -->
note:
The next big thing could be 'Version Control By USB Stick', for example.
Haven't you been wondering why some of my slides have had USB sticks in the background?
It's a great story.
FIXME: dit verhaaltje uitwerken.
I can assure you that we don't need to worry about 'Version Control By USB Stick'. 
It will not get popular, for obvious reasons.

**Time Elapsed:** 21 min.

**Time Elapsed:** 17 min.

This is not the first time I'm speaking on popularity of a software product.

This is exactly what happened during 'The Browser Wars'.
Multiple times, actually.

So the talk was actually quite similar to this one.
Apart from the fact that my slides back then looked **very** different.

The background gradient.

Which were present on **every** slide.
They were obviously a major waste of space.
Also: the background gradient.

Fantastic stuff.
If you would just wait for fifteen years, it would be fashionable again.

Horrifying stuff!
I think slide deck designs are a lot like fashion.
If you just wait for fifteen years, they will be popular again.
Don't you think so?

The slide also shows that the Internet Explorer browser family was VERY dominant in 2005.

Anyway, apart from the fact that this slide causes your eyes to sting, it also shows that the Internet Explorer browser family was VERY dominant in 2005.

Now in this talk I predicted three things, of which two **actually really happened**.

Now in this college talk I predicted three things, of which two **actually really happened**.

note:
## In ten years time...
1. ...Internet Explorer would be surpassed as the top browser family;
2. ...Mozilla Firefox would surpass Internet Explorer;
3. ...Mozilla Firefox would be the top browser.
---
## In ten years time...
1. ...Internet Explorer would be surpassed as the top browser family;
2. ...Mozilla Firefox would surpass Internet Explorer;
3. ~...Mozilla Firefox would be the top browser.~

FIXME: leg dit mechanisme beter uit. Wat er zeker in moet voorkomen:
* een dominant product trekt meer aandacht, zowel positief als negatief:
  * vatbaarder voor maliciousness - zie virussen op Windows vs. Linux
  * meer mensen kennen je product en kunnen in theorie iets nieuws verzinnen dat je product nog niet heeft.

The dominant product will get a lot of attention. 
Both positive *and* negative.
Your product - or the users of your product - could be popular victims of malicious software
(This is the reason why there are so many viruses on Windows, compared to Linux for example)
Also, if more people know your product, then in theory they can come up with fresh new ideas that your product doesn't have.
Just like in sports, it is a lot harder to stay on top, than it is to get there.

FIXME: Introduceer deze variable. Voeg waar mogelijk samen met het verhaal hieronder.
Because who in their right mind would dare to claim that Google Chrome will be around forever?
I mean, it will probably be gone in ten years or so...
By then it will have been replaced by a superior product.
These replacements in the browser world have happened at least four times until now.
Mosaic was replaced by Netscape, which was replaced by Internet Explorer.
Which was replaced by Internet Explorer, which was replaced by Mozilla Firefox, which was replaced by Google Chrome.
And I can't think of a reason why it wouldn't happen for a fifth time.
FIXME: bedenk een verbindende zin naar het volgende onderwerp. 
En hopelijk iets beters dan wat er nu staat.

So here's our final prediction variable.
It is hard to stay on top, hence "the disadvantage of the dominant product".
Eventually the dominant product will be replaced by a new one, like the browser world.
Netscape was replaced by Internet Explorer.
Internet Explorer was replaced by Mozilla Firefox
Mozilla Firefox was replaced by Google Chrome.
And I can't think of a reason why it wouldn't happen again.

So let's see how these things have happened until now in the version control world!

So let's return to the version control world antd see which products we need to investigate as aspiring successors of Git!

**Time Elapsed:** 26 min.

**Time Elapsed:** 22 min.

<!-- .slide: data-background-iframe="pdf/version-control-history-poster.pdf" -->

## Four new(er) kinds on the block

---

These four Version Control Systems have been published after the large Distributed Version Control wave in March/April 2005. 
FIXME: why did I choose to consider these four and not a few older ones?

These four Version Control Systems have been published after the large Distributed Version Control wave in March/April 2005.
I knowingly didn't choose to investigate products that were published *before* Git.
Because let's face it: these products have already been beaten by a newer product - being Git.
So I can't imagine any product older than Git to still beat it in the future.
If that would be true, it should have happened already.
And... it didn't!

# Veracity

## Veracity (2011)

<!-- FINAL: add Veracity logo -->

![Veracity logo](img/logos/veracity.png) <!-- .element: class="no-background" -->

* Hosting platform onveracity.com hasn't been online since February 4, 2015

* Hosting platform www.onveracity.com hasn't been online since February 4, 2015

FIXME - why was this one even in the abstract and why that's the only reason I have included it.

Sorry if this is a bit of an anti-climax.
But in the talk abstract I included Veracity as one of the contenders.
And when I wrote the abstract I never thought about the fact that it could disappear from the Internet altogether.
Because that's literally what happened.
But no worries, I've found a replacement contender!
Which is Plastic.

<!-- FINAL: add Plastic logo -->

![Plastic logo](img/logos/plastic.png) <!-- .element: class="no-background" -->

* Their references are almost exclusively game studios

* References on their website are exclusively from game studios

* Git users are not switching SCM's just for some *eye candy*

* Git users are not changing their VCS just for some *eye candy*

* Git users are not switching SCM's just for some *eye candy*

* Git users are not changing their VCS just for some *eye candy*

**Time Elapsed:** 30 min.

**Time Elapsed:** 26 min.
Now we get to the more serious contenders!
And first up is Fossil.

* show **descendants** of a checkin

* show **descendants** of a check-in

FIXME: uitbreiden
* **autosync mode** - push automatically after each check-in

* **autosync mode** - pushes automatically after each check-in

note:
FIXME:
The difference is that Git stores its objects as individual files in the ".git" folder or compressed into bespoke "pack-files", whereas Fossil stores its objects in a relational (SQLite) database file. To put it another way, Git uses an ad-hoc pile-of-files key/value database whereas Fossil uses a proven, general-purpose SQL database. This difference is more than an implementation detail. It has important consequences.

* a repository is stored in a single SQLite database file
* contains relations between check-ins to be able to produce both ancestors and descendants of a check-in 

With Git, one can easily locate the ancestors of a particular check-in by following the pointers embedded in the check-in object, but it is difficult to go the other direction and locate the descendants of a check-in. It is so difficult, in fact, that neither native Git nor GitHub provide this capability. With Git, if you are looking at some historical check-in then you cannot ask "what came next" or "what are the children of this check-in".

![Fossil logo](img/logos/fossil.png) <!-- .element: class="no-background" width="12%" -->

Fossil, on the other hand, parses essential information about check-ins (parents, children, committers, comments, files changed, etc.) into a relational database that can be easily queried using concise SQL statements to find both ancestors and descendents of a check-in.

note:
In Git a single commit knows only who its ancestor is.
So producing a list of all descendants of a commit is nearly impossible.
Both native Git and GitHub don't provide this capability.

* repository UI

* repository UI (`fossil ui`)

FIXME: 
So there's no need to use 3rd party products; after cloning a repo you have a fully-featured developer website available.

And, speaking of Github, Fossil is actually some sort of 'Github in a box'.
A feature-rich web interface is available through the command `fossil ui`.
So there's no need to use any 3rd party products; after cloning a repo you have a fully-featured developer website available.

This makes Fossil:

**Time Elapsed:** 38 min.

**Time Elapsed:** 34 min.

* Pijul keeps track of 'dependent patches'
* No merges or rebases; applying a patch is like `git cherry-pick`.

FIXME: toelichting schrijven

In contrast, Git doesn't store patches.
It stores snapshots.

<!-- FIXME: dit gaan we niet allemaal demonstreren, zie de notes --->

  * (but maybe we don't need them - https://nest.pijul.com/tae/pijul-for-git-users)

!!! Throw the dice on stage !!!

!!! Roll the die on stage !!!

* FIXME: verzin er nog een

<https://mivehind.net/2017/04/09/pijul-first-thoughts> <!-- .element: class="attribution" -->

<https://mivehind.net/2017/04/09/pijul-first-thoughts>

FIXME: verwerk dit nog ergens (bron: https://news.ycombinator.com/item?id=19090514)
I've not used Pijul, but I used Darcs — which Pijul is essentially an improved clone of — for half a decade, and I assume it's roughly the same.
The patch model is incredible. Think of "git cherry-pick". Imagine you could use that instead of "git merge" or "git rebase" for all your work. Imagine that every time you cherry-picked, it would tell you which additional commits you'd need, and then pick them for you. And that when you merged your heavily cherry-picked branch back into the mainline, it just worked. That's Pijul/Darcs.
One doesn't have to understand the "theory of patches" to use Pijul/Darcs. As a user, you just work with changes, just like Git. But the UX is much simpler than Git — in a good way.
I remember switching from Darcs to Git back in 2008 or so. It was like switching out a sleek spaceship [] for an old rusty, clanking pickup truck. Git has gotten better over the years, but ultimately, I think Github was the killer app, not Git. Going back technical merits alone, Darcs and Mercurial "should" have won that battle.

**Time Elapsed:** 48 min.

**Time Elapsed:** 44 min.
Well, the wait is finally over, it's prediction time!
About time, right?
Let's compile a list of the prediction variables that we've assembled. 

* What goes up, must come down.

Looks like we've gathered four prediction variables so far:

* **What goes up, must come down.** But when?
* **Hosting platform support** 
<!-- FIXME: gebruik "img/background/hosting-platform-support" voor een weergave van de stand van zaken voor Git, Hg, Svn en Fossil. -->
* FIXME: afmaken

* **Killer features.**
* **Hosting platform support.** 
* **Open-source community support.**
* **The disadvantage of the dominant product.**

## The scores

<table>
    <thead>
        <tr>
            <th/>
            <th>Git</th>
            <th>Hg</th>
            <th>TFS</th>
            <th>Fossil</th>
            <th>Pijul</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <th align="right">Features</th>
            <td align="right">-1</td>
            <td align="right">-1</td>
            <td align="right">-1</td>
            <td align="right">+1</td>
            <td align="right">+2</td>
        </tr>  
    </tbody>
</table>

<!-- FIXME: toon een matrix van PV's en VCS's (de 5 bestaande plus Fossil, Pijul) en deel scores uit.
Tussen -2 en +2.
En toon onderaan een totaalscore.
--->

note:
Pijuls major feature (fast patch-based versioning) might lure new users who think Git is too difficult to understand.
Fossil just adds 'show descendants' and integrated developer website to the mix, which is a bit less 'killer'.

## Prediction matrix 2.0
<!-- 
FIXME: Pas scores van bestaande VCS's aan (eventueel) en laat de veranderingen zien tov 'First Prediction'.
Dat zou bijvoorbeeld kunnen met ~strikethrough~.git  
FIXME: Voeg Fossil en Pijul toe en geef ze een plek.
FIXME: Maak per 'decennium' een slide en pas de volgorde van populariteit daarin aan, zodat je zaken ziet 'verspringen'.
-->

            <th>2009</th>
            <th class="fragment" data-fragment-index="1">2019</th>
            <th class="fragment" data-fragment-index="2">2029</th>

            <th>Git</th>
            <th>Hg</th>
            <th>TFS</th>
            <th>Fossil</th>
            <th>Pijul</th>

            <th align="right">Subversion</th>
            <td align="right">45%</td>
            <td align="right" class="fragment" data-fragment-index="1">8%</td>
            <td align="right" class="fragment" data-fragment-index="2">4%</td>

            <th align="right">Features</th>
            <td align="right">-1</td>
            <td align="right">-1</td>
            <td align="right">-1</td>
            <td align="right">+1</td>
            <td align="right">+2</td>
        </tr>  
        <tr class="fragment">
            <th align="right">Hosting</th>
            <td align="right">+2</td>
            <td align="right">+1</td>
            <td align="right">-1</td>
            <td align="right">+1</td>
            <td align="right">+1</td>
        </tr>
        <tr class="fragment">
            <th align="right">Open-source</th>
            <td align="right">+2</td>
            <td align="right">+2</td>
            <td align="right">-2</td>
            <td align="right">-1</td>
            <td align="right">+1</td>
        </tr>
        <tr class="fragment">
            <th align="right">Dominant</th>
            <td align="right">-2</td>
            <td align="right">-1</td>
            <td align="right">0</td>
            <td align="right">0</td>
            <td align="right">0</td>
        </tr>    
        <tr class="fragment">
            <th/>
            <th align="right">+1</td>
            <th align="right">+1</td>
            <th align="right">-4</td>
            <th align="right">+1</td>
            <th align="right">+4</td>
        </tr>              
    </tbody>
</table>
---
<table>
    <thead>
        <tr>
            <th/>
            <th>2029</th>

    </thead>
    <tbody>

            <td align="right">20%</td>
            <td align="right" class="fragment" data-fragment-index="1">73%</td>
            <td align="right" class="fragment" data-fragment-index="2">80%</td>

            <td align="right">80%</td>

            <td align="right">17%</td>
            <td align="right" class="fragment" data-fragment-index="1">12%</td>
            <td align="right" class="fragment" data-fragment-index="2">9%</td>

            <td align="right">9%</td>

            <td align="right">11%</td>
            <td align="right" class="fragment" data-fragment-index="1">7%</td>
            <td align="right" class="fragment" data-fragment-index="2">7%</td>

            <td align="right">7%</td>

        <tr>
            <th align="right">Subversion</th>
            <td align="right">4%</td>
        </tr>     

            <td align="right">7%</td>
            <td align="right" class="fragment" data-fragment-index="1">&lt;1%</td>
            <td align="right" class="fragment" data-fragment-index="2">&lt;1%</td>

            <td align="right">&lt;1%</td>

## Prediction chart

<!-- FIXME: wanneer voorbereidingstijd over, breid de VCS Popularity Chart uit richting 2029. -->

<table>
    <thead>
        <tr>
            <th/>
            <th><del>2029</del></th>
            <th>2029</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <th align="right">Git</th>
            <td align="right"><del>80%</del></td>
            <td align="right">77%</td>
        </tr>
        <tr>
            <th align="right">Mercurial</th>
            <td align="right"><del>9%</del></td>
            <td align="right">8%</td>
        </tr>
          <tr>
            <th align="right">Pijul</th>
            <td align="right"></td>
            <td align="right">5%</td>
        </tr>      
        <tr>
            <th align="right">TFS</th>
            <td align="right"><del>7%</del></td>
            <td align="right">4%</td>
        </tr>
        <tr>
            <th align="right">Subversion</th>
            <td align="right"><del>4%</del></td>
            <td align="right">4%</td>
        </tr>  
        <tr>
            <th align="right">Fossil</th>
            <td align="right"></td>
            <td align="right">2%</td>
        </tr>           
        <tr>
            <th align="right">CVS</th>
            <td align="right"><del>&lt;1%</del></td>
            <td align="right">&lt;1%</td>
        </tr>      
    </tbody>
</table>

<!-- #1: On measuring VCS popularity. Moved from `2-git.md`. --->
---
<!-- .slide: data-background-color="#f9f9f9" data-background="img/background/vcs-popularity-graph.png" data-background-size="60%" --->
[https://blog.gitprime.com/git-didnt-beat-svn-github-did/](https://blog.gitprime.com/git-didnt-beat-svn-github-did/) <!-- .element: class="attribution" -->
note:
Let's return to this chart one more time and allow me to address a final point:

* The numbers we see here are based on *relative search volume*. It is not the **actual** usage of the products. Version control system popularity is actually quite hard to measure! (more on this later)
---
## Measuring Version Control System Popularity
* This is very hard.
note:
FIXME: dit verhaaltje kan beter. 
En schrijf wat naar het Google Trends-voorbeeld toe.
In Stack Overflow’s 2015 developer survey, 69.3% of respondents used Git, almost twice as many as used the second-most-popular version control system, Subversion. After 2015, Stack Overflow stopped asking developers about the version control systems they use, perhaps because Git had become so popular that the question had become uninteresting.
---
<https://trends.google.nl/trends/explore?date=today%205-y&q=git,subversion,mercurial> <!-- .element: target="_blank" -->
---
<!-- .slide: data-background-video="video/programming-language-popularity-stack-overflow.mp4" data-background-video-muted="true" data-background-size="contain" -->
<https://www.globalapptesting.com/blog/picking-apart-stackoverflow-what-bugs-developers-the-most> <!-- .element: class="attribution" -->
note:
FIXME: leg uit waarom dit niet de metriek is die je wilt. :-)
Wat betekent het als er veel vragen worden gesteld?
* veel gebruikers van de taal?
* veel onervaren gebruikers?
* de taal is moeilijk te leren / niet intuïtief?
---
<!-- #2: What features would you suggest for a 'Git killer' product? -->
note:
Engage the audience in suggesting a few new features or improvements that would make them consider switching from Git.
---
<!-- #3: Version control by USB Stick. Moved from 2-git.md. -->
---
<!-- .slide: data-background="img/background/usb-sticks.jpg" data-background-color="black" data-background-opacity="0.3"-->
## Version Control 'By USB Stick'
<https://pxhere.com/en/photo/652221> <!-- .element: class="attribution" -->
note:
The next big thing could be 'Version Control By USB Stick', for example.
Haven't you been wondering why some of my slides have had USB sticks in the background?
It's a great story.
FIXME: dit verhaaltje uitwerken.
I can assure you that we don't need to worry about 'Version Control By USB Stick'. 
It will not get popular, for obvious reasons.
---
<!-- #4: What goes up, must come down. Moved from 1-preface.md -->
<!-- .slide: data-background="img/background/what-goes-up-must-come-down.jpg" --->
[Photo credit: Quang Le](https://quotefancy.com/quote/833239/Isaac-Newton-What-goes-up-must-come-down) <!-- .element: class="attribution" -->
note:
Now if the idea of "Change is the only constant" is valid in our industry, then so is the idea of "What goes up, must come down".
And although Newton (*point*) probably talked about an apple here, his quote can be applied to a lot of things, including:
* **airplanes**; 
  * I got here on an airplane, and it obviously came down. In a well-organised way, mind you!
* **Bitcoin prices**;
  * They went up, and they went down,
* **browser market shares**;
  * Everyone used Netscape, then it went down and we used Internet Explorer 6. Then Mozilla Firefox. Then Google Chrome.
* and maybe even **version control system market shares**. 
  * But I guess we'll find out!
---
<!-- .slide: data-background="img/background/crystal-ball.jpg" data-background-color="black" data-background-opacity="0.5" --->
## What goes up must come down.
<blockquote class="explanation">
    <code>prediction variable #1</code>
</blockquote>
<https://www.pexels.com/photo/photo-displays-person-holding-ball-with-reflection-of-horizon-940880> <!-- .element: class="attribution" -->