3 ms·
> 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 wil
by lloeki 15y ago
> 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.
- yummyfajitas 15y agoIndeed. Here is one of my forks: https://github.com/stucchio/django-tyrant-cache 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.
- lloeki 15y agoBesides, 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.