You're correct. I wasn't implying starting from scratch. Rather fork and continue where the upstream project left off as long as there are no hard license rest

You're correct. I wasn't implying starting from scratch. Rather fork and continue where the upstream project left off as long as there are no hard license restrictions. Sometimes, a merge never happens due to neglect or the unwillingness of the maintainer to cede control and grant push access. One specific project I've used that follows this pattern is NodeFTPd. It's a ftp server written in node. I use it to run functional tests on my node-ftpsync project because mock ftp servers don't exist for JS. It is now 4 layers of forks deep since I started using it. Each added considerable improvements on top of the previous fork. It's one of those dependencies where I'll make the extra effort to check the network graph before updating to see if any of the derivatives are approaching or have surpassing the fork I'm current using in popularity. Apparently, a FTP server is an extremely valuable application despite many devs failed efforts to manage the project over the long-term. The real issue is central repositories like NPM/Bower. I had one dev fork a project of mine to host on GitHub because it was on Google Code at the time. He then registered his copy on Bower before I had a chance to. So now, not only is it hosting an outdated copy but I physically don't have access to update it. For all the dev's huffing and puffing about how he was going to take over the project in my absence He made approximately 3 minor commits (which I later merged) and disappeared from the face of the earth.