Is AHK dead? (not developed any more)

[sinkfaze]

I have moved this to Offtopic.

[gregster]

Let's don't get ahead of ourselves! And let's tone down the personal angle of this discussion.

I think the first part of getting into a leading position for a (hypothetical) new main branch, would be to show for a person that (s)he/they can maintain a forked version for some prolonged time frame, including handling the discussion and bugs, fair and unfair critique. I think that would be much more convinving than indefinite theorizing and would show both programming and social skills (if the fork gets some traction).

If then the community thinks at some point in the future, that the fork should be the main branch, fine. I still think that Lexikos will come back - and I strongly hope so.
It is often underappreciated what he has done so far - I think AHK_L is now at least 10 years old, probably older. To keep doing this for such a long time with a project of this size (in your free time and not as a job) is a great thing! Thanks again!

Not to forget for all new up-and-coming developpers: if you are maintaining the main branch, there will be much more focus on you and expectations will be huge.
Therefore, I would say, sure, fork away - the more, the merrier. And then we can see and you can see yourself, if you are up to the task...

And finally, don't panic! Autohotkey won't stop functioning tomorrow...

[jeeswg]

- @nnnik: Do find some examples, remember, 'basic' you said.
- Btw you wrote a basic function, this year I think, and there were some pretty odd choices that you made.

