You are always welcome to contact Artefactual at our info email
to inquire about development opportunities. There are also many other development companies who do AtoM work, several of whom have members who participate in this list. If you choose to contract with another developer, we recommend that they review our recommendations on submitting custom development to the public project, as this can reduce the ongoing maintenance burden for you and them, and benefit the project and the community as a whole. However, it requires some upfront planning for larger projects! See:
A few general thoughts to keep in mind:
These all sound like fairly major development projects (particularly adding new languages - more on this below), so unless you have unlimited project funding, you may want to prioritize your requests, and if necessary, consider workarounds in the meantime.
Regarding the language request:
A full list of currently supported languages can be found here:
If the language you want to use is already present in that list, then no development is necessary. However, if it's not, the situation is much more complicated.
AtoM inherits its multilingual support from the Symfony 1.x PHP framework. This PHP framework was originally used to develop ICA-AtoM back in the mid-2000's. However, the framework was deprecated some time ago, and replaced with a non-backwards compatible 2.x version in 2014ish. The Symfony Project is now on version 5.x.
The breaking changes between Symfony 1 and 2 were so extreme that upgrading Symfony in AtoM would have essentially required our team to rewrite the majority of AtoM to be able to implement it. Given that we have historically relied on community support (either via development sponsorship, or else community code contributions) for major development, and given that most institutions do not want to fund maintenance work such as internal upgrades, we have never found a sponsor, and the work was never completed. AtoM 2 still uses Symfony 1, and right now it is one of the biggest barriers to ongoing maintenance, development, and major scalability improvements in AtoM.
As such, adding a new language either involves doing work to change how it is implemented in Symfony 1, or else... upgrading Symfony.
At this point, the second option is not really our preference - mainly because we are not convinced that Symfony, or even PHP, should remain the future core of AtoM. Web based technologies have evolved massively since we began AtoM development, and other new design patterns and technologies have emerged that might be very beneficial in creating solutions for cultural heritage institutions that were not previously available. Since a framework upgrade is essentially as much work as a rewrite, we would prefer to see a strategy to move AtoM to a more modular, service based design that can scale and be easier to maintain going forward.
The first option (altering Symfony1 directly) is also a risk however, since it makes continued maintenance of AtoM and Symfony a greater burden for Artefactual - there is a chance we would no longer be able to pull in security patches and performance improvements from the community-maintained Symfony1 forks that exist, for example.
Our recommendation would be to explore options that can be built outside of AtoM but still integrate with it. This approach would allow for any new development to potentially become one of the first components of an AtoM3 body of modules. Over time, incremental development to move more and more functionality out of Symfony may be the best way for us to build a next generation version, given that finding the funding necessary for new development from scratch to replace a project with 13 years of feature development has proven nearly impossible to find.
I don't yet know what a solution built outside of AtoM but able to work alongside it might look like for additional language support - but that is exactly how our team is trying to approach development requests these days. Understand the underlying problem, consider how best to provide value, and explore options that will not further add to AtoM's technical debt, so we can move the project forward strategically. I would recommend that you consider a similar approach with any other developers you contract with for work on these feature requests.