The short answer is: yes, we can see value in supporting MARCXML exports and via the OAI repository module for harvesting, and have had questions about supporting such a format in the past. If someone were to develop such a module against the latest development branch, meet our coding standard and community development recommendations, and be willing to implement change requests during the code review process, then it is likely we would be open to merging it and taking on the ongoing maintenance of such features.
However, there are also many other considerations for us, meaning the answer is closer to "it depends."
The AtoM project is in a somewhat strange and transitory time period. The need to move away from the deprecated Symfony 1.x framework AtoM was originally built with becomes increasingly important, but doing so requires a lot of time, effort, research, development, and money - either rewriting AtoM in a new code base or developing a long term incremental plan to move core modules out into more modular elements in new code bases. Because of this, we need to be cautious about adding new functionality to maintain while trying to develop a strategy to eventually move everything to a new code base - all while there is no guaranteed large-scale funding for this type of work.
Artefactual is going through its own changes, as we consider how to better deliver value to our clients and users, while ensuring we can remain sustainable as a company and continue to follow our core values, particularly around openness and open source. This means ensuring that we are not adding work that is not maintainable or broadly usable and of value to the wider community, as this impedes our ability to focus on value in the long run. It also means being cautious that we are careful with unpaid work we agree to take on, because we give away all our products for free and therefore offering our time and experience is the one way we manage to remain viable as a company and continue to develop and maintain these projects. Reviewing large pull requests, merging in code, adding documentation, answering forum questions about new features, and continuing to test, fix, document, and generally maintain said features through future releases are all unpaid costs requiring a lot of Artefactual time and effort, that can take away from release preparation, testing, documentation, and forum support for other features and bugs.
For these reasons, we are being a bit more cautious about how we approach community code contributions. We have some general recommendations and resources on our wiki that I would urge you to review, but I will also add a few more thoughts in light of the above. First, see:
Key things to note in here:
- We cannot guarantee that we will accept and merge all pull requests
- Pull requests should be organized into clear atomic commits
- The best contributions will reuse existing methods, functions, modules, etc whenever possible - this means that studying the existing code is a good way to prepare for new feature development
- Your fork should be prepared against our latest development branch (qa/2.x) - the easier it is to merge into our main dev branch without conflicts, the more likely we are to accept the work
- Check our coding standard and make sure you run PHP CS Fixer locally before merging
- You should budget time and resources to be able to make changes based on feedback received in the code review process
And based on the points above, I would add:
The best way to get a new feature merged into the public project and have Artefactual take on its ongoing maintenance will be to prepare your own public fork that is rebased against our latest development branch and share it with the community yourself. We would happily help to promote such an effort. If we see that others are interested and are able to use it themselves, then you have proven value, and by taking on the risk of preparing and maintaining the fork yourself, you have reduced risk for us and the public project. At this point there is proven value and uptake, and we would be very inclined to make the work more broadly available by merging it into a public release.
As for where to start? Check out the general development resources listed in the links above as a starting point. Study the existing export functionality (such as for EAD and DC XML) and the OAI module.
Long ago there were plans to support MARCXML in earlier versions, but this work was never sponsored. However, you can find some old XSLT stylesheets in AtoM for converting EAD or OAI-DC to MARCXML. I have no idea if these will still work with AtoM's EAD profile or if they remain current with the MARC XML schema, but they might be useful - see for example:
Dan Gillean, MAS, MLIS