I have read the paper “FreeBSD and the Early Unix Communities”, interesting about UNIX history. And found two FORTRAN occurrences:
DEC also had the best FORTRAN compiler at the time (much better than the one in Unix).
At the time, DEC distributed many of its programs to universities in source form. So, within a couple of years of the CACM article, they had ported FORTRAN and other programs to Unix using emulation libraries that translated what would be RT-11 or RSX/11M system calls into Unix system calls.
There is a third occurrence of FORTRAN in the magazine:
Before moving on to the 386BSD porting topic, let’s see hardware and software technology in the Japanese industry at that time. In the 1980s, mainframes or minicomputers were still popular as larger-scale computers in Japan. Many applications written in FORTRAN or COBOL were used in government facilities, offices, banks, etc. and major electric companies partnered with US companies to learn the technology, including hardware and software. Until 1975, foreign companies were not able to enter the Japanese market.
I read with interest another paper: “FreeBSD at 30 Years: Its Secrets to Success”. It is interesting about FreeBSD characteristics but also about how to create and manage a community on the long term.
Port [software packages], documentation, and development committers are all given equal say in how the project is run. Notably, they all can run for Core [of the FreeBSD organization] and get the same voting rights. In most projects, the developers have more say and others are treated as inferior. The FreeBSD project has worked on building a culture of inclusion from its start.
So don’t worry if you think you are not ready to contribute to the code of a Fortran compiler, the Fortran Package Manager, or any great numerical computing library. Everyone has some talents: maybe you are good at writing documentation, or at translating, or you have communication talents, or you can teach Fortran, etc. For example, concerning documentation the same paper says:
Many of the documentation committers started out by doing translations of documents into their native language. This translation task often helped them get up to speed both on how the documentation tools worked and how FreeBSD itself worked.
You can also report bugs in Fortran tools, or point out what is missing in the fpm documentation, edit fortranwiki.org or Fortran related Wikipedia pages, etc. Every small task adds up to the whole.
I stumbled into the end-of-day hackathon portion of the FreeBSD Developer’s Conference. I was impressed to observe McKusick collaboratively coding with someone who must have been at least forty years younger than he. The spirit of working to keep the BSD operating system projects multigenerational ran through the entirety of BSDCan. The oldest, most accomplished participants, who might have had legitimate reasons to ignore neophytes, especially outsiders (as I was), treated me as a worthy discussion partner
Same here, I appreciate that the Fortran Discourse is mixing all generations. And I hope neophytes feel the same spirit when they arrive here.