3 ms·

But in all likelihood, most forks will be worse along all axes because they have less development put into them.

by chc 12y ago

jerf 12y ago
You can't assume that development is going to go into the original fork when your core developer set is unhappy enough to create the second fork in the first place. If some hypothetical third party could mandate that no fork took place, you may very well find in your alternate universe that the development effort you are expressing fear may be split may simply go nowhere at all. You can not simply take it as a given that the developers are simply "stuck" with the original fork and if unable to do their own fork would simply contribute to the original.
- chc 12y ago
  No, I can't assume that — and I didn't. I didn't say anything remotely like that. I was responding to a comment which said, essentially, that you will end up with lots of forks that are each strong in some particular way. This is not generally how it works in my experience. In general, the fork with (for example) better ease of use will also be the one with better speed because it will get much more time and attention than other forks.
  - pixl97 12y ago
    I'm pretty sure you didn't read my comment at all, "Most will die off" was there for a reason. Also, don't confuse a fork dying off with it becoming something completely different.
    - chc 12y ago
      I'm sorry if I gave that impression, but just because I didn't respond to those four particular words doesn't mean I didn't read your post at all. I have to believe "These variants can fill various niches, such as security, speed, or ease of use" and "many will succeed" were also there for a reason, and those are what I was responding to. My point is that for most projects, you don't end up with a bunch of viable forks. It's rare even to end up with two viable public forks, much less several. It's not much like sexual reproduction because sexual reproduction requires there to be multiple breeding entities.

But in all likelihood, most forks will be worse along all axes because they have less development put into them.

by chc 12y ago

But in all likelihood, most forks will be worse along all axes because they have less development put into them.

jerf 12y ago

You can't assume that development is going to go into the original fork when your core developer set is unhappy enough to create the second fork in the first place. If some hypothetical third party could mandate that no fork took place, you may very well find in your alternate universe that the development effort you are expressing fear may be split may simply go nowhere at all. You can not simply take it as a given that the developers are simply "stuck" with the original fork and if unable to do their own fork would simply contribute to the original.

chc 12y ago
No, I can't assume that — and I didn't. I didn't say anything remotely like that. I was responding to a comment which said, essentially, that you will end up with lots of forks that are each strong in some particular way. This is not generally how it works in my experience. In general, the fork with (for example) better ease of use will also be the one with better speed because it will get much more time and attention than other forks.
- pixl97 12y ago
  I'm pretty sure you didn't read my comment at all, "Most will die off" was there for a reason. Also, don't confuse a fork dying off with it becoming something completely different.
  - chc 12y ago
    I'm sorry if I gave that impression, but just because I didn't respond to those four particular words doesn't mean I didn't read your post at all. I have to believe "These variants can fill various niches, such as security, speed, or ease of use" and "many will succeed" were also there for a reason, and those are what I was responding to. My point is that for most projects, you don't end up with a bunch of viable forks. It's rare even to end up with two viable public forks, much less several. It's not much like sexual reproduction because sexual reproduction requires there to be multiple breeding entities.