Alberth, thanks for taking the time to reply, and sorry I missed it.
Alberth wrote:Toffo wrote:Well that's it, isn't it? Life gets busy, people get busy. So if the devs are too busy to review patches, or have standards that are so high that no patch contributor can or will meet them, eventually the current crop of devs get will too busy with life and the new crop of devs don't get accepted. No one gets to contribute, the project dies, and those in charge at the time will have overseen that death.
The standards are what they are, because we believe it's the best approach. You are free to disagree. At some point this becomes a difference in project direction, and a reason to fork, eg like Cirdan has done.
Forking is always possible. You don't have to wait until OpenTTD is dead, devs are not in control like you sketch it.
If you want to have the current devs aboard, then yes, you will have to convince us, but it's not required to continue the project.
The standards might be the best approach for the maintainability of the code, but are they the best approach for the health of the project? I can't answer that.
And true, forking is possible, but for me a fork is no longer OpenTTD, it's something else. The devs are not in control of OpenTTD's code, but they ARE in control of OpenTTD. Let's not end up with 20 different OpenTTD distros
Alberth wrote:Toffo wrote:My personal view is also the "build first, refine later" view - but granted, this view of mine has never been applied to software development. OpenTTD is already refined though
Not by a long shot. Do the "start new game" and "autorenew vs autoreplace" exercises I suggested. There is a lot more unrefined crap below the hood which is much more challenging to get right. Most of my commits is refactoring, ever since I became dev, and there is still plenty. Consider yourself invited to experience consequences of your view in reality.
I can imagine that "build first, refine later" might not turn out well for anything but a small software development project. I've seen it work in other fields. I'll trust your experience when you say it doesn't work for software!
Alberth wrote:Toffo wrote:By all measures, OpenTTD is a remarkable project. But I think we're at a turning point where for OpenTTD to remain remarkable and to stand the test of time, things need to change at a fairly fundamental level, and big decisions need to be made. These decisions, or lack thereof, will rest on the shoulders of the few.
This is a false assumption as I said, you don't have to wait and do nothing.
If people take action, they are taking action on OpenTTD's code, not on OpenTTD. I am referring to OpenTTD as it currently stands as a project.
Alberth wrote:There is a second reason I think. You can't expect devs to fundamentally change in how they do things, just like we can't force patch writers to only provide patches that we completely agree with. If you want to change the direction of the project, you must either convince devs to change opinion (which is going to be very very hard, as they are grounded on technical foundations and experience of the last 10 years), you must become a dev yourself (fight the system from within
), or you must fork and take over as the main OpenTTD version.
At least, I see no other way, or did I miss something?
EDIT: Oh, and "fork" is not the solution I think, it's the start of the same problems, but for the person(s) forking.
Agreed, and I don't expect anything. OpenTTD is a spare-time and free project, and no one owes anyone anything. And no, you very rarely miss anything, and you haven't missed anything now. And I agree that forking is not the answer. I think we agree on the options, which I also covered in an earlier post, amended for clarity:
Toffo wrote:So for the project to thrive, I see three options.
1. The current crop of devs can put more work into OpenTTD. As someone who is 10 years older today than he was 10 years ago (
), I can attest that isn't a reasonable ask. Life happens, families grow.
2. Let new people in. Yes, that will mean a changing of standards, and it might mean learning to get along with those who might have a different viewpoint. Things might be rough for a while until a new status quo with this expanded group of devs, well, develops.
3. A third option, of course, is to fork.
If we do nothing, OpenTTD ("trunk") most likely dies. To me, as an observer, option 2 looks best for the health of the project.