At the moment there appears to be a largely scattered approach, with feedback, requests, surveys, and "large project" requirements driving the development of features and functionality. The result of this is a scattered feature set and poor integration with the common structural design workflows that we use on daily basis. We are all filling in the gaps with workarounds, spreadsheets, scripts, and use of other software. As a firm we need to have a clear vision for our structural software suite.

According to the GSA change log, the last major release (v8.0) was back in 2002 (http://oasys.intranet.arup.com/gsa/GsaChangeLog_8.htm) - i.e. 13 years ago. In software terms this is an eternity. This is likely a symptom of the lack of available resources (budget, staff, etc.) that the software development team has to work with, and needs to be addressed along with the question of development priorities.

This is a call for the establishment of a strong vision for our entire structural software suite. The aim should be for our software to be the intellectual data store for all the work-product "technology" we develop on our projects, in our spreadsheets, scripts, and other processes. The goal should be to minimise repeated tasks, eliminate duplicate work, increase sharing and continually learn from our combined ongoing experience.

This must be done through OUR software with a clear vision to guide the development objectives and the allocation of resources.