In part 1 and part 2 of Issues with OpenFOAM, we concluded that:
- successful development of OpenFOAM demands the resolution of issues where the software does not meet reasonable expectations of users;
- under an agile development streategy, involving collaboration between users and developers to resolve issues, OpenFOAM has been transformed from poor health in 2014 to a new level of quality and maturity with OpenFOAM v4.0 in 2016;
- user participation is encouraged by rewarding users for reporting issues by their timely resolution and by ensuring the development version,
OpenFOAM-devis always releasable quality.
Unresolved Issues
We previously showed the number of unresolved issues taken from the OpenFOAM Issue Tracking system. Unresolved issues increased continuously until the release of the public distribution of OpenFOAM-dev in December 2014, after which they fell rapidly, then stabilized to a fairly consistent level of 60-70 during 2016. Analysis of the remaining unresolved issues is an essential part of high quality software engineering, particularly identifying the components of the code with the highest number of issues.
The breakdown of outstanding issues is shown in the chart above, with 90% of unresolved issues falling within only 7 categories. While “meshing” and “numerical methods” are broad components of CFD, each of the other 5 categories describes a much narrower range on functionality in OpenFOAM. The two worst offenders account for almost half of all unresolved issues: 1) AMI, ACMI and cyclic interfaces; and, 2) heat transfer, including conjugate heat transfer (CHT). These categories, and “particles and tracking” and “sources/constraints” in particular, require significant refactoring and/or rewriting.
Trouble with Roadmaps
Inadequate funding is the primary reason why certain areas of OpenFOAM reached the present state of disrepair. The development of OpenFOAM has always been funded by companies wishing to build functionality falling within their areas of interest. Developments projects historically followed a waterfall, roadmap model, which lacked the rapid-turnaround user feedback associated with today’s agile development of a public OpenFOAM code repository. Issues went unreported for long periods, typically until a major version of OpenFOAM was released, well after a project was closed. With no provision for resolving issues or general maintenance within the development funding, issues simply remained unresolved unless a developer’s conscience compelled him/her to contribute voluntarily outside of working hours.
The circumstances of the AMI development was especially bad, in that it was never funded, but was hastily included by corporate managers within a manufactured roadmap. Its lack of quality was an inevitable consequence of conflicting pressures of zero funding, concocted milestones and revenue targets.
Funding Agile Development
Funding is needed to repair the critical areas of OpenFOAM with unresolved issues. The work requires significant code refactoring and rewriting by developers willing to adopt an agile strategy, described previously, that generates sufficient user feedback to drive software quality rapidly to an acceptable level. Funding should support a broad aim to improve software quality, demonstrated by a reduction in unresolved issues, rather than a rigid set of development objectives.
The target for 2017 is to reduce the number of unresolved issues by 50%. The OpenFOAM Foundation needs €100 k to fund this work, and the costs of running the OpenFOAM project. We propose that 20 companies pool €5 k each to reach the target. Companies that rely on OpenFOAM carry an operational risk associated with its decline through lack of funding. At a fraction of the cost of a single licence of most proprietary CFD software, €5 k is surely a small price to pay to mitigate this risk?