> but most states hired third-party contractors to build an app for them.
So the states paid the bills so can license the result any way they want.
How can they pay for something and not own it?
Sounds to me like there are deep corruption problems
So the states paid the bills so can license the result any way they want.
How can they pay for something and not own it?
Sounds to me like there are deep corruption problems
Try buying a copy of Adobe Software[1], and then hosting the *.isos on your website. You paid for it, you should get to do it!
The short answer is, it costs more to buy 100% of the rights, and governments rarely do so.
[1] It'd have to be older Adobe Software, as modern Adobe Software is all monthly licenses, etc.
of course. But this idea assumes that the contractors are selling the same software to multiple agents. Is that really the case?
Or are the agents already charging the maximum they could for the software, and yet, retain the rights themselves in the hopes of whiteboxing this software in the future for some other gov't agency?
We are not talking about a single consumer. We are talking about the state itself. They will get the license they want if they believe it is needed.
They will also use more tax-payers money to do so. I agree that the code should be public, but I can see why that isn't the case.
I consider this to be a flavor of corruption, too, but it isn't, legally. It is the desired outcome for many, and for many more, maybe not the outcome they wanted, but the logical outcome of what they asked for.
There has been a decades-long process in the US of pressuring governments to do less, to outsource more, to privatize, to move to "public-private partnerships" or whatever new buzzword means socialize losses and privatize profits.
And this is what you get - government that doesn't have the capabilities it needs to do what people ask of it. Which makes it look bad, which encourages another cycle of privatization...
If you want functional government, stop electing people who promise to break it.
Corruption can be legal.
Like election/campaign financing in the USA
They license it.
Renting everything seems to be the fad in business management, and governments often ape business.
Public sector usually makes up the rules for itself and then upholds them in the software. Very little public sector software could be resold in the private sector without significant investment into making it more general, usually to the detriment of the product. The "multiple clients => lower price" thus holds no water, because it's always just different branches of government and the usual way it ends up is that after 10 years or so the product is still used in one place only and the original programmers long left the company. And public still pays for a yearly license.
From what I hear it has changed just a little bit, not much, though. It also depends on state and town.
Speaking for .de and North-Rhine-Westfalia from 1994 to 2001 here.
Have you ever purchases software? Any media, recorded performance, or book?
I don't mean to be rude here, but this question shows a complete lack of awareness of the problem space.
There are a number of contributing factors to why most government software is not open source, but here are some of my direct observations as a consultant to government departments, an employee of government departments, a purchaser of products and services at multiple corporations, and a manager of contract software development as an employee of a corporation, and the owner of small business.
1. Stakeholders building software, using either directly employed, or contracted resources, have a desire to develop the software for the lowest cost possible. Generally this means preferring buying over building for many cases, and building on commercial (paid, free, or open source) stacks that promise easier development and efficiency. This often results the project being encumbered by licenses that complicate the potential release of software as open source.
2. Many government initiated software development projects are done directly in pursuit of supporting legislation that is tightly bound to the jurisdiction of the legislation; even if the legislation is meant to ratify state/provincial, federal, international or other standards, laws, and regulations, there will be regional variations that require at minimum configuration, and most likely real code changes to meet requirements. This often results in software that is tightly coupled to a particular jurisdiction in terms of both legislation and regulations, but also in terms of the ecosystem the software is developed in. The encumbrances created by these couplings often have dependencies on closed and proprietary systems which is a great deal of friction for releasing open source projects.
3. Despite the passage of many international rules related to economic development agreements like the former NAFTA and the newer USMCA which provide provisions to allow fair competition for government contracts within the regions affected (and I believe EU and other trade blocs have similar legislation), the opportunity to award software development contracts to local firms (at any level of locality across municipal, state, and federal jurisdictions) is a strong temptation for politicians to curry favor with voters and business communities. This is often pitched as economic benefits by creating jobs locally, while bolstering local businesses and making them more competitive; if these projects are subsequently released as open source projects, the perception from decision makers is that the value of the investment in the local community is lost. This is where a significant opportunity for what you bill as corruption is identified - I haven't seen a procurement process in government that can't be subverted by suitably motivated buyers and sellers.
4. Releasing open source software can be a public relations nightmare - bug reports, public review and criticism of design or implementation choices generally land on the desks of whatever passes for a service desk for that jurisdiction, who are usually ill equipped to deal with these technical issues, and also are generally understaffed for their core responsibilities. Eventually those reports and criticisms make their way up through different paths and land on the desk of high level bureaucrats and elected officials, who then have to deal with these issues as public relations items. Have to deal with HeartBleed2022? If it's internally developed and open source, the buck stops with the politicians and how they let it happen, time for a public inquiry! If it's an off the shelf product, "We are disabling the service until a patch becomes available." [1, specifically log4j] , and people can grumble about purchasing choices, but it's much harder to criticize the actual implementation.
Alot of folks in government (including me when I was there) wanted to release our stuff as OSS, but there is only so far you can go with opensourcing modules that depend on SAP code, IBM code, or systems that are supplied by the federal government.
[1] https://www.canada.ca/en/revenue-agency/services/e-services/...
Specifically, I would say that number three is mostly false. The companies that receive those contracts are not, at least in my experience, small local shops (and there is an argument that they should be), but instead big consulting companies that know the correct people and procedures.
>>"Alot of folks in government (including me when I was there) wanted to release our stuff as OSS, but there is only so far you can go with opensourcing modules that depend on SAP code, IBM code, or systems that are supplied by the federal government"
The point of the endeavor is precisely to change that.
Define small local shops? I have worked on procurement processes in the United States at the municipal, state, and federal level, but my experience is largely based in the Canadian market. These are companies that have 100-1000 employees, working on technologies tightly scoped to specific municipal, state/provincial programs, and in some cases Federal programs. Some industries include prisons, agricultural programs, energy programs (hydro-electric, oil, gas, nuclear), and a broad cross section of infrastructure projects.
You can disagree or be unconvinced, but even a basic google search highlights the significant issues with procurement, and the fact that we have old and current laws on the books to address these concerns is evidence enough that procurement practices and influence from politicians and industry need regulation.
Simply put, procurement is about finding the right proposition for governments, and demonstrating to taxpayers that they are getting best value, while rewarding the individuals and industries that supported the elected officials and beaurocrats. This isn't a personal opinion, it's well supported by documentation in the industry.
> The point of the endeavor is precisely to change that.
I 100% agree, and I avidly support these kinds of initiatives; my comment didn't discount that, it was an explanation of why public code, developed internally, or by contractors, isn't necessarily suitable for open source release. Not all of the reasons are technical or legal, some are due to organizational or social pressure.
Cloud SAAS e.g. Salesforce apps
Actually, quite easily, and it's cheaper that way (especially if they pay to acquire it, and it wasn't exclusively developed for them.)
Which is also why they would do that.