The other side of forking and pull requests

Charles Nutter of JRuby fame had this tweet yesterday:

And this touches on something I’ve been thinking for a long time.

My experience mostly comes from the Jenkins project, which is one of the open commit policy projects. Everyone gets to be a committer just by asking, and that grants them access to all the plugins. This policy is deep in our culture that we even have an IRC bot that the project people use to add new committers.

This is not necessarily a good idea for every project, but it certainly served us well, especially back in the days when we had the entire source code in the Subversion repository. During that time, for people to make changes to the plugins, they really needed to be a committer — maintaining a custom patch set on top of an external Subversion repository is a royal pain in the back side. The open commit policy means anyone interested in committing can join the project without a fuss, and once they become a contributor and start commiting code, they feel like being a part of the project, and that feeds fresh blood into the Jenkins developer community.

While I totally believe in the technological superiority of Git as a version control system over Subversion, in my view, the fork and pull-request driven world of Git hasn’t been a complete win for the Jenkins project.

Forking and pull requests do encourage contributions by eliminating certain barriers to start hacking on someone else’s project. Whereas it was quite painful to maintin patches externally to someone else’s source code in Subversion, Git makes this trivial with branching and occasional rebases or merges. This part is a good thing.

On the other hand, this ease of maintaining your own versions reduces the incentive to bring your changes back to the community, to some extent. After all, you’ve already scratched your itch and it works on your machine. Why bother trying to push the code back and go through the trouble of writing tests and documenting the change, convincing others about the design, and arguing why that change was needed to begin with. You can see this in a number of forks people created that never turns into as pull requests, and I’ve done this a number of times myself.

An even bigger problem in my mind is that by allowing people to contribute by just sending pull requests, it encourages the “throw the stuff over the wall” way of contributing. Sometimes people can do stuff without telling us anything upfront, and you as a receiver would be hard-pressed to turn it down, given that someone spent so much effort in it. Sometimes when we request additional changes, they never come back. It makes the collaboration and communication after the fact, not before the coding. And it also makes the pathway to the committer bit unclear. How do we convert people from the side sending pull requests to the side receiving pull requests? If we have to ask them one by one it won’t scale.

The situation gets worse on plugins, where there may not be an active maintainer at the moment. We’d like those who are sending us pull requests to take over the maintainership, and use their best judgement to evaluate the changes. But when GitHub makes them feel like the proper way to contribute is by sending a pull request, and if your pull requests do not get any attention, I’m not sure how they are supposed to realize that the plugin needs a new owner. Back in the days of Subversion, the repository alone was enough to be a center of gravity of the project. It attracts new developers (so long as we let them be, aka open commit policy) and it’s almost self sustaining. Now it takes more than just the repository.

In any case, I just wanted to point out that the impliations of forking and pull requests are bit more nuanced.

P.S. I’ve been long meaning to write a bot that patrols for such unattended pull requests, and encourage them to become committers, but haven’t had a chance to do so yet. I still intend to do this, and we’ll see how it goes.

GitHub releases Janky

I saw an announcement that GitHub released Janky today.

I initially got confused a bit because the post says Janky is a continuous integration server, which got me thinking that it’s something you’d use instead of Jenkins, but as I read more about it, it became clear that it’s something you use in conjunction with Jenkins — it’s an application that sits between GitHub API, Jenkins API, and Hubot chat bot to help you create jobs on Jenkins, set up build triggers from push notifications, and so on. So for those who are using GitHub for hosting repositories and Campfire for chat, this is a nice interface that lets you get more out of your Jenkins.

The other thing I like here is that Janky pretty much requires you to run all the services “on the cloud”, because they need to talk to each other via HTTP calls. This makes it a great fit with CloudBees’s DEV@cloud, the hosted Jenkins service CloudBees provide. So between GitHub as a hosted service for repositories, Campfire for a hosted service for chats, and DEV@cloud for a hosted service for Jenkins, you can start to see the power of integration between hosted services. Greater collaboration of web services is a future I can believe in!

And if you like the idea of GitHub + Jenkins but you don’t do Campfire, you might find the Jenkins GitHub plugin useful. This plugin lets you set up a push-based build triggering from your GitHub project with a single checkbox.

Finally, as an icing on the cake, they got this nice thing to say about Jenkins:

The power, vast amount of plugins and large community of the popular CI server all wrapped up in a great experience.

One more validation to the great momentum of the Jenkins project. Yay!

Congrats to the GitHub guys for the launch of Janky!