In my opinion:
1) You will always be constrained by a software team.
2) Change your software preserve your data.
3) General solution tend to be more feasible than custom ones.
4) Is your company planning to make their solution open source and available to other cultural institutions?
This is as succinct as I can be. If you agree with the first three points and your answer to the question number four is No then you should read point number four (appendix). If you agree with the first three points and your answer to the question number four is Yes then you are done.
------------------------------------------------------------------------------------------------------------------------
1) You will always be constrained by a software team.
Whether you will hire a company (that uses open/close source software) or team-up in-house software developers you will always be tied and constrain by their expertise. No illusions here.
2) Change your software preserve your data.
About sustainable software: good documentation and following existing standards are honorable efforts towards sustainable systems. However, such efforts are hopeless when submitted to the years pressure. Software is just like any modern product. It is cheaper to buy a new one than to repair an old one.
Such a thing as a long-lasting software does not exist neither it is desirable. Whatever you will choose now it will be different in a couple of years, either because it evolved or because it died. Software changes are not only healthy, they are essential to survival.
Your most valuable treasure is your data not your software. Your data should be protected and untied from your software. Your data should be exportable from the software to a standard format (plain XML, RDF or other).
3) General solution tend to be more feasible than custom ones.
General solutions are those that do not reflect the idiosyncrasies of a particular institution. Therefore, it is easier to architect a general solution when the software in development is targeted on several similar institutions.
The greatest dangerous of in-house software is customization. Furthermore, constant changes in requirements are common while developing in-house software and often drive projects to failure.
In general, in-house software development brings high risk to a project. Can you afford it? It is very difficult to create a 'winning' software team. This often involves try-out periods with a couple of iteration. The success of your software will reflect how successful you were team-up the software developers.
4) Is your company planning to make their solution open source and available to other cultural institutions?
I am very impressed by your actual research. I think that you walked a long path and you further deepened the subject. You should not underestimated, neither should you discharge the information you have gather so far. I think this is the most valuable achievement.
There are several cultural institution having exactly the same worries/necessities. My proposal is to create a package that can be reusable by other cultural institutions.
The best way to achieve a general and sustainable solution is to involve several institutions in the developing process.
Such a package can include the information you collected so far (in the form of a wiki?). If you decide to exclusively use open source software, you can include a set of instruction explaining how to assemble it and the main problems you have found, etc. You should invite others to talk(write in the wiki) about their experience using such a package. This is easier than it sounds now. Well, I can try to explain how an open source project is baked in another email.
The decision of making your solution open source does not exclude the option of hiring a software company. Have you proposed to the employed company whether they will be interested in making your solution open source? In another email, I can explain why a commercial company might be interested in making your solution open source and free (as in freedom and as in beer).
The decision of making your solution open source should be taken in an early state and not after the production of FACT Online.
Just as a final remark, I think the main advantage of using open source software is to make your own project open source too and benefit from the advantages of an open source community.
