SourceForge is one of the main development and repository sites for Open Source software, and late last year their community voted to make Minsky its Project of the Month for January 2014.
We (myself and Dr Russell Standish, who is the chief programmer for Minsky) were delighted of course: it’s a public affirmation that the project is useful and respected by a very critical audience: other developers of Open Source software. Here is the interview SourceForge conducted with us, which is published on its blog.
SourceForge: Tell us about the Minsky project please…
Minsky Team: Bizarre as it may seem, maintream economic theory ignores banks, debt and money completely, and imagines that the dynamic, innovative and crisis-prone social system we call capitalism can be modelled as if it is almost always in equilibrium. It’s little wonder therefore that most economists didn’t see the financial crisis coming back in 2007.
The designer of Minsky, Dr. Steve Keen, did anticipate the crisis, based on a dynamic monetary model of a possible financial crisis that he developed back in 1992.
The model put into mathematical form the economic approach of the rebel American economist Hyman Minsky, and the program Minsky was named in his honor. Minsky was designed to make a different approach to economic modeling possible: one in which banks, debt and money are indispensible, and in which the economy is always changing. To do that, we built on the established tradition of system dynamics embodied in programs like Xcos, which use flowcharts to build dynamic models of real-world processes.
The flowchart paradigm is fine for physical flows but problematic for financial flows, because the same transaction—say buying goods from a store when its deposit account is in a different bank—has to be recorded in at least four different places: once as a deduction from your account, once as an addition to the store’s, and twice more as a transfer of reserves from your bank to the seller’s bank. 
Because of the multiple entries needed to properly represent financial flows, modeling using the flowchart paradigm rapidly generates a “spaghetti code” of intersecting wires that is effectively unintelligible. Minsky solves this problem by adding a second method to generate dynamic equations for financial flows. This is a spreadsheet-like double entry bookkeeping system, which we call them “Godley Tables” in honor of a pioneer in monetary economics Wynne Godley.
SF: What made you start this?
Minsky Team: The Godley table feature is new, so either needed to be implemented within an existing open source dynamic systems modelling tool, or we had to create the modelling tool de novo. The main OSS system dynamics program Xcos is based on the commercial program Simulink, and even as experienced developers we found the user interface difficult (we became aware of another Open Source program—Insight Maker—after starting the Minsky project, and we’re exploring the possibility of sharing code and approaches here).
So we decided to implement Minsky from scratch in C++ and Tcl/Tk. By doing so we’ve been able to implement “best of breed” ideas from the spectrum of system dynamics tools, and introduce some of our own ideas too. Similar to the commercial program Vissim, Minsky uses variable names as well as wires to pass values, and in addition we enable easy conversion between constants, parameters, variables and integral variables, so that a model can start simple and be made more complex and accurate over time. We also can export a model’s equations to LaTeX, which is essential for academic publishing. To our knowledge, no other system dynamics program does this.
SF: Has your original vision been achieved?
Minsky Team: Yes, although the original vision is only a fraction of what we hope to implement with future development. The original objective was to make it possible to develop dynamic monetary macroeconomic models with both physical and financial flows. That has now been achieved, though some features—for example creating groups and local variables, graphics and data display—are still at an early stage. Overall however we think it’s the easiest system dynamics program to use, and the only one that makes it feasible to model financial as well as physical flows.
SF: Who can benefit the most from Minsky?
Minsky Team: Anyone who has an interest in dynamical systems modelling—from chaos theory, to economics and biological modelling—can use and benefit from Minsky. We’ve easily implemented classic chaotic models in Minsky—the Lorenz attractor, Duffing Chaos etc.—and you can run them in real time, and change parameters as they run.
It would suit mathematics lecturers and students too, as a means to visualize dynamic models and mathematical functions in general. Those who can benefit the most are people who want to understand the financial system and monetary flows. We hope in time that it will be adopted by universities as a teaching tool, and by Central Banks and Treasuries as a means to build realistic models of the economy in which finance and banking play integral roles—in contrast to existing “DSGE” models, 99% of which ignore banking completely.
SF: What’s the best way to get the most out of using Minsky?
Minsky Team: Take a look at the examples, as well as the many videos Steve Keen has made on constructing models—which are available on his YouTube Channel (http://www.youtube.com/ProfSteveKeen).
SF: What was the first big thing that happened for your project?
Minsky Team: The project would not have been possible without an original grant of $128,000 from INET (the Institute for New Economic Thinking). This allowed us to create the first couple of releases of Minsky (named “Aristotle” and “Aquinas” after early thinkers on topics economic and philosophical) which resulted in a usable, but still pretty basic, program. Then a successful Kickstarter campaign in February this year allowed the next two releases Petty and Mun, which improved the usability of the software, and allowed more complex systems to be simulated.
SF: What helped make that happen?
Minsky Team: Steve Keen, the chief designer of Minsky, was a Professor of Economics who is also a well-known critic of conventional economic theory, with a popular book Debunking Economics and an influential blog Steve Keen’s Debtwatch. INET respected his work and were happy to give the initial grant, while his public profile led to a substantial sum being raised from the public via Kickstarter.
SF: What was the net result for that event?
Minsky Team: The net result is that Minsky now fulfils its basic promise—to be able to build dynamic models in general, and in particular to build monetary models of the economy. There are still some rough edges at this level since less than 3000 hours of programming has gone into its development so far, but we’re confident that it is relatively bug-free and will work as intended right now—though we hope to add much more polish and far more modeling power in future releases.
SF: What is the next big thing for Minsky?
Minsky Team: This depends on getting substantial additional funding for programming, but after some more work refining the interface, we intend extending its ability to model the economy by enabling it to represent an economy as a number of industrial sectors, each of which buys inputs from and sells output to the others.
Then we will add the ability to model international trade and financial flows between different national economies. We have already done proof-of-concept modeling of multi-sectoral monetary models in Mathcad and Mathematica, so we know this can be done. Simultaneously we will add the capability to import economic data and to derive system parameters from data using nonlinear parameter estimation techniques.
We have some ideas on how to represent and manipulate statistical data that are also novel and we hope will give Minsky appeal to data analysts as well. We also plan to add two additional ways to model dynamic systems: direct entry of equations in a TeX-like interface and what is known as a “Social Accounting Matrix” (SAM), which also ensures model consistency. There would be each-way conversion between these three design methods—so equations would be converted to flowchart diagrams and SAM entries automatically, and vice versa.
SF: How long do you think that will take?
Minsky Team: If we can get a team of about half a dozen programmers working full-time, it could be completed within 2–3 years.
SF: Do you have the resources you need to make that happen?
Minsky Team: Not at present! Though there are some offers of funding that may come our way—we’ll let you know if they do! This is not your standard Open Source project where programmers with an innate interest in the topic are plentiful, or where corporations see it as in their interests to let their programmers develop a tool: very few economists have any skills in computing at all, and only a handful of economists are non-orthodox in their approach and therefore interested in dynamic monetary modeling. So we do rely on being able to hire programming talent.
Minsky has come so far so quickly because of the happenstance that the non-orthodox economist Steve Keen and the high-performance computing programmer Russell Standish have been friends and research collaborators for almost two decades. We have also been assisted by a volunteer programmer in the USA, and some capable freelancers in Russia and France.
SF: If you had it to do over again, what would you do differently for Minsky?
Minsky Team: The only thing that might have been better would be to program in an environment that generated code for multiple platforms easily. TCL/Tk was chosen due to existing expertise, its inbuilt canvas functionality, and its ability to get something working quickly. But it has limitations in terms of platforms supported (basically Windows, MacOS Aqua and X11), when tablets and web browsers are desirable targets for the future.
SF: Why?
Minsky Team: A lot of time has been wasted writing specific routines to circumvent idiosyncracies in Windows and Mac for this cross-platform software, which is probably the case with any cross platform GUI framework. Moreover, substantial effort was required to get adequate graphics performance, which has not translated onto the Macintosh, because Tk is written using the old Quickdraw API, and not easily adapted to using the more modern Cocoa API.
Furthermore, some means of targetting Android, iOS and Web browsers is also desirable going forward, so investigating other GUI toolkits is desirable.
But apart from that we didn’t take any wrong turns that we later had to reverse. It’s been a pretty smooth development process so far.
SF: Any reason you can’t do that now?
Minsky Team: Mostly because user functionality on standard PCs/workstations has trumped porting the software to these other platforms.The only thing that might have been better would be to program in an environment that generated code for multiple platforms easily. TCL/Tk was chosen due to existing expertise, its inbuilt canvas functionality, and its ability to get something working quickly. But it has limitations in terms of platforms supported (basically Windows, MacOS Aqua and X11), when tablets and web browsers are desirable targets for the future.
SF: Why?
Minsky Team: A lot of time has been wasted writing specific routines to circumvent idiosyncracies in Windows and Mac for this cross-platform software, which is probably the case with any cross platform GUI framework. Moreover, substantial effort was required to get adequate graphics performance, which has not translated onto the Macintosh, because Tk is written using the old Quickdraw API, and not easily adapted to using the more modern Cocoa API.
Furthermore, some means of targetting Android, iOS and Web browsers is also desirable going forward, so investigating other GUI toolkits is desirable.
But apart from that we didn’t take any wrong turns that we later had to reverse. It’s been a pretty smooth development process so far.
SF: Any reason you can’t do that now?
Minsky Team: Mostly because user functionality on standard PCs/workstations has trumped porting the software to these other platforms.
SF: A significant portion of our community are interested in digital currencies such as Bitcoin. Is it possible to model such a currency in Minsky, and if so what interesting questions might be answered?
Minsky Team: Bitcoin is a peer-to-peer system, meaning that transfers from one individual to another don’t go through a bank. That would be easy to model in Minsky. And there’d be a reservoir of Bitcoins with 21 million in existence, a fraction of those in circulation, a variable but slow rate of extraction, and so on.
The exchanges would also be relatively easy to model—though you’d need to have a price for Bitcoin in relation to the local fiat currency. The volatility of this price could be simulated as well.
The issues that would be harder to capture involve things like whether competitors to Bitcoin would spring up because of Bitcoin’s success, whether its popularity might wane as a result, whether its penetration becomes universal (100% of people having a bitcoin account), or not. Overall we think that multi-agent models and contagion-oriented modeling might work better on those issues than Minsky.
With sufficient funding and programming support, multi-agent capabilities could be added to our current system dynamics toolkit. Much of Minsky was based on Russell Standish’s Ecolabproject, which is a multi-agent modeling system, so the code base already exists.
SF: It seems that the economic models designed in Minsky can become quite complex, and can benefit from the features of open source – many eyes to identify bugs in the model, forking a model to bring more detail to a specific economic sector, and then sharing that fork back to a central model bank. Do you foresee one, or a few, detailed models evolving along those lines, and being shared among many users to do research? Or do you anticipate many independent, ad-hoc models being used?
Minsky Team: We want to develop a database for users and model development and sharing—and in fact one was developed by student programmers as part of a web-based version of Minsky. That part of the project is on hold given lack of funding, but the code for real-time simultaneous development of the same model on multiple computers works.
We expect to see a whole eco-system of models, some at quite basic levels for teaching or exploring specific issues, others which will be extremely sophisticated and will definitely need “many eyes” for both development and de-bugging.
SF: What’s the best example of “stability is destabilizing” that you’ve seen from the Minsky software so far?
Minsky Team: The best instance so far is a monetary version of Keen’s 1992 model in which price deflation amplifies the trend to instability. The final crisis is a downward collapse due to private debt falling less rapidly than GDP collapses due to no investment and deflation—which is what happened in the Great Depression. As with the 1992 model, the crisis is preceded by a decline in the volatility of employment, and also inflation—as happened in the real world—and workers’ share of income falls as well.
This model is incomplete—there are inconsistencies in the monetary and physical flow components—but it shows the capacity of genuinely monetary dynamic models of capitalism to capture its behavior in way that the standard non-monetary models cannot.
SF: Is there anything else we should know?
Minsky Team: Yes. We’d love to develop a substantial user community, and that community could help us develop both examples and a comprehensive help system. We’ve been deficient on this front because the development team is so small.
SF: Congratulations to you all on this excellent bit of work, not only for the OSS community, but for folks looking to utilize such modeling systems.
You can download the latest version of Minsky from here.
Check out the download statistics from here.
