It doesn't need an excuse; it's a fully valid reason. Using proprietary software is a perfectly valid choice to make.

Chosing to pay millions when it is not necessary is definitely not a valid choice. It is at best stupidity, at worse corruption.

In my experience in the public sector in France, I have seen these decisions taken to advance someone's career.

For example, a first year free means a purchase person will get their promotion on incredible YoY progress.

Deploying a free tool that doesn't solve an organizations problems isn't a valid choice. I'm tired of open source advocates hand-waving away the reasons people choose other software. For most organizations, software is not a big cost, labor is. It often makes sense to throw a million dollars at a piece of software to make people's job easier, because that can translate to tens of millions in labor.

That is stretching the subject beyond reasonable. Proprietary software as a general endeavor is not an invalid business and nobody is saying that here.

LibreOffice is close enough to Microsoft's offering that surely it makes sense accross the many EU states to stop spending millions on it, and spend a few to close the gap, saving even more millions in the future.

Respectfully, I think it's a bit of a Dunning–Kruger effect for random internet commenters to presume they know what is "close enough" to meet the requirements for the many thousands of different day jobs that people have across the different governments of dozens of different countries.

Certainly the people buying software know best what their requirements are.

> Certainly the people buying software know best what their requirements are.

I doubt it. The people who are going to use the software are the ones who know what the requirements are. The people buying it should be asking the users, but rarely do.

For a large software deployment, you should be getting part of your requirements from discussions with users, but there will often be a lot of requirements from non-user stakeholders. For government deployments, even more so.

Have you ever actually worked in a large org or government IT department? :D

Commendable ideas, but they do not translate to reality. Even taking the OSS discussion out of the equation: Understanding and integrating user requirements in development processes is a hard problem in general. It gets worse when we are talking about resource-constrained contexts (like government IT)

I didn’t say it wasn’t hard. Regardless it is extremely routine for multiple stakeholders groups to be involved in software purchases, at least over my 20 years of experience.

Ideally yes, but do you realistically think that happens?

Let's be real... Tons of governments employ people just to boost employment numbers. Government staff are almost always simply a cost, governments don't need to be profitable. They extract taxes and then spend it. And I think a lot of countries would prefer to spend more on salaries than on software licenses going to a different country...

In English the word "free" is apparently another difficulty. The technical Four Freedoms are not at all about the money. Money can be exchanged between willing partners of course. That includes government. The means and methods of closed source, and the means and methods of "corruption" are real.

I believe the Danish gov is roughly spending 50M EUR/year to MS, certainly you can get the features needed paying for dev time for an open source project with some of that spend.

Not that it is insurmountable -- but the difficulty with adopting open source more broadly often isn't a financial issue, but organizational. A successful enterprise software deployment consists of a lot more than simply paying developers. You need the correct management in place to ensure the developers are building the right features, to ensure they meet your organizations needs in terms of compliance, deployment, support, ensure your users understand how to use the product, etc. Organizations that are familiar with software development can often do this, but these types of projects are sometimes beyond the reach of the expertise of other organizations.

Absolutely, management and maturity are key to success in this regard.