24 ms·

Fragmentation can severely negatively impact a project as well. LLVM exists because no amount of contribution to GCC will accomplish LLVM's goals (licensing an

Fragmentation can severely negatively impact a project as well. LLVM exists because no amount of contribution to GCC will accomplish LLVM's goals (licensing and modular design).

madez 11y ago
> Fragmentation can severely negatively impact a project as well. Natural selection. The losers die so the winners can take up more ressources. That'd be a contribution to the shared goal. > LLVM exists because no amount of contribution to GCC will accomplish LLVM's goals (licensing and modular design). The reason why the competition exists doesn't matter. But the competetive pressure that results from its existence does.
- CyberShadow 11y ago
  In real life, it doesn't work that way. Imagine there is an open-source project. Its development is active, many people are contributing patches, all is well. Then, the maintainer disappears. Forks start to appear, but as there is no centralized development any more, all you can find is a dozen forked GitHub repositories, each with a few improvements - but, without getting your hands dirty, you have to choose only one. Eventually, someone comes along and rallies together the forks and revives the project. You may think that all is well again, but suddenly the original project maintainers return and continue development in a direction incompatible with the main fork. Neither project's leaders show interest in uniting the forks back together. What's worse, now you have a bunch of other open-source projects that depend on the original version, and a bunch which depend on the fork. In many cases (e.g. libraries) you can't use both the original and the fork simultaneously, meaning you can't use any components that depend on both forks in the same project. And now you have a huge mess on your hands. This or similar situations have happened many times before. I can name 3 projects that have suffered this fate off the top of my head, projects that I've been personally involved with. Fragmentation is bad. Forking should be a last resort.
  - em3rgent0rdr 11y ago
    Could you name these 3 projects?
- mlinksva 11y ago
  I almost completely agree with CyberShadow, though the problem with fragmentation isn't only caused by forks...my rant on this http://gondwanaland.com/mlog/2013/10/22/open-source-proliferation-problem/ http://gondwanaland.com/mlog/2013/10/22/open-source-prolifer... But fragmentation is going to happen and occasionally something really better comes along that wouldn't have from improving existing things. So I'm just as interested in making 'natural selection' work better. Now, it's extremely hard for it to operate, because it's hard to discern differences among similar projects, let alone which is better. Popularity data might help a little bit.

Fragmentation can severely negatively impact a project as well. LLVM exists because no amount of contribution to GCC will accomplish LLVM's goals (licensing and modular design).

madez 11y ago

> Fragmentation can severely negatively impact a project as well. Natural selection. The losers die so the winners can take up more ressources. That'd be a contribution to the shared goal. > LLVM exists because no amount of contribution to GCC will accomplish LLVM's goals (licensing and modular design). The reason why the competition exists doesn't matter. But the competetive pressure that results from its existence does.

CyberShadow 11y ago
In real life, it doesn't work that way. Imagine there is an open-source project. Its development is active, many people are contributing patches, all is well. Then, the maintainer disappears. Forks start to appear, but as there is no centralized development any more, all you can find is a dozen forked GitHub repositories, each with a few improvements - but, without getting your hands dirty, you have to choose only one. Eventually, someone comes along and rallies together the forks and revives the project. You may think that all is well again, but suddenly the original project maintainers return and continue development in a direction incompatible with the main fork. Neither project's leaders show interest in uniting the forks back together. What's worse, now you have a bunch of other open-source projects that depend on the original version, and a bunch which depend on the fork. In many cases (e.g. libraries) you can't use both the original and the fork simultaneously, meaning you can't use any components that depend on both forks in the same project. And now you have a huge mess on your hands. This or similar situations have happened many times before. I can name 3 projects that have suffered this fate off the top of my head, projects that I've been personally involved with. Fragmentation is bad. Forking should be a last resort.
- em3rgent0rdr 11y ago
  Could you name these 3 projects?
mlinksva 11y ago
I almost completely agree with CyberShadow, though the problem with fragmentation isn't only caused by forks...my rant on this http://gondwanaland.com/mlog/2013/10/22/open-source-proliferation-problem/ http://gondwanaland.com/mlog/2013/10/22/open-source-prolifer... But fragmentation is going to happen and occasionally something really better comes along that wouldn't have from improving existing things. So I'm just as interested in making 'natural selection' work better. Now, it's extremely hard for it to operate, because it's hard to discern differences among similar projects, let alone which is better. Popularity data might help a little bit.