4 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 will

by pilif 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. What you are seeing is both an explosion in contributions and a permanent log of every failed contribution ever. This greatly affects your perception. Back in the old days it was infinitely harder to provide and apply a useful patch, so it wasn't done in nearly the same frequency. Contributions were limited to a small circle of people motivated and skilled enough to climb the huge hurdle. Nowadays, creating and submitting a patch is trivial, so the hurdle is much smaller. Hence you will get many, many more people to try and contribute, which, because of how github works is also visible to the public for all eternity. At least in my case, none of my patches I sent in in the old days and which were not accepted are visible anywhere. Heck, most of the time you'd have a really hard time at even finding the patches that were accepted. Github is far from killing open source. Quite to the contrary. But as visibility increases and hurdles get torn down, you might have to adjust your perception of reality.

turbulence 15y ago
I think you have to read the article again, because you are talking about something quite different.
- pilif 15y ago
  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?
- tingletech 15y ago
  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?
AdrianRossouw 15y ago
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.
lmm 15y ago
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)
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 ago
  Indeed. 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 ago
    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.

by pilif 15y ago

turbulence 15y ago

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

pilif 15y ago
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?
tingletech 15y ago
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?

AdrianRossouw 15y ago

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.

lmm 15y ago

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)

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 ago
Indeed. 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 ago
  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.