Here is the scenario:

X is the author of a software. X releases v1.0 on an open source license on Github and moves on. People interested in the software fork and improve the software. Now there are 15 different flavours of the software. Few also try to send a pull request back, however since X no longer works on the software, the pull request is just sitting idle on his project page.

As a new user wanting to use the most active and stable release of the software, how does he learn which out of the 15 he should clone and use? He certainly would like to use the more active branch, since it may have more bug fixes and features upgrades.

I see that the model works for bigger open-source projects, because the author of the software is usually well-known in the community. As a result, the user base inadvertently knows which branch to clone from. However, how does one solve a problem for a software, where the author, maintainer and several contributors all are practically unknown in the open-source community?

  • 3
    That scenario is older than and independent from any DVCS. It's how Apache came to be IIRC. – user7043 Apr 22 '13 at 18:41
  • @delnan Sendmail too. – Ross Patterson Apr 22 '13 at 22:25

At the risk of sounding tautological, if you want an active branch with bug fixes and feature upgrades, choose the branch with the most recent activity, bug fixes, and feature upgrades. The revision history is available to you. It might be time consuming to check it for 15 branches, but it's not unreasonable.

Once you've determined who is the most active maintainer, you can see if he's willing to make it official, and talk to the others to see if they agree. If they're not making wildly divergent changes, it shouldn't be difficult to find common ground.


This is a serious and not fully solved problem. You only have to look at the state of RubyGems to see how bad it can be (with multiple gems that have the same name, divergent versioning schemes, and incompatible APIs).

At the end of the day, if you want to have a community build and maintain a piece of high quality software, I think it is almost always necessary to have a single "blessed" repository with maintainer(s) that do releases.

The distributed development is still key because it lets people experiment on their own copy and later merge changes back in to the slower and more stable mainline.


As noted, this remains a problem.

I consider the following to determine viability:

  1. Recent activity on the project.
  2. Amount of activity on project.
  3. If there is an identifiable owner of project.
  4. Who else/what other projects is using the project.
  5. Release history of project.

Determining suitability of a fork/application is non-trivial, no matter what type of software. Generally I'd look at:

  1. Of other people using it to solve the same/similar problems you have.

Or, you can ask on stackexchange/stackoverflow. :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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