I used the phrase 'too big to fork' in another thread.

[david_chisnall@infosec.exchange]

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.

[jeroen@secluded.ch]

@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