Minsky is SourceForge’s Project of the Month

flattr this!

Source­Forge is one of the main devel­op­ment and repos­i­tory sites for Open Source soft­ware, and late last year their com­mu­nity voted to make Min­sky its Project of the Month for Jan­u­ary 2014.

SourceForgeCommunityChoice

We (myself and Dr Rus­sell Stan­dish, who is the chief pro­gram­mer for Min­sky) were delighted of course: it’s a pub­lic affir­ma­tion that the project is use­ful and respected by a very crit­i­cal audi­ence: other devel­op­ers of Open Source soft­ware. Here is the inter­view Source­Forge con­ducted with us, which is pub­lished on its blog.

SourceForgeBlog

Source­Forge: Tell us about the Min­sky project please…

Min­sky Team: Bizarre as it may seem, main­tream eco­nomic the­ory ignores banks, debt and money com­pletely, and imag­ines that the dynamic, inno­v­a­tive and crisis-prone social sys­tem we call cap­i­tal­ism can be mod­elled as if it is almost always in equi­lib­rium. It’s lit­tle won­der there­fore that most econ­o­mists didn’t see the finan­cial cri­sis com­ing back in 2007.

The designer of Min­sky, Dr. Steve Keen, did antic­i­pate the cri­sis, based on a dynamic mon­e­tary model of a pos­si­ble finan­cial cri­sis that he devel­oped back in 1992.

 The model put into math­e­mat­i­cal form the eco­nomic approach of the rebel Amer­i­can econ­o­mist Hyman Min­sky, and the pro­gram Min­sky was named in his honor.  Min­sky was designed to make a dif­fer­ent approach to eco­nomic mod­el­ing pos­si­ble: one in which banks, debt and money are indis­pen­si­ble, and in which the econ­omy is always chang­ing. To do that, we built on the estab­lished tra­di­tion of sys­tem dynam­ics embod­ied in pro­grams like Xcos, which use flow­charts to build dynamic mod­els of real-world processes.

The flow­chart par­a­digm is fine for phys­i­cal flows but prob­lem­atic for finan­cial flows, because the same transaction—say buy­ing goods from a store when its deposit account is in a dif­fer­ent bank—has to be recorded in at least four dif­fer­ent places: once as a deduc­tion from your account, once as an addi­tion to the store’s, and twice more as a trans­fer of reserves from your bank to the seller’s bank. 

Because of the mul­ti­ple entries needed to prop­erly rep­re­sent finan­cial flows, mod­el­ing using the flow­chart par­a­digm rapidly gen­er­ates a “spaghetti code” of inter­sect­ing wires that is effec­tively unin­tel­li­gi­ble.  Min­sky solves this prob­lem by adding a sec­ond method to gen­er­ate dynamic equa­tions for finan­cial flows. This is a spreadsheet-like dou­ble entry book­keep­ing sys­tem, which we call them “God­ley Tables” in honor of a pio­neer in mon­e­tary eco­nom­ics Wynne Godley.

SF: What made you start this?

Min­sky Team: The God­ley table fea­ture is new, so either needed to be imple­mented within an exist­ing open source dynamic sys­tems mod­el­ling tool, or we had to cre­ate the mod­el­ling tool de novo.  The main OSS sys­tem dynam­ics pro­gram Xcos is based on the com­mer­cial pro­gram Simulink, and even as expe­ri­enced devel­op­ers we found the user inter­face dif­fi­cult (we became aware of another Open Source program—Insight Maker—after start­ing the Min­sky project, and we’re explor­ing the pos­si­bil­ity of shar­ing code and approaches here).

So we decided to imple­ment Min­sky from scratch in C++ and Tcl/Tk. By doing so we’ve been able to imple­ment “best of breed” ideas from the spec­trum of sys­tem dynam­ics tools, and intro­duce some of our own ideas too.  Sim­i­lar to the com­mer­cial pro­gram Vis­sim, Min­sky uses vari­able names as well as wires to pass val­ues, and in addi­tion we enable easy con­ver­sion between con­stants, para­me­ters, vari­ables and inte­gral vari­ables, so that a model can start sim­ple and be made more com­plex and accu­rate over time.  We also can export a model’s equa­tions to LaTeX, which is essen­tial for aca­d­e­mic pub­lish­ing. To our knowl­edge, no other sys­tem dynam­ics pro­gram does this.

SFHas your orig­i­nal vision been achieved?

