4 ms·

Forks of a large project seldom survive, they almost always die with no active development. This is a futile move.

dijit 3y ago
There's plenty of precedent that states forks die, however to describe it as entirely futile is: A) Not exactly constructive. B) Possibly untrue. The move might indeed die, if the rust foundations leadership gets it's act together. Which is a strong push for them to sort things out rather than assuming everything will be fine with their current heavy handed and opaque approach. Failing this, we could be in a situation with another Rocky linux, FlatCar linux or LibreOffice ;) (examples of successful forks)
- oefrha 3y ago
  In the examples you gave, either the original project shifted course significantly, or there are major technical disagreements. Here, pointless trademark drama is all there is, and the fork AFAICT replaced some strings and nothing else.
  - dijit 3y ago
    libera.chat
    - oefrha 3y ago
      Not sure what you are trying to convey. There are a ton of IRC hosts out there and they are all interchangeable. A real language fork is not interchangeable, even a different implementation of the same language is going to have its subtle compatibility problems. People pay the price for tangible benefits like performance or portability. You don’t need to use a fork and pay the technical price for it if the only benefit is that Rust Foundation hypothetically won’t sue you for using the word “rust”; just frigging use “crab” as the moniker for “rust”.
      - dijit 3y ago
        Its an example of a wildly successful fork due to poor leadership, without any other technical reasons. You can argue that “its different because its a community” but thats dishonest, because ultimately migrating an entire community is much harder than having an alternative development stream like MariaDB and MySQL. Oh, wait, another successful fork…
        oefrha 3y ago
        IRC is practically stateless, migrating is about as easy as someone signing up at the new host and changing your readme/contact page. If you have some bots you change some URLs. It may not be an easy decision, but the migration is a straightforward one time cost. Guess why a lot of projects moved off Freenode overnight? Because it’s very easy. Supporting a different language implementation, on the other hand, is an indefinite ongoing burden until one dies. Not to mention the trademark bullshit affects a tiny slice of the user base at best.
        dijit 3y ago
        Respectfully, I couldn’t possibly disagree more. Everything you said is just as true for an alternative language. You can maintain compat (like rocky linux) or diverge (like mariadb), so it remains to be seen. However the switching cost of moving your entire community is large and IRC is not stateless, pedantically it is a stateful connection, but you really mean that theres nothing you need to carry with you; but thats not true, permissions, identities, hostmasks etc. all of these tiny things spread across thousands is quite an effort and undertaking it is only done with a heavy heart. If you maintain compatibility then it could be as easy as changing a reference or just calling another compiler (like the Java implementations). Afaik all CentOS and RHEL scripts work without modification on Rocky. Either-way, I think I made my point, I am sure you are convinced of the inverse, so I leave this as my final word to other readers of the thread.
chrisco255 3y ago
It worked for io.js when they split off from node.js. When io.js was re-merged in with node, the project was all the better for it. They ultimately improved Node's release schedule and cadence, governance, etc.
- colesantiago 3y ago
  does the io.js fork still exist? If it is merged back into the main project or left unmaintained the fork failed and died.
  - Borgz 3y ago
    You are implying that the only measure of success for a fork is for it to exist indefinitely. If the goal of io.js was to improve Node's governance model, which appears to be the case, then I would consider it a success.
    - colesantiago 3y ago
      > Forks of a large project seldom survive. The fork died. that is the point. goal or no goal.
      - rowanG077 3y ago
        It obviously didn't die. It got merged into the original project. That is a great end of a fork.
        colesantiago 3y ago
        So it didn't survive then. Isn't that the whole point of what I said: > Forks of a large project seldom survive.
        rowanG077 3y ago
        But it did survive. I can't view rejoining the forked from repository as dying.
p0w3n3d 3y ago
Just look at LibreOffice. This is a fork of OpenOffice and OpenOffice is dead (at least to me)
- colesantiago 3y ago
  OpenOffice isn't dead, they made a release a few months ago this year. https://blogs.apache.org/OOo/entry/announcing-apache-openoffice-4-110 https://blogs.apache.org/OOo/entry/announcing-apache-openoff... Last commit made 3 days ago, actively maintained. https://github.com/apache/openoffice https://github.com/apache/openoffice
  - deleted 3y ago
    [deleted]
  - yarg 3y ago
    https://itsfoss.com/libreoffice-vs-openoffice/ https://itsfoss.com/libreoffice-vs-openoffice/ > Technically, both receive regular updates. But, OpenOffice is limited to bug fixes and minor updates. > LibreOffice has more development activity, frequent bug fixes/minor updates, regular major upgrades with newer features, and improved user experience. Apache can do whatever they want here, but the project is limping at best.
  - sgt 3y ago
    So you went to github and saw commits made 3 days ago, then concluded that surely that means the project isn't dead. It is though, you're just completely missing the forest for the trees - a typical trait of programmer types.
    - colesantiago 3y ago
      It isn't though until they say it is discontinued. You also missed that OpenOffice made a new release and they were even bothered enough to make a post about it. Hardly a trait of dead software. As much as you would love to say it is dead: It officially isn't and it is still maintained.
  - 3y ago
