* Licensing - if you use one of the installers (for OSX or Windows) you're presented with the GPL3 as part of the installation process.

* Mac OSX package (and to the same extent, the Windows installer) - Mu comes with everything bundled in so you don't have to mess around installing a bunch of stuff to make it work. We did it this way after asking for feedback from school network administrators who always said some variation of "make my life as simple as possible". Mu is only just less than 4k lines of Python so, you're right in thinking that the rest of the installer is Qt and a bunch of other stuff (like Tk/tkinter, needed for Python's turtle module to work, something many teachers have told us they need). We also bundle PyGame, iPython, Matplotlib, Numpy etc etc... so they're just there by default if you simply install Mu. In this sense, Mu is a sort of "instant Python for education" (just add learners). ;-)

* Bundling - I'm happy for Mu to be bundled if this were useful to another project although I guess this depends upon what use case you're thinking of. For example, Mu is already "bundled" (in a sense) in Raspbian as a recommended package. If in doubt, just reach out.

Seems like not that big of a deal considering it’s geared towards beginner programmers?

Regarding state/flow... that's partially handled by the visual debugger in Python3 mode (I explain this in a beginner friendly way here: https://codewith.mu/en/tutorials/1.0/debugger).

There could be lots of ways to do state/flow, but implementing a very simple debugger has the additional advantage of progression: it's a powerful tool coders will come to use with professional development environments as they grow in skill. I made the debugger very much with the Alan Kay quote referenced here (https://codewith.mu/en/about) in mind.

FWIW, I'm actually a classically trained musician (I trained at the Royal College of Music in London and played professionally for a number of years), and spent most of my 20s involved in music education. Music education has so much to teach computing education (although I concede I'm probably biased in this opinion) and I wanted to ape the "do the real thing, but at the right level" approach music educators (like my wife) do. She's a cellist and often runs workshops with kids as young as 5 who want to learn to play a string instrument. The first thing she does? She gives them a real string instrument (although it may be a 1/4 sized violin or cello - it's still a proper instrument) and lets them play (in both fun and musical sense of the word).

It turns out that if you want to be a musician, you have to learn to do things musicians do. Likewise, if you want to write software, it's probably a good idea to learn what software developers do.

Having said that, I like the innovation and shift of perspective from people like Bret Victor, so as always, it's a balancing act. We want people to learn about the rules, traditions and history of [music|coding] so they can become effective participants in the current world of [music|code] but then we also want them to innovate, experiment and push boundaries. This sense of breaking rules should definitely be part of education.

I hope this makes sense... :-)

This is but a start and I expect Mu will evolve as computing education matures (hopefully) beyond the current state of affairs.

The rational for deciding features is three-fold:

* A positive answer to, "is it going to make it easy for a beginner to write, execute and change code?" is the first requirement (we check this with user research -- I've observed lessons, code clubs and other beginner-related activities as well as interviewed teachers and learners to find out how they react).

* Alternatively, we checked the features the Raspberry Pi Foundation had feedback about. For instance, the zoom in/out buttons were one of the most requested features from teachers in feedback to the RPi education team. When I demoed this to teachers for the first time there were gasps of amazement (which made me smile, given what a simple / easy to implement feature this is). This is extraordinarily useful in a classroom situation and for learners who may have a visual impairment (such as older learners with bad eyesight... a group I had never initially thought would want to learn... but hey... I rather like the idea of Granny coding Python). ;-)

* Can we demonstrate an obvious progression from Mu's (simple) implementation to a similar feature in an editor to which the user is likely to graduate? For example, the visual debugger is very simple, but looks similar enough to a "proper" debugger in a professional IDE that a beginner graduating to such an environment won't feel out of their depth.

Once a feature is "in" a lot of time and effort is spent making it as simple yet useful as possible. This is likely to be the first time someone will have used such a feature and we need to ensure that the intention is clear, the use is obvious and the outcome useful from the perspective of the learner/teacher.

We also have a "rule of three" when it comes to "nice to have" features... if three people independently ask for something we try to implement it (a good example being toggling on/off of commenting).