Open Source in Government: Newport News, Va.

Sam Hiser writes "Open source in government is getting real. Tom Adelstein, in this penetrating interview with Andy Stein, the CIO of Newport News, Virginia, gets to the heart of why the opportunity to build collaborative software pulled the former chief IT architect of Capital One into the public sector. Police, fire and EMT early responders -- and the IT systems that support them - are under Sisyphean pressure to perform, while budgets are sagging. Something's gotta give, and it's going to be the aging software infrastructure in our towns and cities. Are Open Source platforms the only economically viable alternative? Maybe not, but collaboration will have to occur if we want to build the systems to save our lives."

Comments

Health care as well

[BWJones]

Are Open Source platforms the only economically viable alternative? Maybe not, but collaboration will have to occur if we want to build the systems to save our lives."

And while we are at it.....in addition to city management and taxation for those issues, if we want to reduce the cost of medicine, an open source alternative to the current software with open standards is the way to go for medical health care, health insurance and billing. How much of our current medical system is devoted to billing, reimbursement and trying to transfer and manage data? It's a lot.

A standard open source health care database and form that is managed by the federal government that can be accessed by hospitals, insurance companies, states and individuals is the way through the nightmare that has become managed care. It could even tie into other open source government databases discussed in this article to improve the documentation of medical emergencies which may result in a further reduction of costs to governments and private citizens while also increasing the quality of care.

Battle? Collaboration?

[solprovider]

Most of us have recently seen an increase in news reports about open source software showing up in governments. Most of those reports seem to dramatize an upcoming battle between Linux and Microsoft. Rarely do we see information on the pros and cons of collaborative software development.

It is difficult to have a battle when one side will not show up, and the other side's weapons will not work without rebooting several times.

(Insert bullet. Detected new hardware, please reboot. Loading drivers, please reboot. Shoot. Insert bullet. Detected new hardware...)

---
I learned about programming in the late 70s-early 80s. I started learning by reading code in magazines. I figured that someday I would share my code in magazines. Source was open because everything was interpreted.

I naively thought that was how software was shared. I thought that all programming would be shared. Write once, or find someone else's version, then never write that function again.

I grew up and entered the corporate world. I wrote code, and it was shared inside the company. We did not really have a method to share with other companies.

Then the internet. All the source was open, at least for HTML pages, and continuing when JavaScript was added. Sharing was mandatory, because the "code" was still interpreted.

But we also had these new things called software companies. I learned Pascal by reading the source to Visicalc. I have never seen the source for Lotus123 or MSExcel. How can I fix or add to it? How do I learn from it?

Then I read about RMS and FSF and GNU. Sounded good. Why were businesses using proprietary programs when they could collaborate and get what they wanted cheaper? I still have not heard a good answer, other than management DOES NOT WANT any responsibility they can avoid. They prefer a fixed cost every year to a single effort that produces something that exactly fits their needs.

---
For example, in October I noticed that one of my clients had an incredibly poor process: bad UI for input, little error-checking during input, more human resources dedicated to fixing the bad data than to entering it.

I built a prototype of an application that would solve all that, run on worse client hardware than they were using, and allow remote access. It would integrate further up and down the process, so the people collecting the data would also input it. It included a similar business process that had not been automated yet. I arranged a meeting with management, and I demonstrated it to them.

It turned out that for several years they had been considering an "industry standard" software package to improve this process. My demonstration was the catalyst that caused a decision to be made. They "chose" the industry standard. My software was:

- cheaper in the short term. (They are my favorite client. I had built the prototype for fun. I wanted them to use it to demonstrate other skills that might have led to more business. So I told them to pick a price a little lower than the first year of the other product.)

- free in the long term (I was giving them all source. The industry standard is proprietary and charges annual licensing.)

- better suited to their business. (I built it for them. I know how they think. I know how they will use it and what output they expect. The industry standard is, well, standard.)

- better integrated with their current software. (I BUILT THE CURRENT REPORTING SOFTWARE. My prototype was built to easily transfer into that program. We had already proven integration with the other backends. I do not know how the other product integrates, but IT is already complaining.)

- better ownership. (Forget the source. The industry standard uses the ASP model where the proprietary company owns your data!)

I have had every person involved with this process, except the decision maker, tell me that my "prototype" was already better than the new product.