5 ms·

No. Open source should be more like Darwinism. If you want to make a change, you fork the code. If the creator(s) likes your changes, they incorporate it. I

by Mikeb85 11y ago

No. Open source should be more like Darwinism. If you want to make a change, you fork the code. If the creator(s) likes your changes, they incorporate it. If a code base is good, it survives, if it isn't it dies. The key point is freedom - your freedom to do whatever you like with the code, and the creators freedom to do what they like.

EvanPlaice 11y ago
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.
simonh 11y ago
Or the freedom to come to the conclusion that someone else's vision is worth supporting, and choosing to devote time and effort to helping them realise it. "Seek freedom and become captive of your desires. Seek discipline and find your liberty." ― Frank Herbert, Chapterhouse: Dune
- Mikeb85 11y ago
  Yeah I have no issue with project managers/creators choosing a democratic process. Just issues with users who demand it...
kirillzubovsky 11y ago
Except the initial selection is done by an individual, which leads to a high chance of negative outcomes, since good ideas could be denied and bad ones accepted. Due to the pile-on nature of open source, good code could be killed early on and the contributor not survive long enough for it to included into later editions.
softmodeling 11y ago
The problem is that only tech-savy users have this freedom. Sure, non technical users should not decide on core technical decisions but they should still be able to steer the evolution of the project (e.g. deciding what features to implement next)

by Mikeb85 11y ago

EvanPlaice 11y ago

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.

simonh 11y ago

Or the freedom to come to the conclusion that someone else's vision is worth supporting, and choosing to devote time and effort to helping them realise it. "Seek freedom and become captive of your desires. Seek discipline and find your liberty." ― Frank Herbert, Chapterhouse: Dune

Mikeb85 11y ago
Yeah I have no issue with project managers/creators choosing a democratic process. Just issues with users who demand it...

kirillzubovsky 11y ago

Except the initial selection is done by an individual, which leads to a high chance of negative outcomes, since good ideas could be denied and bad ones accepted. Due to the pile-on nature of open source, good code could be killed early on and the contributor not survive long enough for it to included into later editions.

softmodeling 11y ago

The problem is that only tech-savy users have this freedom. Sure, non technical users should not decide on core technical decisions but they should still be able to steer the evolution of the project (e.g. deciding what features to implement next)