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

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?

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

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.

share|improve this answer

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.

share|improve this answer

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. :)

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.