Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Say I find this great snippet of code on Bitbucket. I really, really like it but there's a small bug I want to fix. On the other hand, I have all of my code on GitHub.

Is it ok to start a new repo on Github and refer to the original by a comment or on the wiki?

share|improve this question
up vote 12 down vote accepted

The most ethical, from any point of view, would be to tell the author about the bug and eventually propse him/her the fix. Making a fork as you call it is nothing more than duplication and duplication in code should be avoided by all means. You could even call it a violation of the DRY principle.

share|improve this answer
What you are not considering is that this is normal practice when working with distributed version control. Where the "old" practice was to fix the bug in your local checkout, and then send a patch to the original developer. Then today you just fork the project (which is basically the same as a branch, and merges back just as easily). Fix the bug, publish your fork, and then sends a request to the original developer asking him to pull you changes in. The tools (git/hg) all supports this in a very simple fashion, and I would not call it a violation of DRY or even code duplication at all. – Bjarke Freund-Hansen Sep 2 '11 at 11:52
@bjarkef That is not what stjin is talking about in my mind. It can be pulled back in relatively easy if the fork was on bitbucket, and that is how bug fixes are done (as you said). However if it is on Git instead that means that the it can't easily be pulled in, and is now more of a new project than just a fork. – Rangoric Sep 2 '11 at 12:23
@bjarkef while you're completely right saying that a branch/fork as you state is is not duplication, forking to a different DVCS is something completely different. Yeah sure you can get it back into the original repo, but in the end there are two distinct repositories that have no link to each other except they have the same code in them. That is duplication imo. – stijn Sep 2 '11 at 12:26
@Rangoric: Ah, so the question is actually about forking/cloning a mercurial repository to a git repository. But my comment is still the same, a fork is basically just a clone or branch. In this case you will just have to pack up your changes and submit them to the original developer yourself. (Or use some kind of hg-git/git-hg bridge.) – Bjarke Freund-Hansen Sep 2 '11 at 12:28
@stijn: Good point about a clone from hg to git (and vice versa) is more of a duplicate than a clone. – Bjarke Freund-Hansen Sep 2 '11 at 12:29

You can maintain you fork wherever you want. But it is polite to pass bug fixes back to the original project, even if that means a little extra work on your part to jump through their project's hoops.

share|improve this answer

If the author is no longer maintaining the source, or will take too long to fix the issue then there's no problem. The whole (theoretical) point of the source being available is to be able to change it.

From a technical point of view moving from Bitbucket to Github isn't an issue as there's a fairly stable bridging tool between the two now. With Mercurial you easily shift between Codeplex, Bitbucket, Google Code and then push to Github via the bridge.

If it was my project I would be happy to see someone fork it, as so many open source projects are simply leeched with nothing given back. It would be polite to tell the author about the bug, and provide a patch for it.

share|improve this answer

Create an account on bitbucket, fork the project, patch it, and send a pull request to the author when the bug is fixed?

share|improve this answer

yes, it's ethical. That's why it's called "open source" (if not, then of course it would be illegal ...)

share|improve this answer
-1. You've implied that legality is equivalent to ethics. Something can be legal but, arguably, unethical. – Megan Walker Sep 2 '11 at 14:25
... yes, officer :) – Raffael Sep 2 '11 at 14:31
Nope, I am pretty sure it is both legal and ethical. There is not some moral obligation to reduce the number of repos in the world. – RKitty Sep 2 '11 at 17:37
I didn't say in this case it isn't both legal and ethical; I was speaking of the general case - they way it was phrased to me was implying that if something is legal then it is always ethical. – Megan Walker Sep 2 '11 at 18:02
it's the creator who chose the license, so in this case legal very well means ethical as well. – Raffael Sep 2 '11 at 18:58

Fork it. It's open source and it's broke. Don't say you wrote it, just reference the original author.

share|improve this answer

Check the license. Different open source license have different requirements about what kind of changes must be contributed back to the origin.

While there are a lot of cases where an author picks a license out of ignorance, most of the time, the license that author picks reflects the author's ethical position.

Most open source license are written in a manner that is technology-agnostic, forking to a different code host or DVCS would not be considered distinct than forking to the same code host and DVCS. It is a feature of many open source license which allows forkers to use whatever technology they see fit for their own purpose as long as the requirements of the license is fulfilled.

Forking to a different technology does add a layer of difficulty for contributing back, so that should be part of your consideration whether it's worth it to fork to another technology. These technical difficulties are now lessened since there are now very stable and high quality bridging between Mercurial and Git.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.