3 ms·

Yep, brutal cold-hearted darwinism. Authored a popular project and haven't felt like working on it for 6 months? No worries, somebody will fork it and take ov

Yep, brutal cold-hearted darwinism. Authored a popular project and haven't felt like working on it for 6 months? No worries, somebody will fork it and take over the development. Or create something better. It baffles me how hurt some people get because they had an issue closed without a resolution or a PR rejected because it was out of scope of the project's roadmap. In the bigger picture, projects that don't aggressively maintain high standards of quality AND continue to improve are as good as disposable.

bluejekyll 11y ago
You ignore the cost savings in terms of project build and testing that you lose by going your own. Though, if more people adopted a fork and build your own, we'd probably have more people involved in open source. Then again, Darwinism really has a group that progresses together, not lots of little forks of individual development. You need some form of merging things back together at some point, otherwise you end up with tons of incompatible derivations of the project.
- EvanPlaice 11y ago
  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.

bluejekyll 11y ago

You ignore the cost savings in terms of project build and testing that you lose by going your own. Though, if more people adopted a fork and build your own, we'd probably have more people involved in open source. Then again, Darwinism really has a group that progresses together, not lots of little forks of individual development. You need some form of merging things back together at some point, otherwise you end up with tons of incompatible derivations of the project.

EvanPlaice 11y ago
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.