Oregon Bill Would Require Open Source Consideration

VeniDormi writes "I just found out that House Bill 2892 was introduced in the Oregon House of Representatives by Representative Phil Barnhart. The summary: 'Requires state government to consider using open source software when acquiring new software. Sets other requirements for acquiring software.' Rep. Barnhart has a few comments on the bill." A NewsForge story has more information, including some words from Rep. Barnhart.

Comments

How does MS feel about this?

[mgessner]

It'd be interesting to know what Oregon's northern neighbors in Redmond think about this.

It's a baaare faced challenge to the quality of M$'s products.

Go OREGON!

I write code for government agencies

[stratjakt]

This means nothing. This is a no-tooth bill that has nothing to do with increasing open source usage, but merely placating a bunch of lobbyists.

Here's how it goes when an agency is looking to buy software:

- They decide what they want, and which vendor to get it from. They seek a budget for it.

- The rules say they must let contractors compete on the bid, so they put out an RFP (request for proposals).

- They word the questions in the RFP in such a way as to make sure that the only product that will be acceptable is the one they originally planned on.

I see this day in and day out. Just this morning I read an RFP. They were looking for an RMS system to complement their police dispatching system.

The first requirement was: Must work with the existing dispatching system.

Well, the only RMS out there that works with the dispatching system is the one from the vendor of the 20 year old dispatching system. The whole RFP process is a beurocratic circle jerk.

Now if all the systems were 'open source', would it make a difference? Not really, since we'd be unlikely to rewrite our RMS for each and every bid. An open format for data transmission would be nice, but a pipe dream, since every agency in the country has their own way of managing the data.

So while this is a nice warm and fuzzy bit of legislation, it wont affect how the system works at all. If they put out a contract for a bunch of OS's, it'd read "Must support DirectX 9" or some such to pigeonhole it into what they already decided on.

Re:I would gladly welcome this in my state

[stratjakt]

This is especially true in government applications where the code is 99% custom anyways.

Eg; I work for a company that writes and sells computer dispatching and records systems to cops and firemen. I see no CAD systems on sourceforge. They simply dont exist, and wont because much of the code required is very site specific and customized. It's a niche market that open source, for all its virtues, cannot fill.

Now if they want to run Red Hat Advanced Server on the backend instead of HP-UX or WinNT (which is what we offer now), more power to 'em, but it's still a few hundred bucks in a half-million dollar contract. A bit like pissing into niagra falls to warm it up.

Gaps are everywhere

[TheConfusedOne]

The issue is what you can do when you find a gap and who benefits from plugging the gap.

In the opensource world you can either try to rally the masses or hire your own programmers to fill a gap. The new code then gets returned to the community for possible future use and refinement. (Or it may remain so unique that no one else can gain any use from it.)

In the commercial/proprietary world you usually wind up having to convince the software owner that this is a gap worth filling in. Then you have to wait through the release cycle or pay them extra to do the work for you. At the end of the day the other company owns the fix and you end up re-buying it each time you get another license/upgrade.

(If it's a customizable API then you're exactly where you were with the open source stuff we're you're paying programmers to do the work for you.)

At the end of the day you're probably going to have to pay for a programmer, it's just a question of what return you get on that investment.