Aside from the foster collaboration side of the issue, from a business perspective it will enhance and strengthen GitHub’s traffic, user base and market position. So there is a little bit of a business strategy associated with it too.

Personally I don’t mind this because GitHub provides a valuable service to the open source community.

Is it meant to show that this is a collaborative project – you’re welcome to add improvements?

Yes: you don’t have the right to push a commit directly at their repo.
But you do have the possibility to fork their repo, which makes it your repo, and push commit from there, preparing pull requests.

The “Fork me on Github” badge is meant to show that it the project you are granted the right to contribute to the project or use it as a starting point for your own project.

It kinda shows that “it’s a collaborative project and that you’re welcome to add improvements.”

It allows you to play around with the code or make a spin-off of the same project without affecting the original source.

https://help.github.com/articles/fork-a-repo

The same principle applies to all other git hosts.

The main points (among many other) of giving the right to fork a project is to

• foster collaboration – by allowing people to work together in improving the project.
• add to knowledge – by allowing people to study your code.

Some of the projects you may have encounters may be by Github staff for their own private needs. They do not want to promote github. You can find projects by github here : https://github.com/github

As to why you’re not seeing badges from other hosts is because Github is the most popular git hosting and collaboration platform.

Imagine you use your favorite text editor, and after some time you find that you would really love some feature to be implemented (like non-blocking Save file option).

After thinking that for the eleventh time you decide to write one by yourself. After you find the github page of this project you have two options:

1. Download the source code, modify it and keep it for yourself.
2. Fork the project on a github and work on your fork.

If you chose the second option, after making your feature well-written and well-tested, you could prepare pull request and then the entire project would benefit from you.

However, if you chose the first path, it is very likely that you will just forget about your modification and nobody except you will benefit from it (yes, you may share the code manually, but some other coder could easily forget that. Using github is forcing you to get more socialized with the other’s work).

Saying ‘fork me on a github’ project’s owner just want to make sure that you chose the Fork on github instead downloading the code and publishing it into your home directory.

It’s only there to show that this is an open source project and you fork it if you want to, whatever the reason.
Also, check out this blog post on GitHub: https://github.com/blog/273-github-ribbons

Update: Personally, I add these GitHub ribbons so people can find me on GitHub and star my projects 😉

It means they’re on github, where forking is cheap, and they want to encourage contributions to improve their software and community.

Github is trying to widen their userbase to include any collaborative work, not only source code hosting; and thus do they push the fork and send a pull request method. Making patches and sending them via email wouldn’t be attractive to most people other than programmers and alike. Push permissions are not really important here, as eventually most of the git (or mercurial, darcs, or whatever) users with considerable amount of knowledge of the tool and development workflow would be able to send an email with a patch attached somehow.

Also, Github is more about social networking than code hosting: your profile, repos and changes make up your identity as a software developer, just like your tweets and ‘+1’s. All those ribbons and buttons and alike are used as a means of self-canvassing, a path to the profile of the person whom the project belongs to. Nowadays, having a decent Github profile is the first thing expected from a developer. Even though I use mercurial for anything, I push to Github via hg-git for these reasons.

Eventually, that “Fork me on Github” ribbon differs just slightly in purpose from the “Tweet this Article” or the “Share this Thing on G+” button. (Also having a fork of a repository on your list of repos means “I am a user of this thing”, there are thousands of forks of Linux on github, even though Linus Torvalds does not accept pull requests.)

it’s another way to say “patches are welcome”.

instead of sending wishes and feature requests, people can send pull request where the original author review, validate and merge the pull request.

historically forking is a hostile action done by group that is in conflict with the management of the original project, for example Sun’s OpenOffice used to reject fast C/C++ SVG plugin because it prefers its own slow broken Java-based plugin for political reasons.

In most cases forks are bad, and carried by envy people or people from selfish companies who have plans that do that is not shared with the original community and is not in align with it (ex. Canonical) and example of this is libav/avconv (which is a fork of FFMPEG), in those cases the original community have higher quality, security, and they welcome patches that is aligned with community plans.

Dan Walsh noted the old definition of fork

I have been in open source for a long time, and my definition of a
“fork” might be dated. I think of a “fork” as a hostile action taken
by one group to get others to use and contribute to their version of
an upstream project and ignore the “original” version. For example,
LibreOffice forking off of OpenOffice or going way back Xorg forking
off of Xfree86.

Then he compared that with github’s fork

Nowadays, GitHub has changed the meaning. When a software repository
exists on GitHub or a similar platform, everyone who wants to
contribute has to hit the “fork” button, and start building their
patches. As of this writing, Docker on GitHub has 9,860 forks,
including ours. By this definition, however, all packages that
distributions ship that include patches are forks. Red Hat ships the
Linux Kernel, and I have not heard this referred to as a fork. But it
would be considered a “fork” if you’re considering any upstream
project shipped with patches a fork.

All the responses saying that this is collaborative beg the question: why not say “Clone me on GitHib” or “Download .zip from GitHub”?

On GitHub you can see a count of the number of forks. But, to my knowledge, not a count of the number of clones or zip downloads.

So, I’d say it is partly to encourage collaboration, partly to get feedback and validation that people are using your code.

P.S. I’m fairly new to GitHub so if this is totally wrong of off base kindly let me know.

forking on github makes it sound really easy to say like follow me on twitter. I
t brings a little socialization into the world of development from my own perspe
ctive also making it obvious that is open source and available for modifications
.I also think it’s a nice concept with the “fork me on github” banner on one end
of your project website

You’re probably best off just taking the simplest answer: they want you to know the code is freely available on GitHub. I think your hypotheses are a bit overthought.