Alas, I wish it was, but it's not sensible. Govts run at enterprise scale, and need specialised software, and specialised services to manage that scale. And in some areas that simply doesn't exist as OSS.

So then you have to have your law carve out exceptions. Which means you need criteria to determine when you have to have OSS, and when you can use off the shelf.

Or conversely all Govts at every level need herds of programmers to tweak OSS code to make it fit. My city is 10000 people so we need a rate calculator that matches our bylaws, over there is a city of 1000000 people who need a very different rate calculator.

So every town has to hire a programmer to tailor some OSS program - but hey, we don't need every town to have a rates-calculator domain expert - we can say hire 10 of them between us, and split the cost. Yay, a central it dept, with builtin monopoly, at govt pay, can't be fired. What could possibly go wrong with this model.

No wait, we'll make them compete, pay them only for success, negotiate rates, and we end up with? A commercial proprietary software business that's motivated to deliver... With experts at doing this one task at scale. Rinse and repeat for hundreds and hundreds of departments...

> Or conversely all Govts at every level need herds of programmers to tweak OSS code to make it fit. My city is 10000 people so we need a rate calculator that matches our bylaws, over there is a city of 1000000 people who need a very different rate calculator. > > So every town has to hire a programmer to tailor some OSS program - but hey, we don't need every town to have a rates-calculator domain expert - we can say hire 10 of them between us, and split the cost.

Why would each town need their own? It's FLOSS, so it's perfectly feasible to have the state maintain FLOSS systems, in which case you'd just need a small team that handles this functionality.

> Yay, a central it dept, with builtin monopoly, at govt pay, can't be fired. What could possibly go wrong with this model.

When the alternative is a builtin monopoly, at govt contract costs, that can't be fired but can also hold the state to ransom with proprietary software, then that central IT dept at state level looks a lot more desirable.

In fact, the only difference between the two would be that the FLOSS systems would allow the state to invite different vendors to bid on and compete for modification of the FLOSS systems, with all the modifications open so that the state can switch to a new vendor if necessary.

>> so it's perfectly feasible to have the state maintain FLOSS systems,

um, no it's not. The state does not have the skill set required to duplicate the functionality provided by the SAPs, IBMs and Microsofts of this world. (Not to mention the other 5000 or whatever bits of software in play.) And it does not have the skill set required to build a team of people who could acquire or duplicate this skill set.

Or put another way, Enterprise software companies have a 30-40 year head start in this space. Good luck catching up.

What it does have is a love for bureaucracy so no doubt they'd love to give it a go - hiring an army of HR/Product Managers etc to oversee another army of programmers - either on govt payroll or as contractors. All hired on a principle of "lowest price wins".

>> in which case you'd just need a small team that handles this functionality.

I think you underestimate the sheer scope of functionality in play here. The size and diversity of the user base (ie govt employees), the breadth of software encompassing every utility, every browser, every os, every niche tool and product they use. To mandate this must all be OSS would be an interesting (and expensive) play. And that's _before_ we add "govt overhead" to everything and everyone...

>> When the alternative is a builtin monopoly, at govt contract costs, that can't be fired but can also hold the state to ransom with proprietary software, then that central IT dept at state level looks a lot more desirable.

Does it though? Firstly it's really not that much money in the grand scheme of things. Secondly when the OSS software project fails, as most software projects (commercial or OSS) do, who carries the can for spending all that money and having nothing to show for it? Politically that would be insane. And for what? So instead of being beholden to commercial suppliers they are beholden to a nice big internal new govt department?

Honestly, I think commercial companies will do it better for less money.

>> In fact, the only difference between the two would be that the FLOSS systems would allow the state to invite different vendors to bid on and compete for modification of the FLOSS systems, with all the modifications open so that the state can switch to a new vendor if necessary.

How would the state choose between one vendor and another? Who will decide if the vendor did a good job or not? Which FLOSS system is even in the running to replace serious bits of Govt software? If there are good, well supported _free_ competitors to [SAP et al] then why do commercial businesses still use [SAP]?

If business, who prioritize the bottom line think [SAP] is worth the money, why should Govt spend even more money for less return? Repeat the same question 500 or 5000 times for all the bits of software a govt uses, and you'll get an idea of the absolute monster of bureaucracy this would create.

>> When the alternative is a builtin monopoly, at govt contract costs, that can't be fired but can also hold the state to ransom with proprietary software, then that central IT dept at state level looks a lot more desirable.

>

