I work with @lkoutsofios at AT&T Labs Research and volunteered to see if I could help restore the repo to a state the community is comfortable with. This was last discussed in #1464 (comment) and onward.

I am not an expert in ksh or the technical issues, and I don't know the entire history, but my understanding is that

1. ksh93u+ is the final official release from AT&T. This can be found in the branch 2012-08-01-master
2. A later version, ksh93v-, was contributed by the original authors after they left AT&T, but this version is not considered stable. This can be found in the tag ksh93v
3. @krader1961 has been maintaining the master branch for some years. He has tried to streamline the codebase (and only support ksh, not the rest of ast), but this has caused compatibility issues.

The original authors of ksh have all left AT&T. We still have plenty of users inside the company, but no one who can maintain and manage the project.

My proposal is:

• Move the current master to a branch "ksh2020" (or whatever is appropriate).
• Clearly mark README.md and CHANGELOG.md on that branch as unmaintained, point to segfault with extended globs #1464 and this issue for further info
• Reset the master branch to 2012-08-01-master
• Remove external collaborators from the repo. Since no one in AT&T is maintaining this, it doesn't make sense to have this fork be the active one. Git and Github allow anyone to take the code in whatever direction they want, in their own space.
• Clean up README.md to reflect the current state: "This repo contains the AT&T ksh93u+ and experimental ksh93v- versions of AST. There may be later forks of AST and ksh out there."
• Change CONTRIBUTING.md and issue template to be clear we are not actively maintaining this fork and do not promise to review anything.
• Shorten the repo description to "AST - AT&T Software Technology" (Streamline this repository's description #1441)

After this is complete, we at AT&T may contribute patches to ksh93u+ in the master branch. We probably won't review or accept contributions unless they are trivial (build issues, etc.) Eventually, we will archive this repo.

Currently I don't think anyone in the company plans to create a repo just for ksh. However, I think this is fairly straightforward and can be taken up by the community.

If anyone wants to create a community fork, I'd suggest creating a new GitHub Organization. This is free for open source projects. The bigger commitment is time, making contribution and maintenance guidelines clear, possibly creating a code of conduct, etc. Of course if anyone wants to fork this repo to an existing organization, they are welcome to do that too.