Too much choice can sometimes be just as bad as not enough. Market research has shown that there is an optimal number of jam flavours a supermarket should have on shelf for its customers—less than that, and you feel constrained; but more than that and the variety confuses you.A recent paper in Energy and Buildings reminded me of the bewildering variety of building simulation software packages available today, many of them free of charge. The paper describes the International Building Physics Toolbox, a software library for Simulink that provides all the building blocks you need to simulate heat, air and moisture in buildings.

A Simulink library for building physics is an excellent thing—the flexibility and speed of model development more than make up for the library’s slower execution speed, compared with software written in more pedestrian environments. And Simulink/Matlab provide an environment that can directly execute Java code, enabling developers to extend these building models with their own Java programs. For example, code running in a separate process—possibly on a remote machine—can interact with the building simulation while it runs through e.g. the Java RMI library.

But the IBPT is now the second building simulation package for Simulink that I hear about. The first was SIMBAD, which I used in my doctoral work. The IBPT paper mentions yet another, CARNOT. Nowhere does the paper discuss the pros and cons of each of these packages, and the readers are left to do their own research. Will a healthy, thriving community adopt the IBPT and maintain it, or will it fizzle out? There is no way to know.

I will, however, boldly suggest two criteria that may predict the success of a building simulation package. The first is that it must be developed by programmers, not by scientists. Of course the package’s physical models must be described and validated by academics—but the package’s architecture, and the models’ implementation, must be left to people who understand principles that characterize good software such as simplicity, reusability and maintainability.

The second is that the package must be free of charge and open source. This is the best way to attract talented developers and users that will ultimately help build the package’s user community. Open sourcing the software will not only help maintain the software’s quality—though I have some reservations about that—but it will also make the package attractive to bright and talented people interested in extending and improving it. And that has always been the secret to great open source projects.