Hacker News Reader

Comment by linkdd | Hacker News Reader

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.

View on HN

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.

> 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

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.

More anecdotal examples of "survivor's bias" do not dismiss the initial argument.

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.

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.

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.

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). 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.

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.

I can't think of a single example of an unsuccessful fork of a large project caused by a monetization change. So I am not convinced that success is the exception for that case.

> If my business is making games, I don't want to fix/modify/add things to a game engine.

Oh but you do. Unless you want to be one of those 10000 asset store games that no one buys.

> You do not need to innovate if you plan to let your game rot and become unplayable 10-20 years later.

They stop maintaining games in 2-3 years, not 10. The few exceptions that maintain sales forever are just that, exceptions.

Are you thinking of multiplayer free to play games? Those aren't games, they're predatory grinding treadmills and I don't care what happens to them.

> let your game rot and become unplayable 10-20 years later

Don't worry about it. Other people will literally solve that problem for you if they like your game enough no matter what you do. They won't even bother asking for permission.

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.

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?

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.

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

> 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.

Reply on news.ycombinator.com