denton-scratch 3y ago
> Forks of a large project seldom survive MariaDB? That fork was also the result of heavy-handed lawyering over IP.

There's plenty of precedent that states forks die, however to describe it as entirely futile is: A) Not exactly constructive. B) Possibly untrue. The move might indeed die, if the rust foundations leadership gets it's act together. Which is a strong push for them to sort things out rather than assuming everything will be fine with their current heavy handed and opaque approach. Failing this, we could be in a situation with another Rocky linux, FlatCar linux or LibreOffice ;) (examples of successful forks)

oefrha 3y ago
In the examples you gave, either the original project shifted course significantly, or there are major technical disagreements. Here, pointless trademark drama is all there is, and the fork AFAICT replaced some strings and nothing else.
- dijit 3y ago
  libera.chat
  - oefrha 3y ago
    Not sure what you are trying to convey. There are a ton of IRC hosts out there and they are all interchangeable. A real language fork is not interchangeable, even a different implementation of the same language is going to have its subtle compatibility problems. People pay the price for tangible benefits like performance or portability. You don’t need to use a fork and pay the technical price for it if the only benefit is that Rust Foundation hypothetically won’t sue you for using the word “rust”; just frigging use “crab” as the moniker for “rust”.
    - dijit 3y ago
      Its an example of a wildly successful fork due to poor leadership, without any other technical reasons. You can argue that “its different because its a community” but thats dishonest, because ultimately migrating an entire community is much harder than having an alternative development stream like MariaDB and MySQL. Oh, wait, another successful fork…
      - oefrha 3y ago
        IRC is practically stateless, migrating is about as easy as someone signing up at the new host and changing your readme/contact page. If you have some bots you change some URLs. It may not be an easy decision, but the migration is a straightforward one time cost. Guess why a lot of projects moved off Freenode overnight? Because it’s very easy. Supporting a different language implementation, on the other hand, is an indefinite ongoing burden until one dies. Not to mention the trademark bullshit affects a tiny slice of the user base at best.
        dijit 3y ago
        Respectfully, I couldn’t possibly disagree more. Everything you said is just as true for an alternative language. You can maintain compat (like rocky linux) or diverge (like mariadb), so it remains to be seen. However the switching cost of moving your entire community is large and IRC is not stateless, pedantically it is a stateful connection, but you really mean that theres nothing you need to carry with you; but thats not true, permissions, identities, hostmasks etc. all of these tiny things spread across thousands is quite an effort and undertaking it is only done with a heavy heart. If you maintain compatibility then it could be as easy as changing a reference or just calling another compiler (like the Java implementations). Afaik all CentOS and RHEL scripts work without modification on Rocky. Either-way, I think I made my point, I am sure you are convinced of the inverse, so I leave this as my final word to other readers of the thread.

chrisco255 3y ago

It worked for io.js when they split off from node.js. When io.js was re-merged in with node, the project was all the better for it. They ultimately improved Node's release schedule and cadence, governance, etc.

colesantiago 3y ago
does the io.js fork still exist? If it is merged back into the main project or left unmaintained the fork failed and died.
- Borgz 3y ago
  You are implying that the only measure of success for a fork is for it to exist indefinitely. If the goal of io.js was to improve Node's governance model, which appears to be the case, then I would consider it a success.
  - colesantiago 3y ago
    > Forks of a large project seldom survive. The fork died. that is the point. goal or no goal.
    - rowanG077 3y ago
      It obviously didn't die. It got merged into the original project. That is a great end of a fork.
      - colesantiago 3y ago
        So it didn't survive then. Isn't that the whole point of what I said: > Forks of a large project seldom survive.
        rowanG077 3y ago
        But it did survive. I can't view rejoining the forked from repository as dying.

p0w3n3d 3y ago

Just look at LibreOffice. This is a fork of OpenOffice and OpenOffice is dead (at least to me)

colesantiago 3y ago
OpenOffice isn't dead, they made a release a few months ago this year. https://blogs.apache.org/OOo/entry/announcing-apache-openoffice-4-110 https://blogs.apache.org/OOo/entry/announcing-apache-openoff... Last commit made 3 days ago, actively maintained. https://github.com/apache/openoffice https://github.com/apache/openoffice
- deleted 3y ago
  [deleted]
- yarg 3y ago
  https://itsfoss.com/libreoffice-vs-openoffice/ https://itsfoss.com/libreoffice-vs-openoffice/ > Technically, both receive regular updates. But, OpenOffice is limited to bug fixes and minor updates. > LibreOffice has more development activity, frequent bug fixes/minor updates, regular major upgrades with newer features, and improved user experience. Apache can do whatever they want here, but the project is limping at best.
- sgt 3y ago
  So you went to github and saw commits made 3 days ago, then concluded that surely that means the project isn't dead. It is though, you're just completely missing the forest for the trees - a typical trait of programmer types.
  - colesantiago 3y ago
    It isn't though until they say it is discontinued. You also missed that OpenOffice made a new release and they were even bothered enough to make a post about it. Hardly a trait of dead software. As much as you would love to say it is dead: It officially isn't and it is still maintained.
- 3y ago

denton-scratch 3y ago

> Forks of a large project seldom survive MariaDB? That fork was also the result of heavy-handed lawyering over IP.