Min­sky Team: Yes, although the orig­i­nal vision is only a frac­tion of what we hope to imple­ment with future devel­op­ment. The orig­i­nal objec­tive was to make it pos­si­ble to develop dynamic mon­e­tary macro­eco­nomic mod­els with both phys­i­cal and finan­cial flows. That has now been achieved, though some features—for exam­ple cre­at­ing groups and local vari­ables, graph­ics and data display—are still at an early stage.  Over­all how­ever we think it’s the eas­i­est sys­tem dynam­ics pro­gram to use, and the only one that makes it fea­si­ble to model finan­cial as well as phys­i­cal flows.

SFWho can ben­e­fit the most from Minsky?

Min­sky Team: Any­one who has an inter­est in dynam­i­cal sys­tems modelling—from chaos the­ory, to eco­nom­ics and bio­log­i­cal modelling—can use and ben­e­fit from Min­sky. We’ve eas­ily imple­mented clas­sic chaotic mod­els in Minsky—the Lorenz attrac­tor, Duff­ing Chaos etc.—and you can run them in real time, and change para­me­ters as they run.

It would suit math­e­mat­ics lec­tur­ers and stu­dents too, as a means to visu­al­ize dynamic mod­els and math­e­mat­i­cal func­tions in gen­eral.  Those who can ben­e­fit the most are peo­ple who want to under­stand the finan­cial sys­tem and mon­e­tary flows. We hope in time that it will be adopted by uni­ver­si­ties as a teach­ing tool, and by Cen­tral Banks and Trea­suries as a means to build real­is­tic mod­els of the econ­omy in which finance and bank­ing play inte­gral roles—in con­trast to exist­ing “DSGE” mod­els, 99% of which ignore bank­ing completely.

SFWhat’s the best way to get the most out of using Minsky?

