We should be able to have a graded approach to the software design. The core hydraulic engine (with the data structures generated when ENopenH() is called) should be designed with efficiency as the main goal, and stay pretty close to what it is at the moment. However, the data structure that sits on top of this can be OO. This will allow users to extend and apply the EPANET code with all the benefits of OO, but with only a small price to pay in terms of efficiency. Expert users can write their own code to modify the internal data structures directly if they want to be super-efficient.
I was aiming for something quicker. For WDSA we can aim the next version to.
I’m was referring to the first major open source model (version 3?), not 2.1.
You’ve raised some interesting points, and the discussion so far has been fruitful. I’d like to summarize the points raised up to now (please correct me if I missed/misunderstood something):
@imontalvo: lack of developers, licensing, funding, the programming language and the software architecture. In addition, Idel highlights testability, scalability, task-division across developers and the use of the Object-Oriented architecture.
@eladsal identified as key issues licensing, stability, speed, portability, ease of use, integration with other languages and maintenance. Starting point in roadmap: get/set for all data.
@markwilson highlights the free GUI, speed, stability and the existence of a profitable business model
@kobusvanzyl highlights efficiency and considers the benefits of OO.
A lot of issues have been raised, and I also agree we need a roadmap, as @samhatchett has pointed out. I also agree we should prioritize in accordance to our (limited) resources.
Bug-Fixes (short-term): For the short-term, we need to release EPANET version 2.01.00. This would be an important milestone and should include the most important bug-fixes plus some additional new functions. This goal should be feasible to be achieved (tested/verified) within the next months. The community is waiting for this update (myself included).
Modular Architecture (long term): EPANET 3.00.00 however might be something completely different. There are some other successful examples, such as the QGIS, in which the community  has decided to follow a modular architecture with multiple libraries and with clear APIs which allow the communication of various plugins (written in C++ or Python). As I understand it, the big challenge would be to design and implement the backend, that would orchestrate the different modules. However, I can easily visualize a new software (in any language), which would coordinate the execution of various libraries (all the previous versions of EPANET, the new ones, as well as plugins). Plugin writters (e.g. PhD Students) should have an API which they can use to make their software communicate with the system. Language again should not be extremely important, because I expect wrappers would be created by the community, to assist programs written in any language. Furthermore, I can also visualize having a configuration file in which one can easily select between different models (e.g. Demand-driven, Pressure-driven).
Learn from others: I would also recommend we study/hear how other people in the community have tried to solve the problem, e.g. CWSNet (@zkapelan) , OOTEN (@kobusvanzyl) and others. A webinar could be easy to organize
Collect Data: We need more data for our decisions, and we need to involve as many people as possible. The scientific approach would be to organize a questionnaire, to learn how people are using EPANET. A short/well-structured questionnaire could be easily forwarded to all the members of the community (which are not that many), and it would help us get an understanding of the needs (e.g. in academia and hopefully the industry). It could also trigger the sense of participation and contribution.
Speed (vs?) Modularity: I think there might be a compromise in speed. By making EPANET ultra-fast (e.g. EPANET running on GPUs), we may not be able to make it ultra-modular (as QGIS is). However, what do we mean by “fast”, is arbitrary. In any case, identifying the bottlenecks and fixing them it might be a research topic by itself, which may be (hopefully) solvable by writing a plug-in.
Special Interest groups: One idea is to involve researchers from within the same field, and ask them to prepare a joint paper e.g. on water quality modelling in EPANET (what is the state-of-art etc, what the priorities should be etc). This should provide the basis for a road map at least from the scientific point of view.
nice to hear from you! I´m totally agree with your comments. For the short term you were mentioning I suggest to follow what @samhatchett already prepared and labeled as v2.1 Milestone. I liked the idea of a fast short term delivery like you and @eladsal were mentioning combined with a more “long term” vision of a major open source model as mentioned by @kobusvanzyl.
@demetrios You also were bringing back the importance of the GUI as mentioned by @markwilson. At the CCWI it was said that no GUI development is planned to be done but it is real that without the integration of the new developments in a GUI it will be really hard to reach most of the people using EPANET out there, I suggest to rethink the idea of the GUI maybe for the “long term / middle term”.