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.<p>What you are seeing is both an explosion in contributions and a permanent log of every failed contribution ever. This greatly affects your perception.<p>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.<p>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.<p>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.<p>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.
As someone who has dealt with this, it's not as big a deal as you might think. Most future forks are based on older forks, so all the person at the end of the line has to do is fast forward onto the end of the branch. One FF merge, push, end of story.<p>When you have bifurcations, you can do an octopus merge - git is <i>really</i> good at resolving these things. Very little human effort is needed except where multiple revisions change the exact same line in different ways.<p>In addition to this, most patches that people submit are quite small. Even if you have 200 people submitting patches, the odds are that most of them fall into two categories: people fixing the same bug, and people working on completely different sections of code. Neither is a substantial problem to merge.<p>I think I can count on one hand the number of times I had to do any nontrivial merge work on patches from contributors... And you're pretty delighted to do it - it means they fixed something that <i>really</i> matters.
It's not that hard to do this:<p><pre><code> git remote add other_user_who_forked git://github.com/other_user_who_forked/project_name.git
</code></pre>
from within your checkout of your fork. In one of the projects on GitHub that I've forked, we are merging between each other without the original project owner even being involved.
I don't get it.<p><i>If A disappears with merges pending … then B/C/D find they have 3 distinct codebases, and no way within GitHub to do a simple cross-merge.<p>Now, the situation is not lost – if B, C, and D get in contact (somehow) and negotiate which one of them is going to become “the primary SubAuthor” (somehow), and they issue manual patches to each other’s code (surprisingly tricky to do on GitHub)...</i><p>If B, C and D get in contact via, I dunno, github messages, and pick a primary subauthor, it's very easy to issue manual patches. If I'm B:<p><pre><code> git remote add C ...
git remote add D ...
git pull C master
git push github master
</code></pre>
I agree github might not have a button for this, but I'm pretty sure most github users are comfortable with the git command line.
I really did feel the same way as the author for a long time, but I haven't yet seen any of my fears manifest in practice. The vast majority of forks die without fanfare after serving some singular purpose. People who want to contribute code do so more easily than ever. People who fight over ownership of open source projects are just jerks like they've always been. There may be more of them, or more of them are more visible now that we all use Github, but I consider this a trivial downside of an otherwise remarkable ecosystem.
The author has this completely backward: this is fundamentally a social problem - the difference is that with GitHub it's actually visible. Anyone old enough to remember the pre-DVCS era should remember chasing down patches in bug trackers, blog posts, etc. and maintaining local forks — with the requisite terror-inducing periodic gigantic merges. Now we've lost all of the manual labor in that process and made it easy for anyone who wants to do things the right way to do so – it's still possible to waste your collaborators' time if you really want to but before it was almost a requirement of the process.<p>As a minor point of craft, this also illustrates an area where more training is needed: the problems described are most common when someone makes a fork and keeps every single commit in a single branch. Using feature branches – and it'd be awesome if Github started encouraging that with the fork & edit model – makes most of the listed problems far more manageable.
When you hear Linus speak about his workflow when working on the kernel, he always mentions his "Web of Trust" concept. I think the problem is not inherent to github, but rather to the idea we have when we foolishly think of the possibilities combining git and a social network.<p>The truth is, programming is still very much about people, and you need to trust the people in order to pull their code. Trusting the people goes beyond trusting the code. If you give me great code, then disappear or decide to make an unmergeable fork, it will harm my project as described in the article.<p>On the other hand, if I get to know the people behind the pull requests, learn to talk to them and get them to be more involved in the project, then the risks exposed can be easily circumvented.
Actually, if you fork from the main branch, you can still pull commits from other collaborators--though I don't know if you can send pull requests to other people, haven't tried. But it is doable. There is nothing to stop you from making another remote branch that tracks another person's repo and share code that way.
I don't agree that GitHub is killing open source. However, the author has a point. It is hard(er) to merge into other forks, which is a shame since git is so good at this.<p>I'm not critising GitHub, their software is great, but in the next iteration, they should consider addressing this.
Most Open Source projects die. That's why CPAN, PyPi etc. are able to have such a huge number of packages, a significant part, if not most, has no documentation, tests, support or is dead all of which in practice is more or less the same.<p>"In the old days" you didn't notice it as much because those projects just disappeared but with Github they don't, in fact they're all over the place.<p>I'm not sure if this is a problem or one big enough worth caring about but in any case Github isn't the problem.<p>It would be nice if authors could "archive" or "abandon" repositories which could be filtered out on searches by default and be displayed less dominantly on profiles.
To be fair, the usual consequence for a project that loses its Author is to die.<p>It seems that github could facilitate the migration of an "ownerless" project to a designated fork - including facilitating the selection of who has the designated fork. Just support for the informal process outlined in the submission.<p>It's interesting that linus deliberately avoided having a "designated fork" in git, but instead made them all equal, and you just pull from who you trust. Of course, in his case. <i>his</i> fork was the socially designated one, so this was not a problem he experienced or had to solve.
The commit graph (gitk --all if you are using plain decentralised git, GiHub's network graph for the convenient everyone-github-knows online version) makes it quite obvious which author is good at reviewing and integrating patches. With a little bit of side-channel communication, a deficient maintainer is easy to replace.<p>Also, someone who is late at merging patches won't have a lot of difficulty catching up. If they did no divergent work at all, it's just a matter of picking the best integrator and fast-forwarding.
I don't think projects faltering out due to the bus factor [1] not being taken into account is github's fault.<p>set up a team repository and give multiple people commit access? Team/project accounts should probably be more of a standard feature of open source projects on github, once things get beyond a certain point.<p>[1] <a href="http://en.wikipedia.org/wiki/Bus_factor" rel="nofollow">http://en.wikipedia.org/wiki/Bus_factor</a>
Wow, no offense dude but this was a really crappy post.
This problem have existed for all eternity, just as other people are stating: There are a lot more projects, people who contribute and transparency of those than before.<p>And choosing that title. It just seems you are writing one of those. "Look at me! I am writing something controversial"-articles
I think the author is missing something that makes Open Source work that few people appreciate. It's a fundamentally lossy development model. A certain number of patches/features end up in /dev/null for any Open Source project.<p>You can think of each "fork" as a new start-up trying out a new idea. But instead of reinventing the entire world, they get to start with a functioning product. The vast majority of these start-ups will fail but the ability to experiment (and fail) with forking is fundamentally what makes Open Source development better (at least IMHO) than proprietary development.<p>A lot of people look toward Open Source development thinking that there's a lot of wasted development and that that's a problem worth solving, but that's like the government trying to make 100% of businesses successful.
This has nothing to do with github. Github is what it is as the name suggests, it's a convenient hosting platform for git projects. The fix/merge issues are between developers and has been around since open source first started. It's people issues, not github.
Here is a question:<p>How do you handle merging someone else patch into your dual-licensed project?<p>The GitHub hosted code is GPL, but your other code license is for commercial projects (you charge a fee for the NON-GPL license).<p>Obviously, the patch is based on the GPL project, but you don't have copyright on that patch (to be able to merge it into the non-GPL codebase).<p>Do you ask the contributer to give you the copyright?<p>What if it's a simple bug fix that's only a few characters?<p>What if the contributer says no?<p>Is there a way to make this happen smoothly?
This reminds me of the famous Churchill quote: "It has been said that democracy is the worst form of government except all the others that have been tried."<p>Most of the article is true, but GitHub is also leagues above anything else out there, and certainly leagues above the mailing list with hand-crafted patches by de-demonizing forks and turning projects more into a meritocracy.<p>There is certainly room for improvement, but I think it's a step in the right direction.
The very fact that both forks are available on github means that you can check out both forks, then merge changes locally. After that, you can use the merged code to create a new github project that is not a github fork of the original ones.<p>If you really have a tangled web of failed forks, this is the way to fix it by starting afresh with a merger of the best forks.
What would go a long way towards fixing this is having an organization plan that's free, but only allows public repositories. That way the code could be entrusted to more than a single individual as it is now. Commit rights are one thing, but having ultimate control over the repository is usually limited to one person.
I fail to see a better alternative unfortunately.<p>The only way that you can stop this is by having multiple maintainers for a project so that projects don't just die if the main maintainer is hit by a bus.<p>And yes, this crappy, albeit well known situation is not just specific to Github.
Was this written (conceived) before the new pull requests mech & UI was introduced?<p>How can the dead end of an ignored patch submission be better than what we have now?
reading that makes me wonder how open source projects existed at all <i>before</i> GitHub...<p>GitHub exposes the once private forks that people had lying around on their HDDs, so I count that as a plus.<p>As for developing open source in a collaborative way, that goes much further than just a git infrastructure, there's mailing lists, patch reviews, roadmap discussion etc... exactly like in ye olde days
google cache: <a href="http://webcache.googleusercontent.com/search?q=cache:http://t-machine.org/index.php/2012/01/13/2012-the-year-of-uncollaborative-development-or-when-github-kills-open-source/&strip=1" rel="nofollow">http://webcache.googleusercontent.com/search?q=cache:http://...</a>
What does this have to do with git_hub_? Isn't this a "problem" with git?<p>I don't think it is a problem at all because without git (or hg, bazaar etc.) or github we wouldn't even have such a thriving open source and open development community. Collaboration didn't get harder with DVCS it got easier.