Yes. The primary argument for me is the combination of two facts: as with other data software is brittle, requiring regular maintenance, and libraries are not generally major power brokers in the commercial software field.
Software companies have a strong incentive to build applications for as wide a market as possible, leaving libraries with very limited buying power, and as with other areas of preservation, decisions are made based on current market realities and whims. We've seen this with systems like Apple's QuickTime which had very complex functionality (e.g. embedded Flash & other rich, programable content) added and later removed after falling into disfavor — certainly the right business decision and definitely a security benefit but completely stranding the small number of people with a significant investment in content which actually used those features.
At the other end of the market, a small vendor may go out of business or have key personnel retire, leaving all of their users stranded with no option other than hoping an alternative is available and that the migration path is not too rocky.
Open source software helps with several of these challenges:
In the simplest case, it means that it's impossible for a vendor to simply disappear. It might not be cheap but at least you have the option of hiring a software developer to maintain or improve an open source application.
Corollary: you really want to make sure that you actually save a copy of the source for anything you use if the current maintainer starts to seem shaky.
There's frequently a huge difference between a format as specified and as practiced. Using an entirely open-source stack now means that you have a known reference implementation from the beginning rather than finding out later that your data really only works well with one particular implementation. If you are forced to migrate later, it can be extremely helpful to have a known working codebase for reference.
On a related, open source software now almost always implies an open version control system which makes it much easier to determine where and how something stopped working. There's one other interesting aspect: the dominance of distributed version control systems in the open source world is particularly powerful because it breaks the assumption of a single privileged maintainer, making it safer for your organization to maintain local customizations against upstream releases. Handling local customization gracefully traditionally has been a weak point for commercial software vendors for various reasons but it's integral to working in the open source world.
There's a significant related advantage: open source software is usually considerably cheaper and you have cost saving options if you're not paying support but can perform some work in house – this is a benefit to the extent that it either frees budget for more direct preservation work and avoids unpleasant surprises down the road.
All of these generally shift as a function of how close they are to your critical path: if you need a particular viewer for a file format, it's far more important than, say, a search engine on your storage system since the latter operates independently and can be swapped out far more easily.
This strongly rewards keeping your architecture simple and standard because you lower the chances that you'll need to start supporting something which has fallen out of popularity within the community. For example, storing items in a database is far riskier than storing the same content on a filesystem simply because it introduces a massive chunk of complex, possibly expensive, software which has to work simply so you can retrieve a file and the lack of a standard interface would mean that you need to develop or pay for support in anything which needs to access the data.
