I used the phrase 'too big to fork' in another thread.
-
I used the phrase 'too big to fork' in another thread. It's something I try to avoid in projects I maintain. I don't want to control how you use my code. Giving you a license that lets you do whatever you want with it is part of that, but it's on the start. The rest is making sure that, if we disagree on how it can evolve, you can take your copy and make it do something different. That means building small projects, building projects with well-defined and stable interfaces between components, and documenting how things work.
I'm not always good at these things, but they're always my goals. If a project is too big to fork, those freedoms that the license gives you are freedoms in name only: you don't have the ability to exercise them.
-
R relay@relay.infosec.exchange shared this topic
-
I used the phrase 'too big to fork' in another thread. It's something I try to avoid in projects I maintain. I don't want to control how you use my code. Giving you a license that lets you do whatever you want with it is part of that, but it's on the start. The rest is making sure that, if we disagree on how it can evolve, you can take your copy and make it do something different. That means building small projects, building projects with well-defined and stable interfaces between components, and documenting how things work.
I'm not always good at these things, but they're always my goals. If a project is too big to fork, those freedoms that the license gives you are freedoms in name only: you don't have the ability to exercise them.
@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
-
R relay@relay.an.exchange shared this topic
-
I used the phrase 'too big to fork' in another thread. It's something I try to avoid in projects I maintain. I don't want to control how you use my code. Giving you a license that lets you do whatever you want with it is part of that, but it's on the start. The rest is making sure that, if we disagree on how it can evolve, you can take your copy and make it do something different. That means building small projects, building projects with well-defined and stable interfaces between components, and documenting how things work.
I'm not always good at these things, but they're always my goals. If a project is too big to fork, those freedoms that the license gives you are freedoms in name only: you don't have the ability to exercise them.
@david_chisnall with source control, diffing, patching, merging, the size of the project does not matter.
-
@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.
-
@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.
-
@david_chisnall we have two very different views of reality, it appears.
@david_chisnall it certainly does help to keep projects small and focused.
but, for instance, ibm's eclipse ide, despite being, to put it gently, a collossal turd, has been forked numerous times.
-
@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?
-
@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?
@david_chisnall woah hey now, i didn't say it was easy. but you made it sound like it is impossible.
-
@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.
-
@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
️ -
@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 ok. maybe i was too optimistic in my wording.
what you just wrote about seems to weigh more heavily though: frequent breaking changes. and they can also occur in small projects.
-
@david_chisnall ok. maybe i was too optimistic in my wording.
what you just wrote about seems to weigh more heavily though: frequent breaking changes. and they can also occur in small projects.
@david_chisnall and when you depend on a bunch of small projects and they all break abi all the time, does it then make much of a difference if the dysfunctionality is monolithic or modular?
-
@david_chisnall and when you depend on a bunch of small projects and they all break abi all the time, does it then make much of a difference if the dysfunctionality is monolithic or modular?
If small projects break their APIs (or ABIs) all the time, that affects all of their users. If a large project breaks their internal APIs, that only affects downstream forks. That makes the cost-benefit calculations for them very different.
-
If small projects break their APIs (or ABIs) all the time, that affects all of their users. If a large project breaks their internal APIs, that only affects downstream forks. That makes the cost-benefit calculations for them very different.
@david_chisnall i would say this too depends on style and internal culture. but yes. there's a good reason why i always stuck to LLVMs/libclangs rather stable C ABI rather than messing around with their volatile class system. it takes them forever though to expose all the parts.
-
@david_chisnall i would say this too depends on style and internal culture. but yes. there's a good reason why i always stuck to LLVMs/libclangs rather stable C ABI rather than messing around with their volatile class system. it takes them forever though to expose all the parts.
@david_chisnall we can also debate how much of that is due to C++ leaking implementation details almost by design.
-
@david_chisnall we can also debate how much of that is due to C++ leaking implementation details almost by design.
C++ here doesn’t make a difference for forks. You can build stable public interfaces in C++ but it’s harder. But when you’re maintaining a fork, it’s the internal structure that matters. No amount of information hiding helps when you’re on the other side of that boundary. The Linux kernel is a good case study here: they strive for 100% ABI compatibility for things in userspace but routinely make changes that break out-of-tree kernel modules and cause huge merge headaches for downstream forks.
-
C++ here doesn’t make a difference for forks. You can build stable public interfaces in C++ but it’s harder. But when you’re maintaining a fork, it’s the internal structure that matters. No amount of information hiding helps when you’re on the other side of that boundary. The Linux kernel is a good case study here: they strive for 100% ABI compatibility for things in userspace but routinely make changes that break out-of-tree kernel modules and cause huge merge headaches for downstream forks.
@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?
I’ve written a lot on this subject, most recently this post, which is probably a good starting point.
-
@david_chisnall i'm familiar with conway's law. there is nothing to object to in this post except that it's too abstract to answer my question.
-
R relay@relay.mycrowd.ca shared this topic
