Oh man, when I first started regularly contributing to open source, I had to make a patch and manually increment the numeric prefix when i committed it to a public cvs repository's patches directory.

Then I had to write an email to let people know about it.

That was followed by posting patches as attachments to issues on an issue queue, with no version control net on my side, unless you count committing CVS repositories into subversion.

OP just isn't aware of all the failed forks/patches because they were never as readily available and easy to merge before.

> For every contributor to an open source project in the old days, there might be fifty failed forks on github, sure. But for every five failed forks, there will be one that thrives and which commits get accepted back.

Define "failed fork". GitHub&al, propelled by decentralized VCSs, definitely changed the meaning of 'fork'. Previously, creating a fork was a serious act, taken only when you did not have access to the central repository and had to do modifications, or when a given project was going nowhere anymore, or not where or how you wanted. A fork was either a rebirth or a schism.

But that changed.

A fork is now part of the global workflow. One forks and submits a pull request almost like one would checkout, diff and mail a patch previously. The definition of a 'failed fork' is therefore wildly different since the very notion of fork evolved dramatically. Forks never submitting pull requests have their own use so you can't even qualify a fork based on that.

Indeed. Here is one of my forks:

https://github.com/stucchio/django-tyrant-cache

It's the standard tokyo tyrant cache backend for django with a bugfix (it reconnects if the connection dies). The pull request was made in august last year, and I've heard nothing back. Oh well.

On the other hand, my connections to tokyo tyrant don't crap out, and I've got a nice permalinked submodule in my main project. (Or I did before I switched to redis.)

Is this a failed fork? By the definition of the author, sure. But it's made me happy. And if someone else needs this bugfix, it will probably make them happy too.

Besides, it makes upgrading your variant much easier, since you're tracking a remote and can easily (and more often than not, trivially) fetch from then merge with/rebase on it.

In Ye Olde Days at least the main repository was something you visibly had to maintain. The original author A would set up a project on sourceforge, and add B, C and D with commit access. (Indeed, I remember this being cited as one of the great advantages of git - it breaks down the two-tier society where you had an inner circle of authorized committers, and then second-class citizens who had to submit their patches). But it did mean you would do succession planning around it - if A got hit by a bus, someone else would have access to the One True Repository, and they could take over merging patches from outside contributors.

Ironically, github is making it easier to have a single central point of failure. Because it's so easy for the original author to merge patches from other repositories, there's no longer any pressure to give other people access to the "master" repository. Which is fine until the original author stops doing it (for whatever reason)

I think you have to read the article again, because you are talking about something quite different.

Not necessarily. If a project doesn't merge a proposed patch, the patch could simply be deemed inappropriate for the projects chosen direction.

So if a fork doesn't get merged upstream, I see this as a failed fork.

If a upstream stops working on their project and stops accepting patches, the outlined problems can happen, but just look at any random sourceforge project not updated since 2006. In the old days, there was practically no way for other contributors to get back on track, but it wasn't logged for eternity either - the project just died.

Today, Github at least provides a chance to get back on track, but, again, your perception might be altered by the fact that on Github you don't just see the successful reboots, but also all the failed ones?

humm, the way I read it, the post you are replying to is speaking to the same issue as the article (proliferation of forks). What issue do you think it the article is ranting about?