The Effect of Version Control Systems on Emacs Developers

In November 2014, Emacs switched version control systems from Bazaar (aka bzr) to git.  There were two main reasons: 1) bzr has kinda stopped development, and 2) using a version control system that more people are familiar with might attract more developers.

On the other hand, git is really, really finicky, and bzr is arguably superior to git in many works flows. Perhaps switching to git would scare away some Emacs developers who just couldn’t be bothered?

It’s now April 2015, so five months have passed, and I whipped up a teensy script to tally the number of patch authors per month, and then plotted the results.

The red line denotes the changeover.

First of all, it’s amusing that we have a timeline going back to 1988, but I would suspect that the numbers before, say, 2007 are too low because maintainers would commit patches with themselves as the “author”, I think.  (Edit: Eli Zaretskii says the numbers should be accurate throughout the timeline.)

But the most recent years should be kinda reliable:

Uhm…  Well, attracting droves of new developers didn’t happen, apparently.  Except for the spike the month git was introduced, we’re within the normal range of developers, I think.

Anything interesting pop up if we count commits per month instead of contributors per month?

Not really — same story.

What about the number of people who commit patches to the Emacs repository?

That does look like a possible uptick.

So…  was the changeover worth it?  Probably.  But the impact was a bit over-sold on both sides, I think.

3 thoughts on “The Effect of Version Control Systems on Emacs Developers”

  1. Super cool that you put this together!

    Given the amount of variance in the ‘Contributors per Month’ data + the fact that all potential contributors won’t immediately know that the changeover happened, it might take a while to see any (potential) gains.

    That said—and speaking as a contributor of *a couple* commits—there are still some big barriers to contribution, and I think we’d see a big increase in contributors if we removed them. Viz., (1) submitting patches via email is rather foreign to a generation of developers growing up with GitHub (and similar), (2) the contribution guidelines, while extensive, aren’t exactly beginner-friendly (IMHO), (3) the ChangeLog situation is out of control (per-directory ChangeLogs? Is this necessary? Feels cargo-culty at this point.), (4) Copyright assignment (not much to be done there though).

    1. The ChangeLogs are gone now, so that helps a bit. But the way we’re supposed to format the git commit messages may still seem pretty weird to most people…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s