5 ms·

MariaDB, OpenTofu, etc... Those are the exceptions. Forking is easy. Maintaining a fork, keeping the quality and innovation alive, and the community involved i

by linkdd 3y ago

MariaDB, OpenTofu, etc... Those are the exceptions. Forking is easy. Maintaining a fork, keeping the quality and innovation alive, and the community involved is hard. There are many more failed forks than successful forks. So saying "you can fork" is utopist at best. Sure you can, but you'll probably be the only one maintaining it and it will slowly rot as there won't be a community to keep it bug-free and compatible with new hardware/standards.

nottorp 3y ago
However that doesn't matter when you have an existing game title already in the market. You just maintain your title, which you need to do anyway.
amrocha 3y ago
The idea is that the community decides on a fork and maintainers move over. Are those really the exception? Do we have examples of large projects that made a monetization TOS change and didn't immediately get forked? The only one I can think of is Docker maybe?
- nani8ot 3y ago
  Audacity made some bad decisions but the forks never got anywhere. That said, this particular issue was blown out of proportion, so the forks going nowhere isn't an issue.
xmprt 3y ago
I think it's a self regulating system. If the product was so important and so many people relied on it (eg. Unity) where a cash grab by the Unity development team results in the entire community considering switching to a completely different product (eg. Godot), then I'm sure the community would rather fork the existing product and make it better. On the other hand, if the product wasn't that important or the cash grab wasn't that bad, then fewer people will be likely to fork and the current product will continue to be the mainline. Open source gives users more options which is always better.
throw0101c 3y ago
> Forking is easy. Maintaining a fork, keeping the quality and innovation alive, and the community involved is hard. LibreOffice is doing pretty well compared to OpenOffice: * https://news.ycombinator.com/item?id=37645160 https://news.ycombinator.com/item?id=37645160 EGCS was eventually merged back into GCC (or rather it became the new GCC?). I don't pay attention recently, but XEmacs was/is pretty active along with Emacs.
- linkdd 3y ago
  More anecdotal examples of "survivor's bias" do not dismiss the initial argument.
  - mcv 3y ago
    I haven't seen any evidence in support of the original argument, though. Which open source projects have been killed explicitly by Big Tech that they didn't originally create? Microsoft spent ages trying to kill Linux but never succeeded.
wolverine876 3y ago
> Maintaining a fork, keeping the quality and innovation alive, and the community involved is hard. It's hard, but the FOSS model has a long, successful history at this point.
OkayPhysicist 3y ago
You don't need to innovate on the foundation of your product. It's a game engine: If it fulfilled your needs when you started, it's fulfilling your needs now. With open-source solutions A) you can't have the rug pulled from under you, as you have a perpetual license, and B) you can fix/modify/add things yourself if the business needs arise. With a proprietary solution, you might get A, but you have zero hope of B. It's an objectively worse proposition.
- linkdd 3y ago
  If my business is making games, I don't want to fix/modify/add things to a game engine. You do need to innovate on the foundation if you plan to maintain your game long term: new consoles support, new hardware support, obsolescence of old platforms, etc... You do not need to innovate if you plan to let your game rot and become unplayable 10-20 years later. Yes having a FOSS solution for the foundation would be ideal. That was not the topic of the discussion. The topic was about the claim "we can fork if we're not in agreement". No, as a game developer you won't be forking and maintaining a game engine. No a "just fork it" is not a viable solution in the majority of cases as you need a strong community behind you and your fork to make it last long term and not rot after 2 weeks.
  - danparsonson 3y ago
    Actually it's quite common for game dev studios to make custom mods to engines (source code to Unreal engine available here for example: https://www.unrealengine.com/en-US/ue-on-github https://www.unrealengine.com/en-US/ue-on-github). The idea with forking an open source engine as a game dev would not necessarily be to maintain it for the community, but to bring it in house and ensure continuity for your own projects.
    - linkdd 3y ago
      That's fair, but if we consider the amount of game dev studio that have the resources (time and money) to do that, versus the amount of indie game devs and small studio who do not, I'm not sure that it's fair to say "you can just fork it". The examples of successful forks are anecdotal, they are the exceptions not the rule. This is survivor's bias.