Min­sky Team: Take a look at the exam­ples, as well as the many videos Steve Keen has made on con­struct­ing models—which are avail­able on his YouTube Chan­nel (http://www.youtube.com/ProfSteveKeen).

SFWhat was the first big thing that hap­pened for your project?

Min­sky Team: The project would not have been pos­si­ble with­out an orig­i­nal grant of $128,000 from INET (the Insti­tute for New Eco­nomic Think­ing). This allowed us to cre­ate the first cou­ple of releases of Min­sky (named “Aris­to­tle” and “Aquinas” after early thinkers on top­ics eco­nomic and philo­soph­i­cal) which resulted in a usable, but still pretty basic, pro­gram.  Then a suc­cess­ful Kick­starter cam­paign in Feb­ru­ary this year allowed the next two releases Petty and Mun, which improved the usabil­ity of the soft­ware, and allowed more com­plex sys­tems to be simulated.

SF: What helped make that happen?

Min­sky Team: Steve Keen, the chief designer of Min­sky, was a Pro­fes­sor of Eco­nom­ics who is also a well-known critic of con­ven­tional eco­nomic the­ory, with a pop­u­lar book Debunk­ing Eco­nom­ics and an influ­en­tial blog Steve Keen’s Debt­watch. INET respected his work and were happy to give the ini­tial grant, while his pub­lic pro­file led to a sub­stan­tial sum being raised from the pub­lic via Kickstarter.

SF: What was the net result for that event?

Min­sky Team: The net result is that Min­sky now ful­fils its basic promise—to be able to build dynamic mod­els in gen­eral, and in par­tic­u­lar to build mon­e­tary mod­els of the econ­omy. There are still some rough edges at this level since less than 3000 hours of pro­gram­ming has gone into its devel­op­ment so far, but we’re con­fi­dent that it is rel­a­tively bug-free and will work as intended right now—though we hope to add much more pol­ish and far more mod­el­ing power in future releases.

SF: What is the next big thing for Minsky?

Min­sky Team: This depends on get­ting sub­stan­tial addi­tional fund­ing for pro­gram­ming, but after some more work refin­ing the inter­face, we intend extend­ing its abil­ity to model the econ­omy by enabling it to rep­re­sent an econ­omy as a num­ber of indus­trial sec­tors, each of which buys inputs from and sells out­put to the others.

Then we will add the abil­ity to model inter­na­tional trade and finan­cial flows between dif­fer­ent national economies.  We have already done proof-of-concept mod­el­ing of multi-sectoral mon­e­tary mod­els in Math­cad and Math­e­mat­ica, so we know this can be done.  Simul­ta­ne­ously we will add the capa­bil­ity to import eco­nomic data and to derive sys­tem para­me­ters from data using non­lin­ear para­me­ter esti­ma­tion techniques.

We have some ideas on how to rep­re­sent and manip­u­late sta­tis­ti­cal data that are also novel and we hope will give Min­sky appeal to data ana­lysts as well.  We also plan to add two addi­tional ways to model dynamic sys­tems: direct entry of equa­tions in a TeX-like inter­face and what is known as a “Social Account­ing Matrix” (SAM), which also ensures model con­sis­tency. There would be each-way con­ver­sion between these three design methods—so equa­tions would be con­verted to flow­chart dia­grams and SAM entries auto­mat­i­cally, and vice versa.

SF: How long do you think that will take?

Min­sky Team: If we can get a team of about half a dozen pro­gram­mers work­ing full-time, it could be com­pleted within 2–3 years.

SF: Do you have the resources you need to make that happen?

Min­sky Team: Not at present! Though there are some offers of fund­ing that may come our way—we’ll let you know if they do! This is not your stan­dard Open Source project where pro­gram­mers with an innate inter­est in the topic are plen­ti­ful, or where cor­po­ra­tions see it as in their inter­ests to let their pro­gram­mers develop a tool: very few econ­o­mists have any skills in com­put­ing at all, and only a hand­ful of econ­o­mists are non-orthodox in their approach and there­fore inter­ested in dynamic mon­e­tary mod­el­ing. So we do rely on being able to hire pro­gram­ming talent.

Min­sky has come so far so quickly because of the hap­pen­stance that the non-orthodox econ­o­mist Steve Keen and the high-performance com­put­ing pro­gram­mer Rus­sell Stan­dish have been friends and research col­lab­o­ra­tors for almost two decades. We have also been assisted by a vol­un­teer pro­gram­mer in the USA, and some capa­ble free­lancers in Rus­sia and France.

SFIf you had it to do over again, what would you do dif­fer­ently for Minsky?

Min­sky Team: The only thing that might have been bet­ter would be to pro­gram in an envi­ron­ment that gen­er­ated code for mul­ti­ple plat­forms eas­ily. TCL/Tk was cho­sen due to exist­ing exper­tise, its inbuilt can­vas func­tion­al­ity, and its abil­ity to get some­thing work­ing quickly. But it has lim­i­ta­tions in terms of plat­forms sup­ported (basi­cally Win­dows, MacOS Aqua and X11), when tablets and web browsers are desir­able tar­gets for the future.

SFWhy?

Min­sky Team: A lot of time has been wasted writ­ing spe­cific rou­tines to cir­cum­vent idio­syn­cra­cies in Win­dows and Mac for this cross-platform soft­ware, which is prob­a­bly the case with any cross plat­form GUI frame­work. More­over, sub­stan­tial effort was required to get ade­quate graph­ics per­for­mance, which has not trans­lated onto the Mac­in­tosh, because Tk is writ­ten using the old Quick­draw API, and not eas­ily adapted to using the more mod­ern Cocoa API.

Fur­ther­more, some means of tar­get­ting Android, iOS and Web browsers is also desir­able going for­ward, so inves­ti­gat­ing other GUI toolk­its 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 devel­op­ment process so far.

SFAny rea­son you can’t do that now?

Min­sky Team: Mostly because user func­tion­al­ity on stan­dard PCs/workstations has trumped port­ing the soft­ware to these other platforms.The only thing that might have been bet­ter would be to pro­gram in an envi­ron­ment that gen­er­ated code for mul­ti­ple plat­forms eas­ily. TCL/Tk was cho­sen due to exist­ing exper­tise, its inbuilt can­vas func­tion­al­ity, and its abil­ity to get some­thing work­ing quickly. But it has lim­i­ta­tions in terms of plat­forms sup­ported (basi­cally Win­dows, MacOS Aqua and X11), when tablets and web browsers are desir­able tar­gets for the future.

SFWhy?

Min­sky Team: A lot of time has been wasted writ­ing spe­cific rou­tines to cir­cum­vent idio­syn­cra­cies in Win­dows and Mac for this cross-platform soft­ware, which is prob­a­bly the case with any cross plat­form GUI frame­work. More­over, sub­stan­tial effort was required to get ade­quate graph­ics per­for­mance, which has not trans­lated onto the Mac­in­tosh, because Tk is writ­ten using the old Quick­draw API, and not eas­ily adapted to using the more mod­ern Cocoa API.

Fur­ther­more, some means of tar­get­ting Android, iOS and Web browsers is also desir­able going for­ward, so inves­ti­gat­ing other GUI toolk­its 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 devel­op­ment process so far.

SFAny rea­son you can’t do that now?

Min­sky Team: Mostly because user func­tion­al­ity on stan­dard PCs/workstations has trumped port­ing the soft­ware to these other platforms.

SFA sig­nif­i­cant por­tion of our com­mu­nity are inter­ested in dig­i­tal cur­ren­cies such as Bit­coin. Is it pos­si­ble to model such a cur­rency in Min­sky, and if so what inter­est­ing ques­tions might be answered?

Min­sky Team: Bit­coin is a peer-to-peer sys­tem, mean­ing that trans­fers from one indi­vid­ual to another don’t go through a bank. That would be easy to model in Min­sky. And there’d be a reser­voir of Bit­coins with 21 mil­lion in exis­tence, a frac­tion of those in cir­cu­la­tion, a vari­able but slow rate of extrac­tion, and so on.

The exchanges would also be rel­a­tively easy to model—though you’d need to have a price for Bit­coin in rela­tion to the local fiat cur­rency. The volatil­ity of this price could be sim­u­lated as well.

The issues that would be harder to cap­ture involve things like whether com­peti­tors to Bit­coin would spring up because of Bitcoin’s suc­cess, whether its pop­u­lar­ity might wane as a result, whether its pen­e­tra­tion becomes uni­ver­sal (100% of peo­ple hav­ing a bit­coin account), or not. Over­all we think that multi-agent mod­els and contagion-oriented mod­el­ing might work bet­ter on those issues than Minsky.

With suf­fi­cient fund­ing and pro­gram­ming sup­port, multi-agent capa­bil­i­ties could be added to our cur­rent sys­tem dynam­ics toolkit. Much of Min­sky was based on Rus­sell Standish’s Eco­labproject, which is a multi-agent mod­el­ing sys­tem, so the code base already exists.

SFIt seems that the eco­nomic mod­els designed in Min­sky can become quite com­plex, and can ben­e­fit from the fea­tures of open source – many eyes to iden­tify bugs in the model, fork­ing a model to bring more detail to a spe­cific eco­nomic sec­tor, and then shar­ing that fork back to a cen­tral model bank. Do you fore­see one, or a few, detailed mod­els evolv­ing along those lines, and being shared among many users to do research? Or do you antic­i­pate many inde­pen­dent, ad-hoc mod­els being used?

Min­sky Team: We want to develop a data­base for users and model devel­op­ment and sharing—and in fact one was devel­oped by stu­dent pro­gram­mers as part of a web-based ver­sion of Min­sky. That part of the project is on hold given lack of fund­ing, but the code for real-time simul­ta­ne­ous devel­op­ment of the same model on mul­ti­ple com­put­ers works.

We expect to see a whole eco-system of mod­els, some at quite basic lev­els for teach­ing or explor­ing spe­cific issues, oth­ers which will be extremely sophis­ti­cated and will def­i­nitely need “many eyes” for both devel­op­ment and de-bugging.

SFWhat’s the best exam­ple of “sta­bil­ity is desta­bi­liz­ing” that you’ve seen from the Min­sky soft­ware so far?

Min­sky Team: The best instance so far is a mon­e­tary ver­sion of Keen’s 1992 model in which price defla­tion ampli­fies the trend to insta­bil­ity. The final cri­sis is a down­ward col­lapse due to pri­vate debt falling less rapidly than GDP col­lapses due to no invest­ment and deflation—which is what hap­pened in the Great Depres­sion. As with the 1992 model, the cri­sis is pre­ceded by a decline in the volatil­ity of employ­ment, and also inflation—as hap­pened in the real world—and work­ers’ share of income falls as well.

This model is incomplete—there are incon­sis­ten­cies in the mon­e­tary and phys­i­cal flow components—but it shows the capac­ity of gen­uinely mon­e­tary dynamic mod­els of cap­i­tal­ism to cap­ture its behav­ior in way that the stan­dard non-monetary mod­els cannot.

SF: Is there any­thing else we should know?

Min­sky Team: Yes. We’d love to develop a sub­stan­tial user com­mu­nity, and that com­mu­nity could help us develop both exam­ples and a com­pre­hen­sive help sys­tem. We’ve been defi­cient on this front because the devel­op­ment team is so small.

SFCon­grat­u­la­tions to you all on this excel­lent bit of work, not only for the OSS com­mu­nity, but for folks look­ing to uti­lize such mod­el­ing systems.

You can down­load the lat­est ver­sion of Min­sky from here.

Check out the down­load sta­tis­tics from here.

About Steve Keen

I am a professional economist and a long time critic of conventional economic thought. As well as attacking mainstream thought in Debunking Economics, I am also developing an alternative dynamic approach to economic modelling. The key issue I am tackling here is the prospect for a debt-deflation on the back of the enormous debts accumulated in Australia, and our very low rate of inflation.
Bookmark the permalink.

2 Responses to Minsky is SourceForge’s Project of the Month

  1. Derek R says:

    That’s good news, Steve. Congratulations!

  2. Pingback: Minsky is SourceForge’s Project of the Mo...

Leave a Reply