# Comparison of Multi-Agent Platform Usability for Industrial-Grade Applications
## 5 AOSE in Contrast to Modern SDLC
### State of Maintenance
\begin{table}
\begin{tabular}{c l} \hline \hline
**Platform Name** & **State of Maintenance** \\ \hline \multirow{3}{*}{_JADE_} & Builds on Java JDK 1.5, with its compatibility tested with Java 21. Its updates are published irregularly at intervals spanning several years. Some old issues remain unaddressed. \\  & Targets Java 17. Updates are made regularly and include frequent bug fixes. \\  & Is compatible with Python 3.10. Updates are highly irregular, and some technological issues remain unaddressed. \\ \hline \hline \end{tabular}
\end{table} 
Table 5: State of maintenance in JADE, Jadex, and SPADE. were released monthly. However, there has been a noticeable gap between the release of version 4.0.267 and Jadex-V. This may be due to the migration of the project, but the consistency of upcoming releases should be closely observed. Due to the frequent code updates, Jadex is better able to manage technological debt (despite the issues outlined in Section 5.3) by including extensive bug fixes in its successive versions. Additionally, by publishing the repository on GitHub, Jadex provides a common space for issue tracking and bug reporting, making both of these concerns transparent to external developers. Like Jadex, SPADE remains up-to-date in terms of the latest software distributions, supporting the most recent versions of Python. Moreover, during the code analysis, no errors indicated possible migration improvements or usage of deprecated APIs. However, the main issue with the platform lies in the lack of frequent updates. This is primarily due to the fact that SPADE is maintained by a small group of developers. Nonetheless, from the perspective of end users, such an approach does not offer stability sufficient for application in industrial-grade systems. Moreover, due to irregular updates and the limited amount of human resources available for functionality improvements, SPADE contains several unresolved issues. For example, one of the critical bugs involves inefficient memory management. Specifically, it was reported that the agent's trace store, used in SPADE, consumes increasing amounts of memory in simulations with constant memory complexity. Additionally, due to the upfront size limitations, when running applications, it became possible to fill the entire memory capacity. Although several years have passed, the issue has not been addressed. A similar case exists with the other 26 issues reported in the official repository. In such a case, if an industrial-grade large-scale system based on SPADE were to be deployed in a production environment, it would likely result in burdensome errors that could take a substantial amount of developers' time to resolve, generating additional project costs. The severity of technical debt may differ significantly depending on the agent platform. Nevertheless, it is evident that legacy platforms need to be migrated to modern software distributions commonly used by the industry. Furthermore, some platforms still struggle with recognising and resolving errors. This can be attributed, among other things, to the lack of sufficient test coverage. Most platforms (e.g., JADE and Jadex) contain only a few functionality tests, which prevents automatic bug detection. Lack of testing is evident not only in the internal functionality of these platforms but also in their incompatibility with modern industrial-grade test libraries. Up to this section, the focus was placed on the SDLC stages prior to and including **Implementation**. Let us now address, in more detail, the barriers encountered in terms of software **Testing**.