@david_chisnall good points. what is your opinion on how they could fix it?
@david_chisnall good points. what is your opinion on how they could fix it?
@david_chisnall with source control, diffing, patching, merging, the size of the project does not matter.
@lritter That is so obviously untrue, I can’t even begin to think of how to argue with it.
@david_chisnall we have two very different views of reality, it appears.
@lritter So you maintain a fork of LibreOffice with custom features? Or Chromium? Or even something smaller like LLVM? Or any other million-line or larger project?
Have you, in fact, ever tried to do the thing that you’re saying is easy independent of scale? When someone does a refactoring upstream and removes a function that your local change was calling and changes a data structure that it relies on, version control makes it easy for you to keep the update? When this happens once a week, it’s easy for you to keep up with security updates and keep your custom feature working?
i have no clue what the background of this discussion is but it popped into my notifications right before i went to bed and i personally agree with the take of tiny small easy to focus modules being true open source and big projects an anti pattern.
i wonder why somebody woupd say size doesnt matter. isnt it obvious that smaller is better? 😁
...i mean - who knows, maybe we get stable reliable deterministic LLMs who lagically make size not matter, but for now 🤷♀️
@david_chisnall woah hey now, i didn't say it was easy. but you made it sound like it is impossible.
@lritter You literally said that the tooling makes the size of the project irrelevant:
with source control, diffing, patching, merging, the size of the project does not matter.
And this is obviously incorrect for anyone who has maintained a fork of a large project for any length of time.
@david_chisnall The entity that improves the code base the most, and has the better tool, the better support, will be the surviving fork. Especially if "competing" forks are going to take patches forward/back. If one does not care about what the other fork adds, then one is good, but if all users leave..... becomes a question of why one is working on code, who it is for, which might be maybe just yourself; but then also why one opens it.
And open source, the worst part likely is the users ;)