> Does it though?

Well, yes. The only difference should be the license the software is provided under. The result of the current system is all the disadvantages of FLOSS + the lock-in effect.

> Firstly it's really not that much money in the grand scheme of things. Secondly when the OSS software project fails, as most software projects (commercial or OSS) do, who carries the can for spending all that money and having nothing to show for it?

Well, who carries that now? Because all the software is supplied without any liability to the vendor. Right now if a SAP rollout is a complete failure, SAP's responsibility ends with "Sorry".

> Politically that would be insane.

I don't understand why: lets say SAP delivers a FLOSS system because that is in the requirements - how does the politician get the blowback if it all goes wrong, compared to the SAP proprietary system?

> And for what? So instead of being beholden to commercial suppliers they are beholden to a nice big internal new govt department?

Firstly, they are not locked into "commercial suppliers", they are locked into "a single supplier with the power to arbitrarily raise prices and lower quality at the same time".

Secondly, while the state might be beholden to a new internal department, they have control over that department. They might even outsource that department to a commercial entity if they so wished, and keep only a minimal headcount of lawyers to ensure that the FLOSS license is adhered to.

>> In fact, the only difference between the two would be that the FLOSS systems would allow the state to invite different vendors to bid on and compete for modification of the FLOSS systems, with all the modifications open so that the state can switch to a new vendor if necessary.

>

> How would the state choose between one vendor and another?

The same way they currently choose between different proprietary vendors.

> Who will decide if the vendor did a good job or not?

The same way they do it now for proprietary vendors.

> Which FLOSS system is even in the running to replace serious bits of Govt software?

They can decide that the same way they currently decide which proprietary vendor gets the contract.

> If there are good, well supported _free_ competitors to [SAP et al] then why do commercial businesses still use [SAP]?

Who cares?

My point is that the practical result of the current system is that the requirement for all vendors usually boils down to "Must pay license fees to $VENDOR", where $VENDOR is Microsoft, SAP, etc.

If the requirement is changed to "All software must be provided under a FLOSS license", then the state can switch vendors at will.

This does not prevent those companies (SAP, etc) from providing systems. It only means that they cannot hold the state to ransom for future modifications of those systems.

Really, there is no downside to the state adding a single FLOSS requirement to all the existing contracts. They can even grandfather in existing systems so that everything continues working, and only make it a requirement for new systems, or only for new modifications to existing systems.

> Govts run at enterprise scale, and need specialised software

If it's specialised software that's written on a one-off basis, then of course it can be open source.

> Or conversely all Govts at every level need herds of programmers to tweak OSS code to make it fit.

You seem ot be arguing that OSS code needs "herds of programmers" to tweak it, but that proprietary code doesn't. I don't follow why you think this is so.

> My city is 10000 people so we need a rate calculator that matches our bylaws, over there is a city of 1000000 people who need a very different rate calculator.

Either both cities need something different, in which case it needs to be written differently every time, and that's exactly the same whether its proprietary or OSS, so OSS is no more costly or time consumringf to do.

Or, they both need the same code, so the OSS program doesn't have to be partly re-written for each city.

I would have thought that if the program is well-written, then changing things like tax rates would just be a value that is entered somewhere, e.g. on a GUI or web interface.

> Yay, a central it dept, with builtin monopoly, at govt pay, can't be fired. What could possibly go wrong with this model.

Then that's the same as the proprietary software model... except that the code is open source so if one cite doesn't like those terms they can update it separately.

> No wait, we'll make them compete, pay them only for success, negotiate rates, and we end up with? A commercial proprietary software business that's motivated to deliver... With experts at doing this one task at scale.

No. Doesn't work because they proprietary model is to write the code once then sell it lots of times. Once they've written it, they can sell it lots of times at something only slightly less than the cost of writing it each time, because that's the same cost as for each individual city to write it. So if a country has 100 cities, they end up paying 100 times as much with the proprietary solution than OSS,

Once they buy the source, then what?

Are they going to set up a software engineering team to extend the program they bought?

IMO, doesn't really matter. Even if they keep buying new software that gets published as OSS after 5 years, it's still benefits the public.

Also, other companies could reuse the code, even if it's after say .. 3 years. It would also be a boon for transparency, and also lower the bar for alternative suppliers.

Over here, it's almost a meme that the government procures software that noone but the original supplier has a right to modify, which naturally results in enormous maintenance fees. Often they even procure new SW, because it's cheaper than the maintenance fees of the old one.