- The people working on C++ at the moment are me, you and Helgef.
- Helgef wasn't too interested. I'm not sure how good you are at nurturing a team. So that left me.
- Anyhow, I'd already begun cataloguing the source code, reviewing past source code changes and writing demo/viable source code.
- Also, my AHK via DllCall projects helped ensure that I fundamentally understood every nut and bolt of the AHK functions. (I've done more work on them since my last update.)
- I asked a long time ago to have a proper AutoHotkey Source Code/C++ Development forum, and I was surprised there wasn't one already, when I joined the forum.
- I didn't see any active steps by the staff to secure AutoHotkey's future. By proposing fixes to AutoHotkey's syntax, and by documenting the source code, I hoped to attract and train the next generation, and avoid AutoHotkey dying like Media Player Classic et al.

- I collaborated with Helgef and invited you to join the team, and asked Helgef to invite you, but to no avail.
- It's threads like this, however, that make me sceptical of involving you:
A_MajorAHKVersion - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=13&t=53924
- Firstly the title should have been 'A_AhkMajorVersion', 'Ahk' not 'AHK', and 'Ahk' before 'Major' to match A_AhkVersion/A_AhkPath, minor, but speaks volumes.
- You also seemed to ignore the question of 'A_AhkXXXVersion' and 'A_OSXXXVersion'.
- The 'XXX' should be consistent to aid the memory, but you glossed over this.
- 'Major' wouldn't make sense in the context of the OS, and was confusing/ugly in its original context for AHK because people have expectations of what a major version number is.
- On something as basic as this you're already making AutoHotkey something of a disaster.
- Plus you proposed removing NumGet/NumPut.
- But more fundamentally, in a small team, whether you agree with something or not, we're not going to get very far if you refuse to respect or even acknowledge valid input.
- Btw you'll have a lot more fun if you try to encourage people rather than discourage people.

[kyuuuri]

Hello, I'm not experienced like people that posted in this topic, also I don't think I should be replying to this post because I'm a nobody in ahk's forums, but here are my 2 cents:
I personally think we should have some kind of democracy where everyone can suggest and vote what they think is needed. I think we need to stop making custom versions of ahk, that will split the community, will confuse new users, etc. Is not a good idea, it worked once only because Chris lost interest in ahk.
Right now we have how much? 70%? of users that simply come to the forums to post on wrong sections asking for help with titles like "NEED HELP SCRIPT NOT WORKING" (don't get me wrong, I ask for help too but if you read "ask for help" or "gaming" section you will know what I'm talking about), we need to attract more experienced users and useful people (didn't find a better word) and the only way to do it is by stop making custom versions and start making this language progress with everyone working on only 1 ahk and not multiple versions.
Don't get me wrong, there is nothing wrong with ahk, it works, we can do A LOT of things with it, I still love it but I know we can be WAY better.
We need to make a change, it doesn't matter if Lexicos is only on vacations or if he doesn't want to work on ahk anymore.

This scripting language is open source and needs the help of anyone that can code, make suggestions, help other users, etc. I'm willing to help and I know there is a lot of people that is willing to help as well.

So to make it short:

• We can make a suggestion section or a google form with moderators that will read them and filter stupid things like "I WANT AHK TO BE NAMED AHQ BECAUSE MY "K" IS BROKEN", then they will add those to a public list like in a google's spreadsheet with sections like Bug fix, changes, improvements, etc (this can be easier using google forms, having users to log in to fill the form and limitting the amount of time they can submit in 1 day) always having in mind the priority (no need to explain but just in case, if it's a bug that breaks ahk then it's obvious it has to be marked as URGENT and needs to be first)
• Leaders / experienced users can read this spreadsheet and make a list of possible changes that can be made for next update.
• This list will be posted in the forums so people can vote and establish an order for it. (again, urgent things don't need to be voted)
• We should separate that list in Bug Fixes, Changes, Improvements, etc like we did for the spreadsheet.
• We need to STOP splitting the community by making custom versions of ahk. This will only confuse new users and will make more experienced programmers choose another scripting language instead of this one. Instead of that we can listen to everyone's suggestion and make the community decide if it fits in our scripting language.

This way we have:

• Leaders / experienced users that will make the most important decision (deciding which suggestions can be worked on).
• Moderators / contributors / etc that can filter suggestions and establish their priority.
• A list of suggestions that everyone can read (in case anyone is interested in writing the code for it).
• Users giving suggestions with a pre established format, maybe using google forms (at first you will think there will be A LOT of suggestions, but they will be separated in changes, bug fixes, improvements, etc. and will be easier to establish a priority list, making it easier to work with)
• A poll (idk if it's the right word) where Leaders / experienced users can see what the community wants.
• Order, no more custom versions, suggestions lost, confusion for new users, unhappiness, etc.

This is what I always used for every project I made (not that I made a lot ) and it always worked, everyone had a voice, we agreed to filter stupid suggestions, we had established roles that made us know our limits so we don't "fight" with each other, it sounds like a big change at first but it will make things WAAAAAAAAAAY better.

Hope my bad english didn't ruin the post, I'm sorry if something doesn't have sense, it's like an storm of ideas that are in my mind right now / ideas that I already used. I re wrote this post like 3 times because of all the ideas that came in mind while writing it .

[nnnik]

Hello, I'm not experienced like people that posted in this topic, also I don't think I should be replying to this post because I'm a nobody in ahk's forums, but here are my 2 cents:
I personally think we should have some kind of democracy where everyone can suggest and vote what they think is needed. I think we need to stop making custom versions of ahk, that will split the community, will confuse new users, etc. Is not a good idea, it worked once only because Chris lost interest in ahk.
Right now we have how much? 70%? of users that simply come to the forums to post on wrong sections asking for help with titles like "NEED HELP SCRIPT NOT WORKING" (don't get me wrong, I ask for help too but if you read "ask for help" or "gaming" section you will know what I'm talking about), we need to attract more experienced users and useful people (didn't find a better word) and the only way to do it is by stop making custom versions and start making this language progress with everyone working on only 1 ahk and not multiple versions.
Don't get me wrong, there is nothing wrong with ahk, it works, we can do A LOT of things with it, I still love it but I know we can be WAY better.
We need to make a change, it doesn't matter if Lexicos is only on vacations or if he doesn't want to work on ahk anymore.

Thanks you've spoken from my heart.

[gregster]

kyuuri, you say that we should "stop making custom versions of ahk, that will split the community, will confuse new users, etc."
I don't see how this is true. Where are these custom versions that split the community? The only relevant I know of is AHK_h and I fail to see how it had negative effects... it is more an useful enhancement than a rival; and I don't see many newbies in the forum that even seem to know or care about it (only if someone recommends it to them because they have a special use case) - and usually becoming aware of it doesn't end in a nervous breakdown for them. I think such versions can also be a testing ground for features that might have potential for the main version.

In theory, it might be good to work on a unified version, but to be honest, I don't see it at the moment - too many egos competing. In the end, developers who offer their free time won't have any fun implementing features that some majority of experienced users (is this even democracy? well historically, ok yes, you could call it this way) agreed on, if they don't like it themselves. And that's ok - they are volunteers... it's not their job.

And you can't enforce a single version. Even if you say, "we want just one version", that would totally go against the idea of open source and the history of AHK and our forum (which isn't so bad). Sure, you could ban forks from this forum - but I fear that it would be counter-productive and in the end provoke a split of the community.

If you work on a project in a company or a club or privately, I would agree with your experiences - there can be good results. But I don't see the structures here to make it work like this. That's why I say, I want to first see what people can do and how they work together on a project like this. I want to be more convinced by actions than by plans and intentions.

And to be fair, I have seen my share of dysfunctional teams in companies, sports and other private endeavours. The composition of the team is important - and not everyone functions best in a team.

To be clear, there is no one stopping people from polling for wishlists, teaming up and creating the most wonderful version ever. To these people: surprise us, convince us with your concepts and that big egos can work together (for some time), show us how you solve disagreements, attract new developers or just make a decent fork - and then we will see!

But even if it is a success, I would never want to ban relevant forks from the forum... not only teams drive development, competition does too!

[nnnik]

AHK_H works out because it is an extension of AHK_L and these 2 don't actually compete that much.
They are completely compatible with one another. Given the current situation we would get extensions of AHK_L that are incompatible with one another.
They would become exclusive. The Forks that start now and gain traction would probably address one specific group of the community but not all of them.
Each fork would have each groups backing and exclusively so. After that we have a situation in which the community is split.

What you are suggesting is essentially: "Don't coorperate! Fight to the death until there is only one left standing!"
This is so uncivilized.
I won't create a fork, if anything I'll help someone else write theirs. Until then I will try and recruit people into one central project.
Making forks like you suggested will turn into a pitchfork situation very quickly.

[jeeswg]

@nnnik: What are your priorities for AHK features right now?

[nnnik]

We all hope lexikos returns, so we should prepare for his return.
The easiest way of doing this is something everyone should be able to agree on and doesn't set any future path in stone.
For now the goal should be the removal of technical debt.
Lexikos has mentioned a few times that the current parser does not fit our needs. If we want to expand this language in the future then a rewrite of this part is necessary.
This should be our first priority.

[jeeswg]

removal of technical debt
...
the current parser does not fit our needs

- Surely those are long-term goals.
- Those statements are also quite vague, can you be more specific?
- Do you have any suggestions for *right now*? Any smaller changes? Thanks.

[gregster]

[...]The Forks that start now and gain traction would probably address one specific group of the community but not all of them.
Each fork would have each groups backing and exclusively so. After that we have a situation in which the community is split.

What you are suggesting is essentially: "Don't coorperate! Fight to the death until there is only one left standing!"
This is so uncivilized.
[...]
Making forks like you suggested will turn into a pitchfork situation very quickly.

Who? Me? I say "fight to the death" and "don't cooperate"?
Quite the opposite, I did say that people should team up, if they are interested to develop, and show that they can work together instead of fighting over the smallest details. It would also be a good opportunity for them to test themselves.
Additionally, I promoted the idea that forks should have its place on the forum (not that I expect many). That's pretty much the opposite of "fight to the death". Allowing only one version would literally lead to "only one left standing"!

Besides, I don't see any supporting evidence that new forks (if they would happen and stay allowed here) would lead to a split. But anyway, who should prevent forks? The fork police? It's open source - AutoIt already exists... I also asked what current custom versions lead to confusion or splits, like kyuuri alluded to at least three times in his post. If they don't exist - what you seem to confirm - how can these custom versions be part of our problem?!?

Apart from that, I have made clear in my first post that I expect and hope that Lexikos comes back soon and continues on our current main version (this includes, of course, v2); and to meanwhile keep cool.

What I also did say is that a dysfunctional team would help nobody and that I would like to be convinced before we only allow one version with a team that nobody has seen working together by now.
A team is like a tool. A bad tool makes you crazy. A good tool and if it is also the right tool for the job, is a pleasure. But if you only have a hammer, everything starts to look like a nail...

P.s: I can only recommend using some real tools from time to time as a counterweight to just working at the computer.

[kyuuuri]

kyuuri, you say that we should "stop making custom versions of ahk, that will split the community, will confuse new users, etc."
I don't see how this is true. Where are these custom versions that split the community? The only relevant I know of is AHK_h and I fail to see how it had negative effects... it is more an useful enhancement than a rival; and I don't see many newbies in the forum that even seem to know or care about it (only if someone recommends it to them because they have a special use case) - and usually becoming aware of it doesn't end in a nervous breakdown for them. I think such versions can also be a testing ground for features that might have potential for the main version.

In theory, it might be good to work on a unified version, but to be honest, I don't see it at the moment - too many egos competing. In the end, developers who offer their free time won't have any fun implementing features that some majority of experienced users (is this even democracy? well historically, ok yes, you could call it this way) agreed on, if they don't like it themselves. And that's ok - they are volunteers... it's not their job.

And you can't enforce a single version. Even if you say, "we want just one version", that would totally go against the idea of open source and the history of AHK and our forum (which isn't so bad). Sure, you could ban forks from this forum - but I fear that it would be counter-productive and in the end provoke a split of the community.

If you work on a project in a company or a club or privately, I would agree with your experiences - there can be good results. But I don't see the structures here to make it work like this. That's why I say, I want to first see what people can do and how they work together on a project like this. I want to be more convinced by actions than by plans and intentions.

And to be fair, I have seen my share of dysfunctional teams in companies, sports and other private endeavours. The composition of the team is important - and not everyone functions best in a team.

To be clear, there is no one stopping people from polling for wishlists, teaming up and creating the most wonderful version ever. To these people: surprise us, convince us with your concepts and that big egos can work together (for some time), show us how you solve disagreements, attract new developers or just make a decent fork - and then we will see!

But even if it is a success, I would never want to ban relevant forks from the forum... not only teams drive development, competition does too!

Hello, don't get me wrong , everything I said was something more like "what we should do if we care about ahk" and not "what rules we need".
Instead of a custom version we can make a custom way to work having these premises in mind.
I don't want forks to be banned, I only want people that cares about ahk progressing to stop making forks and try to work on the "real" version of ahk so we can progress with that one, we don't need rules for that if we care about ahk.
About ahk_h it's like @nnnik said.
Again, my post was more something like rules that we should follow ourselves and not rules that need to be applied in the forums. It's like "if you care about ahk, please consider working on it instead of making your own version of it".
And about splitting the community, it will do. It doesn't happen with ahk_h because it adds functionalities that are needed for specific projects.
But let's say tomorrow I make ahk_k, that changes things from normal ahk. Now we have 2 ahk versions with differences in code but same purpose. Instead of doing that I can make my suggestion and if the ahk community thinks is needed then it will be added soon, if it's not then I can wait for next update. If nobody wants what I need and I'm a person that cares about ahk, then I can:

• Keep waiting
• Make a pull request and write its code myself to see if it's approved
• Apply these changes to the source and compile. And instead of making a fork and posting it in the forums confusing users, I will have my normal ahk version but tweaked for myself. If it didn't get voted it's because ahk's community didn't want/need what I consider that needs to be changed/implemented so there is no reason to have it in the forums.

This way I won't have a custom ahk version maintained by myself, I will have a simple tweak I make to a normal ahk version. I won't confuse users and it won't split the community.

A good example about splitting would be v2 and v1, you will have some scripts made for v2 that won't work on v1 and vice versa. If you use v2 and you ask for help you will only have v2's community to help you. I know it's "official" but you understand what I mean.

So to make it short, what I proposed before was some kind of premises that we have to follow ourselves to make ahk progress.

Remember, this is my point of view.

Apart from this, we need to clean forums a little and establish a good suggestion system that let's everyone see all the suggestions, bug reports, etc. in 1 place / 1 spreadsheet.

(remember that english is not my main language, if for some reason I sounded rude, it wasn't my intention )

PS: I don't mind helping with this (idk if this phrase means that I don't mind using my time here, like I want to do it or if it means "I don't care about ahk", If it means the second one, please tell me), I have some free time I want to spend here to make it progress, please don't think I'm like YOU ALL HAVE TO DO THIS WHILE I RELAX IN MY HOUSE, I'm not a c++ programmer but maybe I can help with forms, sheets, etc.

Have a nice day.

[gregster]

kyuuuri, I appreciate your thoughts and your motivation to help. But we might have our different views what might be best for AHK. I still don't see the problem of forks - and I mentioned hosting relevant forks. Of course, we don't need every test or personal version that doesn't get any traction - but these problems will sort out itself. If there is no interest in a fork and it doesn't add extra value, it won't get much visibility. In the last ten years I have seen not one new fork here on the forum (or, I missed them because nobody cared) and I don't expect any to flood the forum now. Even if there would be one or two, discussions about these wouldn't likely happen in the 'Ask for Help' forum where new users start and no one would recommend or support these versions, if they don't add extra value or haven't proven some reliability or consistency.

But I think that for a complex project like this, experience is important (especially if we think about developping new talents for the future) and it would be better for people that never handled a software project of this size, to practice to maintain a version for some time - and for this the possibility of feedback from other users is good. Of course, this could strictly happen on github - but then again, most versions won't get much attention anyway.

If Lexikos or HotKeyit put out a new version, people know what they can expect (their versions are 10 years or older). If you or me would make a fork, people wouldn't care much unless we would do something really interesting, reliable and useful - and at least create the impression that we would support it for some time. If that would really happen, it is always good to have a record of it (as documented information, if someone wants to revisit an issue in five years or plans a specialised version that is only interesting for a few people), even if it has not a remote chance of ending up in the main version.
And we have seen with HotKeyit's and Lexikos' versions that cannibalisation is not necessarily an issue. Again, I would be surprised if we see more than one fork in the next years that will get any traction - and I wouldn't even bet that we see one (especially, when Lexikos returns). But forks as practice and getting experience - this I would like to see instead of more theorizing.

[nnnik]

Umm do you understand what we are talking about?

[gregster]

Obviously
But please elaborate what you have specifically in mind instead of generalizing.
I will be happy to reiterate and expand on any things that remained unclear from my posts.

[kyuuuri]

Ok let's ignore the fork part and the team part. What about establishing a good system for suggestions so we can have all of them listed in a sheet with pre established format so it's ordered and easy to read? I always wanted to learn C++ and this can be a good reason to do it. I don't know if it's only me but the thing that discourages me the most is chaos, disorder (idk which one is the right word). Not saying that the current situation is a chaos but you if you read the posts I made before, we can have a better way to handle suggestions.
I don't mind setting the sheet and the forms if I'm asked to.

[SOTE]

tank wrote*:
'FYI let me be perfectly clear. I expect Lexikos will continue when whimsy suits him.'

SOTE wrote:
'And asking if AHK is dead, is really pushing it.'

Why are you guys so passive-aggressive?

And I'm not pushing. Maybe asking if AHK is dead isn't tasteful but it's not even a clickbait. Simply, as you can see, my English
is garbage and I feel bad about it also because it took me nearly an hour to write this post and I was able to do so only thanks to
the translator. So I asked this way because I couldn't do it otherwise.

You have a brand new account, and all of your posts are on "is AHK dead?" This doesn't generate a lot of trust about what your intentions are. Not saying you aren't sincere or legitimately worried, but it should also be understandable if some people are a little skeptical.

The only purpose of this topic is to bring attention to this situation (absence of Lexikos and development stopping) and a
suggestion that maybe we should start asking questions instead of pretending everything is in a nice way.

I don't think AutoHotkey members need to pretend. We do have AutoHotkey_H and it's developer, HotKeyIt, is still quite active on the boards (to include having done YouTube videos with Joe Glines. I don't think you should ignore this branch of AutoHotkey. Arguably, AutoHotkey_H could quite easily become the main branch, and has already introduced some interesting new features.

I agree that the AutoHotkey Foundation and members should have some form of plan or strategy to deal with the possibility that Lexikos might not return or is unable to return. Lexikos has been a developer for quite a long time. It's arguably unfair to expect him to continue indefinitely or not to take a long break. There are many things that happen in life.

Ideally, a successor or a group of them would be groomed, who had been working on AutoHotkey_L for a significant period of time and were very familiar with the source code and forums. And then this person or group would be named by Lexikos or the AutoHotkey Foundation to continue development. However, it seems no planned grooming or plans for succession were done, which in itself could be problematic. That's because infighting and hurt feelings can be involved, by persons who felt they should have been named the successor, so it could even turn into something real ugly. Even more so than Lexikos just leaving and the question of who's next in line be left up in the air.

AutoHotkey_L is quite mature and stable. One questions how much there is left to do on the Windows OS, more than minor tweaking, debating about syntax preference, some more code for automating non-standard GUIs, or better code for automating the most popular web browsers; Edge, Internet Explorer, FireFox, and Chrome. Where it seems AutoHotkey has got a good handle on 2 out of the 4. Hmmm... That might still be quite a plate full of things to do, but quite a lot has already been done or the road to what should be done on the Windows OS is much more clear.

Arguably, the next step might should be doing something more radical, like switching from compiling the source with Visual Studio to GCC or creating an AutoHotkey version for Linux and/or Android. This type of step might take a or a group of developers that think differently about where AutoHotkey should go.

I'm just worried. I'm worried about project and about it's only developer who I hope is OK.
No matter what, it looks like Lexikos is the only guy with vision. His absence is serious problem for this project.
There's quite big community but only one person concerned in development. We might not want to admit it but sooner or later this will be issue we'll have to address.

Again, this ignores the contributions from HotKeyIt and AutoHotkey_H. Which is also quite mature and stable. And the issue doesn't seem to be that there weren't any developers, just that Lexikos had control of the final decision on what did or didn't go into his fork, AutoHotkey_L. There was debatably no point in creating yet another fork of AutoHotkey for the Windows OS, when you already have AutoHotkey_L and AutoHotkey_H looking at you.

Maybe the time of a new fork is coming, but it appears people are hesitant because they don't know Lexikos status. There is arguably no point in making a new fork on the Windows OS, if Lexikos returns, since that is the main established branch of AutoHotkey. But let's not act like people can't switch over to AutoHotkey_H or that there isn't any developer talent around to add code to AutoHotkey_L or create a new fork for the Windows OS.

[nnnik]

Ok then let me ceck if I have understood things correctly.

This discussion is - if I understand it correctly - about the fact that lexikos has been absent for a while and the consequences from that.
For example the fact that we need to maintain and develop the language even after the main developer is gone.
Now we want to combine community efforts in some way and want to combine our strength in order to make a smooth transition

If I understand your suggestion correctly you know want us to stop talking and combining our efforts and create seperate competing forks.
Those forks then somehow gain traction within the community and compete for the main fork without splitting the userbase.??
Meaning they compete without actually competing for users.???????
Then one of the forks will somehow become the main fork and we have a new maintenance system.?????????????

And you suggest that because you think that the egos of this community are too big to coorperate?

[jeeswg]

- @nnnik: What are your priorities for AHK features right now (that you could implement within 6 months)???????
- More generally, do you have anything practical/interesting/useful to say about the development of AutoHotkey????????????? I.e. some kind of fuller plan re. functionality.

[gregster]

Ok then let me ceck if I have understood things correctly.

This discussion is - if I understand it correctly - about the fact that lexikos has been absent for a while and the consequences from that.
For example the fact that we need to maintain and develop the language even after the main developer is gone.
Now we want to combine community efforts in some way and want to combine our strength in order to make a smooth transition

If I understand your suggestion correctly you know want us to stop talking and combining our efforts and create seperate competing forks.
Those forks then somehow gain traction within the community and compete for the main fork without splitting the userbase.??
Meaning they compete without actually competing for users.???????
Then one of the forks will somehow become the main fork and we have a new maintenance system.?????????????

And you suggest that because you think that the egos of this community are too big to coorperate?

Not quite, I recommended to interested users to team up and show that they can work together and to gain practical experience (if that is only developping a maintenance system or if a maintenance system is developped while doing a fork, is not really relevant if there is any progress).

I don't suggest that people should strive to work on their own, but that I have doubts that continuous collaboration between certain egos will work - but that I would be happy to be convinced of the opposite. I also doubted that a forced single version (that was alluded to) would help and would rather be counter-productive in the long run.

As I wrote repeatedly, I don't even expect to see many (if any) relevant forks in the near future, but that in general, a fork could be useful (especially for a team) to gain experience with a project of this size. And yes, I think that such actual practice also helps to identify problems and priorities in a future maintenance system for the main branch.

But as forks cannot be prevented (and shouldn't be) we should be open, if they present useful innovations (even if it is only to document them for potential later use).

As we have seen with Lexikos original fork AHK_L, such forks can be very productive and can (not must) become one day the main branch if the main branch is stagnating and if the fork has big support from the user base (and that is how I also understand tank's position). Further, AHK_H shows everyday that a well thought out fork can contribute to the language and the fears spreading about cannibalizing forks that are presented here have no basis in the 15+ years history of AutoHotkey. This over-dramatization of things that could happen (without actual evidence) is exactly what I mean, when I allude to fruitless discussions.

Ideally, Lexikos would continue his work (soon) and the need for some kind of transition team wouldn't get urgent (then still, (a) fork/s could be a useful testing and training ground for the next generation after Lexikos and/or to have more people who would be able to support him)

To repeat, there is no one preventing anyone from doing productive team work - on the other hand, there is no way to prevent individual efforts. Both can advance AHK. That is the reality that we should embrace and there is no need to dramatize any of this and that's why I say "don't panic!" I would welcome any kind of productive effort.