Update on Open Source for Government
Matthew Burton
(The below is also posted on my site here: www.impublished.org/wordpress/govzilla-update-august08/ )
A few updates to report on the Open Source Developer-Government Co-op project (but nothing new to report regarding a better name for this thing).
1. Early on, I said my big concern was avoiding the legal landmines that forbid the federal government from accepting free work. Tom Bruce at Cornell's Legal Information Institute felt my pain and connected me with some former government IT acquisition executives. They have been incredibly helpful, making light of technicalities that would have taken me months to discover on my own. The gist of what they've told me:
- The federal government is loathe to accept products for free, unless they are also offered to everyone else for free.
- Charging the government $1 for a service or product is better than giving it away; that means the buyer and seller have agreed on a price, a point that may not be disputed in the future.
- You cannot attach for-profit maintenance/service agreements to a low-cost sale or giveaway. That's rightly seen as non-competitive.
- Educational institutions are great vehicles for ideas like this one. They are funded outside the government and have the public interest at heart. When working with such an organization, government buyers can be confident that the sellers do not have any plans to make a mint off of taxpayer dollars.
Finally, and most importantly:
- Almost all federal acquisitions have to be competitive. In *most* cases, it would be illegal for an agency to go directly to an organization, non-profit or otherwise, and retain their volunteer software development services. Instead, that agency must go the usual route of requesting bids from the rest of the industry; if the volunteer organization's bid wins, only then could they proceed.
Ah, but I said *most* cases. The exception is the infamous sole source, aka no-bid, contract. (Disclosure: I was awarded a sole source contract in 2006. It wasn't dirty, though. Promise. In fact, any sole source contract that awards little or no money should not draw suspicion. Sole source contracts appear to be the only means for achieving the Open Source for Government goal. Is this means an honorable one? I think so, as we would be working for free. But I'm open to dissenting opinions.)
So, when is a sole source contract justifiable? There are seven circumstances, all outlined here under section (c). Of particular interest to me were 1 ("the property or services needed by the agency are available from only one responsible source"), 2b ("to establish or maintain an essential engineering, research, or development capability to be provided by an educational or other nonprofit institution") and 7a ("the head of the agency determines that it is necessary in the public interest to use procedures other than competitive procedures in the particular procurement concerned").
Our charge is clear: to identify government buyers who think our model can achieve things the current model cannot, who like our price (not hard), and who think our organization will benefit the public good.
Keep in mind that this applies only at the federal level; states' policies could be identical or the complete opposite. Because of that, I am keen to identify states with looser acquisition policies, as they'd be ideal early adopters.
--
2. A few weeks ago, I attended the inaugural BarCampMil in DC, a sort of one-day expo for tech tools with defense and humanitarian applications. While there, I found this juicy nugget buried in the House Armed Services Committee's report on the 2009 defense bill:
The committee is concerned by the rising costs and decreasing security associated with software development for information technology (IT) systems. These rising costs are linked to the increasing complexity of software, which has also resulted in increasing numbers of system vulnerabilities that might be exploited by malicious hackers and potential adversaries...
Open source software (OSS)...provides greater rigor in the software development process by making it available to a diverse community of programmers for review, testing, and improvement. The Linux operation system and Internet Protocol internet addressing system are examples of high quality products developed within the business sector using the OSS standard.
The committee encourages the Department to rely more broadly on OSS and establish it as a standard for intra-Department software development...The committee believes...the wide-spread implementation of an OSS standard will not only lead to more secure software, but will also foster broader competition by minimizing traditional constraints imposed by an over-reliance on proprietary software systems.
This made me beam. This is as close as we could get to a government body saying, "Open source software developers deserve sole source contracts, because they can do things the current model cannot." Within the government, the notion persists that openly visible code is inherently more vulnerable. Having a House committee on our side will do wonders to help us dispel this myth and win those sole source contracts.
--
3. In case you missed it, Dave Witzel hosted an online interview with me a few weeks ago. Most of it focused on the open source project.
--
4. I came across an editorial in the Times on Sunday, blasting the government's effort to fix the terrorist watch list. Railhead, as the reform project is called, has cost the government $500 million. And yet the resulting product cannot perform basic searches. (There's more information, including a link to the House reports, here.)
Downright shameful. It's time for a better model.
Tom Bruce
On Aug 25, 10:00 pm, "Matthew Burton" <matthewbur...@gmail.com> wrote:
> - Educational institutions are great vehicles for ideas like this one.
> heart. When working with such an organization, government buyers can be
> confident that the sellers do not have any plans to make a mint off of
> taxpayer dollars.
government would like to believe it is. There is a certain romance
attached to the way universities operate -- Bright College Years, and
all that. Fact is, doing this kind of work inside a university would
prove difficult unless you were to negotiate a purpose-built
administrative structure with the university from the beginning.
Which is not to say that it's a bad idea, it's just that you need high-
level buy-in from the right partner institution.
Most of what I'm about to say should have the phrase "...at least at
my institution." tacked on to the end of every sentence, and it's
certainly only one individual's opinion.
First of all, there's very little of what I would call mid-term
speculative software development undertaken by professional developers
in universities any more -- certainly not the kind of "hey it would be
neat if..." stuff that built the Web. The world of university IT is
now entirely divided into infrastructural support (broadly interpreted
to include helpdesk operations too), and people who occupy positions
that have the same relationship to funded research that was
traditionally occupied by artisans like glassblowers and machinists.
Very few people have a mandate to try something new that isn't paid
for directly by a grant. And with rare exceptions (we have a software-
engineering practicum course here that takes live clients and has been
a real source of development expertise for me) it is hard to get
enough continuity from student programmers to support projects that
will survive real-world use. We can debate whether development staff
is really necessary to a volunteer effort; I'd argue that some kind of
coordinating core will be essential, just as at Mozilla.
Second, universities take overhead -- 58% at my institution -- off of
any grant. The overhead is considerably less (about 80% less) if the
funds are contributed as a "gift" that has few or vague deliverables
attached. The minute a contract enters the picture, so does the
overhead charge. This is somewhat negotiable, and might well be a
major item to be solved in the aforementioned "purpose-built
administrative structure". I always find it entertaining to have that
conversation with partners, particularly from the private sector.
They are always a little bit stunned by the notion that their money
will go a lot further if they don't ask us to commit ourselves to
actually doing anything ;-). Other points of difficulty in setting up
such a thing include university HR policies (very hard to manage a
staff flexibly, or take on part-time or short-term workers),
accounting structures, and so on, but these are generally easier to
solve. All of these things get a lot easier if a dean, provost, or
other high-level individual wants them to happen. Which brings me
to...
Third, this kind of work will have an interesting and perhaps
difficult time finding the right internal advocates, because it's
"almost right" for a number of disciplines but not an "aha!" -type
exact fit for any. It would be seen (most likely) as an
interdisciplinary project between a government or political-science
department, probably the latter, and a computing or engineering
faculty. There are some of these around, but not many. In most
institutions with the kind of intellectual scope to take it on at all
you'd have to make the case that it somehow contributes to faculty
research -- which might or might not be true -- but in any case would
make it vulnerable to a fairly strong embedded disdain for "applied
research", which is to say anything that ain't basic science, or maybe
quantitative social science. Again, a matter for some careful initial
assessment.
Admittedly, other institutions do this sort of thing way better than
mine does in general, and I have a certain world-weariness that comes
from trying to do this for a while in the face of a fair amount of
institutional drag (trust me, with a few rare exceptions, a law school
is probably not the place to try it). But it would be a real
challenge. Mind you, I think the challenge could be met with some
canny negotiation from the beginning, much as happened with W3C and
MIT, and I could make some offline suggestions about where and how it
might happen. But this is a place where initial conditions need to be
really really right in order to ensure institutional competence over
the long haul, which means careful partnering at the outset.
None of this should be understood as dismissive or opposed to the
notion -- quite the contrary. Universities have amazing advantages in
this context, and we've enjoyed them at the LII for better than 20
years. It's just that romantic notions about free inquiry tend to be
dispelled in the first ten minutes of any meeting with anyone who
controls funds ;-).
> Downright shameful. It's time for a better model.
All the best,
Tb.
Jennifer Bell
to prefer open source solutions:
http://www.tectonic.co.za/wordpress/?p=1377
http://commonspace.typepad.com/commonspace/2008/08/under-the-hood-open-source-govza.html
This seems much more straight-forward. The first step they've
acheived is that all govt documents must be in an open format.
Nifty.
Jennifer
John Wonderlich
(GAO pdf)
energy, public health and healthcare, and telecommunications—that are critical to
the nation's security, economy, public health, and safety.1 Because these sectors rely
extensively on computerized information systems and electronic data, it is crucial
that the security of these systems and data is maintained. Further, because most of
these infrastructures are owned by the private sector, it is imperative that public and
private entities work together to protect these assets. The federal government uses
both voluntary partnerships with private industry and requirements in federal laws,
regulations, and mandatory standards to assist in the security of privately owned
information technology (IT) systems and data within critical infrastructure sectors.
As agreed, our objectives were to (1) identify, for each critical infrastructure sector,
the federal laws, regulations, and mandatory standards that pertain to securing that
sector's privately owned IT systems and data and (2) identify enforcement
mechanisms for each of the above laws, regulations, and mandatory standards. To
accomplish these objectives, we solicited information from the federal agencies
responsible for overseeing each critical infrastructure sector to identify the
applicable requirements, as well as the mechanisms and authorities available to the
government to enforce compliance with these requirements.