It's massively strange that this was closed source while at a public university, and open source under a public company.

US universities have entire departments devoted to technology licensing. The default to secrecy may be an artifact of their historic reliance on defense agency funding for technical projects and the bureaucratic staffing for paperwork heavy processes.

On the other hand, there's an intellectual idea that for many companies, existing software should perhaps be seen as a liability in double entry accounting due to it's need for ongoing maintenance, upgrades, potential for catastrophic failure, and the cost associated with alterations for new business processes.

Companies offload some of those costs by open sourcing and allowing developers to happily "give back" to their bottom line.

Can you explain that a bit more? How does a company offload costs by freeing their software? Surely they're not expecting to rely on public contributions to reduce maintenance costs, are they?

Even at its most basic, an arbitrary developer filing a bug report is potentially less costly to handle than a customer experiencing a failure...it can be ignored and maybe the developer submits a patch.

On a longer timeline, hiring developers experienced in the technology from the open source community saves on the cost of training them for a proprietary code base.

Ideally, the open source community develops new features, identifies and patchs bugs, writes tests and libraries, etc. adding value realized by the company's paying customers. In the meantime the company still can devote staff to its business priorities and ignore those of the larger community: e.g. no `map` in go-lang and no `react new myapp` at the CLI for React.

To put it another way, why would a business open source code for anything other than business reasons?

It actually predates Dybvig's time at Indiana; he started writing it as part of his PhD work at UNC Chapel Hill. Plus, he set up Cadence Research Systems for licensing Chez Scheme, so it was never owned by any university.

The part where Cisco open sourced it is a bit unusual, but it's not uncommon for people to close source and sell systems they create during college or grad school and continue to use them in research.

It wasn't quite developed at Indiana University. It's based on research that was done at Indiana University, but the actual development was done by a spinoff company, Cadence Research Systems. Vaguely similar arrangement to how the original Google was "developed at Stanford" in the loose sense of being based on research the founders did while at Stanford, but it was owned by a spinoff company.

I'm very excited about this. I've been using Chez as my performance benchmark target for my own Scheme implementation.

Scheme user here. I'm very excited about this, and I think I just changed my vacation plans for next week :D

Can't say (yet). I've used a number of implementations: Gambit, MIT Scheme, PLT/Racket, and played around with Chicken. But never Chez, because it wasn't free.

And aside from the JVM implementations and some works in progress the last time I checked, the only one with native instead of green threading.

Well, dfsch is currently not work in progress, because there is no meaningful progress :) But it was originally intended as scheme interpreter with native threading without GIL. Last version has GIL-style global lock, but interpreter threads can run user code without ever acquiring that lock. (In essence: the lock protect structures that cannot be proven to not be shared between threads, which are not required to interpret output of dfsch's compiler for most inputs)

I know Gauche uses pthreads because I got a linker error about it one time ;)

Also, does Gambit not support native threads? That's surprising considering Marc Feeley did quite a bit of research on multiprocessing in Scheme, and he wrote the SRFI for threads.

GNU Guile has pthreads.

Racket has native threads, called "places".

Not in the shared memory way I mean (which I did not make clear), per http://docs.racket-lang.org/guide/parallelism.html

The racket/place library provides support for performance improvement through parallelism with the place form. The place form creates a place, which is effectively a new Racket instance that can run in parallel to other places, including the initial place. The full power of the Racket language is available at each place, but places can communicate only through message passing—using the place-channel-put and place-channel-get functions on a limited set of values—which helps ensure the safety and independence of parallel computations.

Compare to current Guile, where the documentation says sharing a hash table without using a mutex will not corrupt memory, but probably won't give you the results you desire.