plagiarist 3y ago
What are some examples of open source projects that were taken over and the licensing modified where no successful fork managed to emerge?

by linkdd 3y ago

nottorp 3y ago

However that doesn't matter when you have an existing game title already in the market. You just maintain your title, which you need to do anyway.

amrocha 3y ago

The idea is that the community decides on a fork and maintainers move over. Are those really the exception? Do we have examples of large projects that made a monetization TOS change and didn't immediately get forked? The only one I can think of is Docker maybe?

nani8ot 3y ago
Audacity made some bad decisions but the forks never got anywhere. That said, this particular issue was blown out of proportion, so the forks going nowhere isn't an issue.

xmprt 3y ago

I think it's a self regulating system. If the product was so important and so many people relied on it (eg. Unity) where a cash grab by the Unity development team results in the entire community considering switching to a completely different product (eg. Godot), then I'm sure the community would rather fork the existing product and make it better. On the other hand, if the product wasn't that important or the cash grab wasn't that bad, then fewer people will be likely to fork and the current product will continue to be the mainline. Open source gives users more options which is always better.

throw0101c 3y ago

> Forking is easy. Maintaining a fork, keeping the quality and innovation alive, and the community involved is hard. LibreOffice is doing pretty well compared to OpenOffice: * https://news.ycombinator.com/item?id=37645160 https://news.ycombinator.com/item?id=37645160 EGCS was eventually merged back into GCC (or rather it became the new GCC?). I don't pay attention recently, but XEmacs was/is pretty active along with Emacs.

linkdd 3y ago
More anecdotal examples of "survivor's bias" do not dismiss the initial argument.
- mcv 3y ago
  I haven't seen any evidence in support of the original argument, though. Which open source projects have been killed explicitly by Big Tech that they didn't originally create? Microsoft spent ages trying to kill Linux but never succeeded.

wolverine876 3y ago

> Maintaining a fork, keeping the quality and innovation alive, and the community involved is hard. It's hard, but the FOSS model has a long, successful history at this point.

OkayPhysicist 3y ago

You don't need to innovate on the foundation of your product. It's a game engine: If it fulfilled your needs when you started, it's fulfilling your needs now. With open-source solutions A) you can't have the rug pulled from under you, as you have a perpetual license, and B) you can fix/modify/add things yourself if the business needs arise. With a proprietary solution, you might get A, but you have zero hope of B. It's an objectively worse proposition.

linkdd 3y ago
If my business is making games, I don't want to fix/modify/add things to a game engine. You do need to innovate on the foundation if you plan to maintain your game long term: new consoles support, new hardware support, obsolescence of old platforms, etc... You do not need to innovate if you plan to let your game rot and become unplayable 10-20 years later. Yes having a FOSS solution for the foundation would be ideal. That was not the topic of the discussion. The topic was about the claim "we can fork if we're not in agreement". No, as a game developer you won't be forking and maintaining a game engine. No a "just fork it" is not a viable solution in the majority of cases as you need a strong community behind you and your fork to make it last long term and not rot after 2 weeks.
- danparsonson 3y ago
  Actually it's quite common for game dev studios to make custom mods to engines (source code to Unreal engine available here for example: https://www.unrealengine.com/en-US/ue-on-github https://www.unrealengine.com/en-US/ue-on-github). The idea with forking an open source engine as a game dev would not necessarily be to maintain it for the community, but to bring it in house and ensure continuity for your own projects.
  - linkdd 3y ago
    That's fair, but if we consider the amount of game dev studio that have the resources (time and money) to do that, versus the amount of indie game devs and small studio who do not, I'm not sure that it's fair to say "you can just fork it". The examples of successful forks are anecdotal, they are the exceptions not the rule. This is survivor's bias.

plagiarist 3y ago

What are some examples of open source projects that were taken over and the licensing modified where no successful fork managed to emerge?