Language Selection

English French German Italian Portuguese Spanish

AU Government to use open source to break lock-ins

Filed under
OSS

IT vendors pushing costly proprietary software lock-ins have been warned that feeding at the $4.2 billion IT trough of the Australian taxpayer is over and a strict and a new procurement diet for vendors will be personally enforced by the Special Minister of State, Senator Eric Abetz.

A copy of "A Guide to Open Source Software" prepared by Australian Government Information Management Office (AGIMO), exclusively obtained by Computerworld, reveals new guidelines that state if an equal or superior open source product adequately fits the government's needs, it will be expected to be objectively considered by public servants alongside proprietary offerings.

Due to be officially released at the Open Computing in Government conference in Canberra next week, the government guide to open source is the most exhaustive analysis and evaluation of open source for use in government to date.

"This is an important document for both the government and for the open source community. For the first time, government agencies will now have access to an explanatory document about open source software," Abetz told Computerworld.

"The aim of this document is to explode some of the myths surrounding open source software and to acknowledge it as a viable option which should be considered when undertaking government software procurement," he added.

The document's forward from Abetz states, "All solutions - open source or proprietary - which can meet an agency's functional specifications should be considered by an agency when it is undertaking software procurement."

The document also cautions that government agencies preparing "requests for tender need to take care to avoid introducing unintentional barriers that may discourage or inhibit open source vendors and resellers from submitting responses".

Specifically, agencies are advised to avoid specifying products by name or mandating that solutions be delivered using a named proprietary or otherwise named solution.

On the licensing front, the guide goes as far as to provide a matrix as to what sort of open source licence is most appropriate for various government uses. This includes not only the development and sharing of open source solutions (presumably applications) by and for the government, but clear guidance that government agencies can "link open source product with internally developed code and distribute beyond the Australian government as a proprietary product".

However, it is on the subject of lock-ins that the open source guide by far delivers the strongest warning yet the government will not tolerate being led by the nose by vendors at taxpayers' expense.

Under the heading "Risk analysis and risk management", the document states: "One high-level risk associated with proprietary software technology (particularly software only available from a single publisher or supplier) is the financial risk of potentially high termination costs. This risk arises for a number of reasons, but the most important issue is the lack of alternative support for the software in question.

"The result is a lock-in scenario where an agency is tied to a particular supplier with little room for negotiation. This stems from the prohibitively high cost of moving away from a particular piece of technology for which there is no functional or interoperable equivalent from an alternative supplier.

"Such scenarios allow the current vendor to increase future product pricing, support cost structures or other contractual terms," the guide states.

It also refers to previous advice from AGIMO that, "...agencies develop a transition / termination strategy during the original procurement process to reduce the risk of future problems for the agency".

Source.

More in Tux Machines

Leftovers: OSS

  • Anonymous Open Source Projects
    He made it clear he is not advocating for this view, just a thought experiment. I had, well, a few thoughts on this. I tend to think of open source projects in three broad buckets. Firstly, we have the overall workflow in which the community works together to build things. This is your code review processes, issue management, translations workflow, event strategy, governance, and other pieces. Secondly, there are the individual contributions. This is how we assess what we want to build, what quality looks like, how we build modularity, and other elements. Thirdly, there is identity which covers the identity of the project and the individuals who contribute to it. Solomon taps into this third component.
  • Ostatic and Archphile Are Dead
    I’ve been meaning to write about the demise of Ostatic for a month or so now, but it’s not easy to put together an article when you have absolutely no facts. I first noticed the site was gone a month or so back, when an attempt to reach it turned up one of those “this site can’t be reached” error messages. With a little checking, I was able to verify that the site has indeed gone dark, with writers for the site evidently losing access to their content without notice. Other than that, I’ve been able to find out nothing. Even the site’s ownership is shrouded in mystery. The domain name is registered to OStatic Inc, but with absolutely no information about who’s behind the corporation, which has a listed address of 500 Beale Street in San Francisco. I made an attempt to reach someone using the telephone number included in the results of a “whois” search, but have never received a reply from the voicemail message I left. Back in the days when FOSS Force was first getting cranked up, Ostatic was something of a goto site for news and commentary on Linux and open source. This hasn’t been so true lately, although Susan Linton — the original publisher of Tux Machines — continued to post her informative and entertaining news roundup column on the site until early February — presumably until the end. I’ve reached out to Ms. Linton, hoping to find out more about the demise of Ostatic, but haven’t received a reply. Her column will certainly be missed.
  • This Week In Creative Commons History
    Since I'm here at the Creative Commons 2017 Global Summit this weekend, I want to take a break from our usual Techdirt history posts and highlight the new State Of The Commons report that has been released. These annual reports are a key part of the CC community — here at Techdirt, most of our readers already understand the importance of the free culture licensing options that CC provides to creators, but it's important to step back and look at just how much content is being created and shared thanks to this system. It also provides some good insight into exactly how people are using CC licenses, through both data and (moreso than in previous years) close-up case studies. In the coming week we'll be taking a deeper dive into some of the specifics of the report and this year's summit, but for now I want to highlight a few key points — and encourage you to check out the full report for yourself.
  • ASU’s open-source 'library of the stars' to be enhanced by NSF grant
  • ASU wins record 14 NSF career awards
    Arizona State University has earned 14 National Science Foundation early career faculty awards, ranking second among all university recipients for 2017 and setting an ASU record. The awards total $7 million in funding for the ASU researchers over five years.

R1Soft's Backup Backport, TrustZone CryptoCell in Linux

  • CloudLinux 6 Gets New Beta Kernel to Backport a Fix for R1Soft's Backup Solution
    After announcing earlier this week the availability of a new Beta kernel for CloudLinux 7 and CloudLinux 6 Hybrid users, CloudLinux's Mykola Naugolnyi is now informing us about the release of a Beta kernel for CloudLinux 6 users. The updated CloudLinux 6 Beta kernel is tagged as build 2.6.32-673.26.1.lve1.4.26 and it's here to replace kernel 2.6.32-673.26.1.lve1.4.25. It is available right now for download from CloudLinux's updates-testing repository and backports a fix (CKSIX-109) for R1Soft's backup solution from CloudLinux 7's kernel.
  • Linux 4.12 To Begin Supporting TrustZone CryptoCell
    The upcoming Linux 4.12 kernel cycle plans to introduce support for CryptoCell hardware within ARM's TrustZone.

Lakka 2.0 stable release!

After 6 months of community testing, we are proud to announce Lakka 2.0! This new version of Lakka is based on LibreELEC instead of OpenELEC. Almost every package has been updated! We are now using RetroArch 1.5.0, which includes so many changes that listing everything in a single blogpost is rather difficult. Read more Also: LibreELEC-Based Lakka 2.0 Officially Released with Raspberry Pi Zero W Support

Leftovers: Gaming