Is open source an option for process simulation software ?
This is an updated version of the forum entry titled “Is open source appropriate at all for chemeng software ?” which was posted here 5 years ago; that forum seems abandoned nowadays, but the topic is still relevant so I thought of reviving it.
First of all let’s see what is the current status of open source projects for process simulation.
Original MIT ASPEN turned proprietary; I like this quote from the original end-of-project announcement:
“When ASPEN has been adequately tested, in 1981, it will be publicly released and the source code will be available. This will permit companies to modify and adapt ASPEN to meet their own special needs“
In fact if you fancy some good vintage FORTRAN IV, for a fee you can still grab the original source code here.
- SIM42: stopped.
- EMSO: this is not really open source (only the model library is), rather it’s freeware; it seems ticket #1 (“EMSO still have a very small community involved”) is still open.
- OpSim (Open source Process Simulator****): got stuck in the requirements definition stage.
- ASCEND: now restarting after a long break, has a very long to do list. The legacy architecture makes it difficult to maintain.
- DWSIM is young (started in 2006, open sourced in 2008) and progressing quickly; based on modern object oriented, managed technology, at the moment it’s still a one man operation.
- Modelica is really just a Domain Specific Language and open source library of models; there are some (partly) open source bits, but it seems to have little penetration in process simulation.
Interpreting this situation requires a picture of the many forces at play here: innovation, skills, community, funding, business model and confidentiality.
Writing process simulation software in 2012 with programming languages and techniques from the seventies is a daunting task, doing it in a more modern way requires an innovative design. While the open source model is very successful at re-implementing large existing commercial software (examples: LibreOffice vs. Microsoft Office, Linux vs. UNIX) or at writing new small, special purpose tools in areas where there is great enthusiasm from the community (example: peer-to-peer or multimedia), it is not so good at innovation.
We are talking about complex software – designing it from scratch requires a single mind (cfr. chapter 4, “Aristocracy, democracy and System Design” in the book The Mythical Man-Month) – but the democracy and lack of hierarchy in open source projects favors design by committee.
There are not many people with the right skill mix for the task: information technology, numerical analysis, thermodynamic and chemical engineering. Many open source projects terminate at some point, mainly because of the difficulty of priming the community (the way you prime a pump;-). Not only the right people are scarce: it is also not easy to motivate them to collaborate.
There is little incentive in investing one’s time “for free” in developing complex scientific or engineering open source tools or libraries. We owe a number of freely accessible / open source numeric software libraries and scientific tools to research grants assigned to universities or state-owned agencies. Alas over the years no funding has been devoted to the support of open source tools for process engineering, as this discipline has neither the fascination of high-energy physics nor the significance of genomics.
The current business model for process simulation tools is hardwired in the structure of the process industry sector. There has been no success (and maybe even no attempt) to displace it with one of the different open source business models: pay-for-support, dual licensing and pay-for-projects. Actually no other business model has won any market share in this arena: Application Service Provider (ASP), cloud computing or Software as a Service (SaaS). On one hand there is the mythical inertia of the industry (“if it works, don’t touch it”).
On the other hand there is the issue of confidentiality; suppose a company decides to venture in a modelling project based on an open source tool – say they write a model of their proprietary FCC reactor – does the license bind them to give back that code to the community? This is unthinkable.
In conclusion, the success of open source projects for process simulation depends on three key issues: overcoming misconceptions and inertia in the industry, finding the right business model and building a vast community.